Sable Memory
Sable Memory gives an agent knowledge bases it can write to and search. You
create a collection, add documents, and search it semantically. The text is
chunked, embedded, and stored AES-GCM sealed at rest, and the chunks a search
returns are meant to drop straight into the sable_context
field on your next chat call, so the receipt attests exactly what context the
model was given.
It is metered like any other work: adding a document is billed as embedding
usage on the same key and the same prepaid balance as inference. A collection
uses sable-embed-3-small by default.
Quickstart
Memory is key-authed: send a sk-sable_ API key as
Authorization: Bearer.
# 1. Create a collection
curl https://api.buildsable.com/v1/memory/collections \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{"name": "handbook"}'
# 2. Add a document (chunked, embedded, stored sealed)
curl https://api.buildsable.com/v1/memory/collections/$COLLECTION_ID/documents \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{"text": "Refunds are processed within 5 business days.", "label": "refunds"}'
# 3. Search it
curl https://api.buildsable.com/v1/memory/collections/$COLLECTION_ID/search \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{"query": "how long do refunds take?", "k": 3}'A search returns the top matches, each with its similarity score, its label, and the chunk text:
{
"results": [
{
"id": "chk_9f21…",
"score": 0.83,
"label": "refunds",
"text": "Refunds are processed within 5 business days."
}
]
}
Composing with a chat call
The point of a search result is to become the context for a completion. Take
the chunks you got back and declare them on the next chat call as
sable_context. The gateway fingerprints
each item in-frame and stamps a content-free context block on the receipt, so
anyone holding the receipt can prove which documents the answer was grounded in
without ever seeing them.
curl https://api.buildsable.com/v1/chat/completions \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{
"model": "sable",
"messages": [{"role": "user", "content": "How long do refunds take?"}],
"sable_context": [
{"text": "Refunds are processed within 5 business days.", "label": "refunds"}
]
}'Endpoints
All key-authed (Authorization: Bearer sk-sable_…).
| Method | Path | What it does |
|---|---|---|
| POST | /v1/memory/collections | Create a collection. Body {name, embed_model?}. |
| GET | /v1/memory/collections | List your collections with dimension and chunk count. |
| DELETE | /v1/memory/collections/{id} | Delete a collection and its sealed chunks. |
| POST | /v1/memory/collections/{id}/documents | Chunk, embed, and store a document. Body {text, label?}. Billed as embedding usage. |
| POST | /v1/memory/collections/{id}/search | Semantic search. Body {query, k?}. Returns the top matching chunks. |
Privacy and limits
- Sealed at rest. Document text is stored AES-GCM sealed, opened only in-frame to embed and to return a search hit. Only the embedding dimension, chunk count, and any label you set are stored in the clear.
- Metered, not free. Adding a document embeds it and is billed as embedding usage; search reads stored vectors. Both run on your prepaid balance.
- This is storage you opted into. Memory is the deliberate case where you ask Sable to hold your text so it can search it later. That is different from the privacy contract for prompts and completions, which are never persisted. Deleting a collection destroys its sealed chunks.
- The default embedding model is
sable-embed-3-small; passembed_modelto pick another from the embeddings catalog.