You are already paying for your whole history, every question.
Put in the size of the history you keep pasting, the model you paste it into, and how many questions you have asked. The numbers below start from measured token counts. The recall curve is measured directly at five history sizes on the current engine, from 22k to 802k tokens, by rendering the real prompt and counting it. Sizes between those points are interpolated, and this page says which is which.
GPT-4.1-mini (used for every published number)
Output tokens depend entirely on the task. A yes/no lookup answers in tens of tokens; a "rewrite this module" answers in thousands. Output is billed at four to five times the input rate, and neither arm can avoid it: the answer is the same length whether the model read your whole history or a recalled page. So it sets a floor on cost, and the longer your answers, the smaller the percentage .dai can save.
Conversion happens once. Questions afterwards never re-convert, and recall itself spends no model tokens: your model simply reads a smaller prompt.
Recall sizes are measured on the current v4.4n engine at 22k, 101k, 200k, 502k and 802k-token histories, at its shipped settings, with the context counted off the real rendered prompt. Sizes in between are straight-line interpolations between two measured points, and the 1M row extends the last measured segment. The 22k to 101k stretch is the least certain, because the engine changes mode inside it. Every figure here is the open-source path: the engine run on your own machine with your own key, priced at raw model cost.
Where the money goes
Every model, every history size
Cost of 100 questions, pasting the whole history each time versus recalling from .dai. Impossible means the history no longer fits in that model's context window at all, at which point the comparison stops being about money.
The accuracy column is that model answering from the same v4.4n stores on the official 500-question benchmark (LongMemEval-S, official evaluate_qa.py). The retrieval is identical for every row, so the spread is the answering model, not the format. Every actor we have measured on this engine is in the grid.
The four Claude rows were run through a Claude subscription rather than over an API, so they carry no temperature 0 setting; the GPT-4o row does. Conversion cost (one-time, GPT-4.1-mini observer) is included in the .dai column, priced at raw model cost: the open-source path, run on your own machine with your own key. Answers assumed at 350 output tokens each.
Caching is assumed on neither side, which is the conservative choice and leaves the ratio between the two arms unchanged. Cached entries expire after five minutes by default, or an hour at double the write cost, so caching helps a rapid burst of questions and does nothing for a history you return to next week, which is what a memory is for.
Where caching does apply the two effects are independent and multiply: on these tests, caching alone was worth 7.8x and .dai alone 2.9x, for 16.7x together. Note that the engine does not configure caching itself, so a direct API integration gets none unless you add it. How to set it up
Cost is the small problem. The window is the real one.
Every model has a ceiling, and pasting hits it long before your history stops growing. Here is where the ceiling currently sits across the major vendors, largest first.
Read these as advertised ceilings, not working room. Independent testing finds quality falling off well before the maximum: models sold on 200k become unreliable somewhere around 130k, and a 1M-token model typically holds up to roughly 600k to 700k. So the third column is the planning number, and even it is generous. A 1,000,000-token history, a few years of daily work, is already past what most of this table can open at all, and no budget changes that. Through .dai that same history is a prompt of about 40,000 tokens: under a third of GPT-4o's 128k window, a fifth of Claude Haiku 4.5's 200k, and 4% of a 1M-token window. That figure extends a measured curve that reads 34,244 tokens against an 802,203-token history, rather than resting on an assumption.
Sources and date. Claude figures are Anthropic's published model table. Every other row is the vendor's advertised maximum, cross-checked against two independent comparisons in August 2026. Vendors change these often, so treat the table as dated rather than permanent.
Where this is measured and where it is not: the curve comes from five direct measurements on the v4.4n engine, at histories of 22,431 / 101,075 / 200,487 / 502,296 / 802,203 tokens, reading 37,476 / 14,835 / 17,112 / 25,500 / 34,244 tokens of context respectively. They cost nothing to take: the reader renders the whole prompt before it calls any model, so the context can be counted exactly without spending an answering token. Three of them are worth reading carefully.
At 22k the engine reads more than the history holds, 37,476 tokens against 22,431, because below roughly that size it takes its full-content path and reads the originals verbatim instead of retrieving. That is deliberate behaviour and it is the measured proof of the advice given everywhere else: below about 20k, do not convert, paste it. This panel reports that case as no reduction rather than as a negative saving.
The 22k to 101k stretch crosses that mode switch, so interpolated values inside it are the least certain figures here.
The curve is measured on a purpose-built scaling corpus, not on LongMemEval: the benchmark run reads a mean of 10,065 tokens against a 103,601-token history, lower than the 14,835 this curve gives at a similar size, because the two corpora differ.
It works wherever history piles up. How much you save depends on the work.
A .dai store is a folder of dated text, so anything that accumulates over time can live in it. People use it for chat history across Claude, ChatGPT and Gemini; coding-agent sessions, where Claude Code, Cursor and Windsurf read and write the same store over MCP and the session hook archives each one as it ends; agent memory that has to survive between runs; project and research history spanning months; documents, since PDFs, Word files and chat exports convert into the same format; and team knowledge, because the store is files you can put in git and hand to somebody else. One store serves all of it at once.
What changes between those is not whether recall works. It is how much of your bill it can reach, and this section is the mechanism, so you can predict your own number instead of trusting ours. Every reduction figure is measured on questions asked of a conversation history, which is what LongMemEval-S tests, so treat that as the best case rather than the typical one.
The saving depends on what share of your context is history. Memory can only shrink the part of the context that is memory. In a recall session, the store is nearly all of it. In a build session, most of the context is the work in progress: files being read and written, test output, command results, the system prompt and tool definitions. None of that is history, and no memory format compresses it.
| Session shape | Memory as share of content | Token reduction | Cost reduction |
|---|---|---|---|
| Recall-heavy: 30 questions asked of a large store | most of it | 10.1× | 6.3× |
| Build-heavy: 23 turns writing code, auditing a repo, running tests | 19% | 3.3× | 2.3× |
Both measured on our own real sessions, same format, same engine. The only difference is what the session was doing. Note also that the cost reduction is always below the token reduction: output tokens and cache writes do not shrink when you shrink the input, so a 10.1× token saving lands at 6.3× on the bill. Quoting a token multiple as if it were a cost multiple overstates the saving by roughly half, and we have tried not to do that.
Read the second row as the realistic expectation for token-intensive work. On a build-heavy or agent-heavy session the saving is real but far smaller, 2.3× rather than 6.3×, and your total bill can still go up week on week while the memory layer is working perfectly: it is holding the history flat while the generation, the tool calls and the file reads around it keep growing. Memory caps the part of your context that is memory. It does not cap the task.
Output tokens go up on large tasks, not down. Memory shrinks what the model reads. It does nothing to what the model writes, and a long build task writes a great deal: code, files, explanations, tool calls. On the build session above, output was 333,710 tokens and would have been identical without any memory layer at all. At $25 per million on Claude Opus 5 that is a real line on the bill that no memory format touches. If your work is generation-heavy rather than recall-heavy, the memory layer is simply working on a smaller share of your total spend.
Join the community
An open format only becomes a standard if people use it, so join us and help make it happen: the project is new enough that whoever turns up now shapes what gets built next.