Frequently asked questions

Hosted long-term memory for AI agents on OpenAI. Before every model call your agent sends what is new in the conversation and gets back the request, ready to submit to OpenAI with your own key. After the reply, it reports the reply. Your agent keeps one conversation going for days or weeks without sending the whole history every call: the latest messages go word for word, the facts from older messages stay in view, and the older messages that matter come back, with their dates, when the conversation turns to them.

The context window is finite; the conversation isn't. No model can read an unlimited history, so infinite context is what the conversation is like when it never hits the end of the window: the agent keeps what matters in view, keeps the facts of the rest, and recalls details when they come up, for as long as the conversation runs. In practice: the latest messages word for word, the facts from older messages kept in view, older messages brought back when they matter, a request that stays bounded, and a local fallback when the service cannot be reached. See Infinite context for OpenAI agents.

Not long-term memory. Each Chat Completions request carries the history the model sees. The Responses API can hold a conversation's state with previous_response_id or the Conversations API, but every earlier input token is billed again on each call, and nothing decides what the model should still see. See Does the OpenAI API have memory?

Developers building agents and assistants on the OpenAI API whose conversations run long: support agents, coaches, research and coding assistants, companions, internal copilots. If your conversations end well inside the context window, you may not need it yet.

Any model the OpenAI API you use accepts, through Chat Completions or Responses. We do not call the model; the request comes back to you. The note ask relies on function calling, so use a model that supports it.

Send only what is new to decorate: the user's message, or the model's reply and your tool results. The request that comes back holds what the model should see, and its size stops growing with the conversation. See How to stop resending the whole chat history.

Your instructions, the facts from older messages, the older messages that matter to what was just asked (with their dates), and the latest messages word for word. As the conversation grows, older messages stop being sent word for word, so the request stays a size the model can take. See How it works.

No. They stay in the memory, come back word for word when the conversation turns to them, and are in the export. Data is deleted only when you delete the memory.

Your own model. When older messages are about to stop being sent word for word, the request asks the model to note their key facts with one call to the note tool. The model that was in the conversation writes better facts than a summariser reading it afterwards. See Let the model write its own notes.

The newer fact replaces the older one: "moved to Denver" replaces "lives in Austin". The model sees what is true now.

When a new user message touches something older, the older messages and facts about it come back, with their dates, just before the message, before the model is called. A message that asks about two things gets older messages for both. Your agent does not have to ask for them.

No. RAG answers questions from documents that exist before the conversation. Memory carries the conversation itself forward. It keeps what matters in view and brings back the older parts of the conversation when they come up. See Agent memory vs RAG.

Three calls around the model call you already make: decorate before, submit the request yourself, report after. Add the note tool to your tools and answer its calls with noted. The quickstart has the full loop in TypeScript and Python.

TypeScript (@threadlessai/sdk) and Python (threadlessai), both thin clients over a REST API documented as OpenAPI 3.1. Any language can call the HTTP API directly.

Both. memory.chat is Chat Completions and memory.responses is Responses. A memory can even switch format mid-conversation. See Add memory to a Responses API agent.

Yes. Call decorate before every model call, including each one inside a tool loop. If you stream, report the final response once the stream ends. See Add memory to a streaming chatbot.

Yes. /setup.md gives a coding agent exact steps from install to one verified call, every docs page is served as markdown, and /llms.txt indexes them. The admin MCP server lets Claude Code, Cursor or Codex create projects and API keys.

No, on purpose. Memory is the context the agent runs in, not a tool it calls. An agent that has to decide to search its memory forgets to. The admin MCP server exists for setup, not for runtime.

Your agent keeps answering. The SDK keeps a local tail of recent turns in your process and builds the request from it when we cannot be reached, so the model call goes ahead. Bugs such as a revoked key still throw. See What happens when memory is down.

Per conversation. A memory's id is its only scope, and recall never crosses memories. Durable facts about a user belong in your instructions. See Memory per conversation, not per user.

There are two meters: user turns (a decorate call that carries a new user message) and stored memory per GB-month. Prices are being finalised. You pay OpenAI for your model calls directly, with your own key. See Pricing.

Yes: a monthly allowance of user turns and memories, with no card. The allowances are set with the prices.

No. Calls inside a tool loop, which carry only the model's reply and tool results, are not turns. report is never billed.

decorate answers 429 quota_exceeded, and the SDK falls back to the local tail, so your agent keeps answering.

There is no limit. A memory can run for months; every request stays sized for a 200k-token context window.

On long conversations, usually. Without memory, input tokens grow with every turn; with it, token use stays bounded as the conversation grows. Short conversations cost about the same either way.

No. The SDK returns the request; your process sends it to OpenAI with your key. We see the request you decorate and the reply you report, and never your OpenAI key.

Every message you decorate and reply you report, the facts, search indexes over them, and your metadata. Security lists it all, with where it is processed.

Yes. Export returns everything a memory holds as JSON: every message and every fact. Delete removes everything the memory holds and verifies it is gone before it returns.

No. The memory id is the only scope. Every read and write names it, a request without one is refused, and recall searches only within that memory. A key reaches only its own project's memories.

No. Threadless AI is a hosted service. Ask at support@threadlessai.com if you have data-residency requirements.

They are memory stores: you add messages, retrieve relevant memories or a context block, and place them in your prompt. Threadless AI returns the whole request with the history managed, uses your model to write facts, keeps the request bounded however long the conversation runs, and falls back locally when unreachable. Each has cases where it is the better fit. See Threadless AI vs Mem0 and Threadless AI vs Zep.

Supermemory is a store you add chat, documents and files to and search; its models extract the memories. Letta runs the agent itself on its own server. Threadless AI runs no agent and returns the request for the model call your code already makes. See Threadless AI vs Supermemory and Threadless AI vs Letta.

Supermemory, Letta, Cognee, LangMem, Honcho, Hindsight and Threadless AI, among others. They differ in who builds the prompt, what a memory covers, and who writes the memories. See Mem0 alternatives and Zep alternatives.

Compaction replaces old context with an encrypted item you cannot read, and only in the Responses API. Memory keeps readable facts, brings back details when they come up, with their dates, and works with Chat Completions too. See OpenAI compaction vs a memory layer.

A bigger window delays the problem. Every call still pays for, and waits for, everything in it, and models attend less well to the part that matters in a very long prompt. Memory keeps the request at the size of what matters now.

We are running LongMemEval and LoCoMo against the hosted service and will publish scores with the method and the runs behind them. Until then we publish no numbers.