Why We Built This
We're two people building WOS, a long-term memory API for AI agents. The problem we kept running into: agents either forget everything between sessions, or you fix that by re-sending the full conversation history on every single call.
That gets expensive fast, and past a certain length, models don't even use all of it well anyway.
What It Actually Does
You store a user's memories once. On each query, WOS recalls only the relevant ones and hands you a small, bounded context, no matter how much history is behind it.
- Semantic Retrieval: No keyword matching (BM25), so it works perfectly across English, Korean, Japanese, etc.
- Bring Your Own Key: Use your own LLM key for generation; we only handle search and storage.
The Number That Mattered Most: 45x Cheaper
For a 100K-token history with 1,000 queries a month:
- Standard approach: ~$250/month in tokens.
- With WOS: ~$5.50/month.
The gap only grows as the history expands.
Language-Agnostic by Design
We deliberately left out any lexical/keyword matching. This means retrieval quality doesn't quietly degrade depending on what language someone happens to write in. We test this against a single store holding multiple languages at once, and it holds up.
Try It Out
You can explore the documentation and start using the API here:
Wontopos - Long-term memory for AI agents
WOS is a long-term memory API for AI agents. Store and recall what matters across sessions, in any language, billed only for the tokens you use.
wontopos.com
Would love feedback!
Especially from anyone who's hit memory or context-length walls building their own agents. How are you handling long-term context today?
Top comments (2)
How's everyone actually handling long-term memory right now? Re-summarizing the whole history each session, a full RAG pipeline, something else?
The 45x is real and it is measuring the easy thing. Cost is arithmetic on tokens, verifiable in one line. The claim that actually decides whether the product works, that selective retrieval preserves the answer, is the one the post does not touch, and it is not touchable by looking at outputs either. A plausible answer from an incomplete retrieval looks identical to a plausible answer from a complete one. That is the trap: full-history stuffing is expensive and dumb, but it has one virtue, it cannot silently omit. Bounded retrieval buys the cost saving with exactly that virtue. The agent now sees a small clean context and answers confidently whether or not the one memory that would have changed the answer scored just below your threshold.
So the number you are missing is the false-drop rate, and there is only one oracle for it: run the same query against full history and against bounded retrieval and measure where the answers diverge. Divergence is the cost of the cost saving, stated in the currency that matters. Without it, 45x is a fact about the bill and silence about the product.
One constructive piece, since your retriever already holds the signal. Do not just return the top-k, return the score gap between the last included memory and the first excluded one. A small gap means something relevant sat just under the line, which is the query where bounded retrieval is about to fail, and it is exactly the near-miss a winners-only retriever throws away. That gap is your completeness meter, and it is what lets the agent widen the window instead of answering confidently into a hole.