xmemory vs model-vendor context primitives

“Why not just use the model’s own memory?” is the most common question we get, and it deserves a precise answer, because the word covers different things. This page is about three API-level primitives: Anthropic’s memory tool, a file-editing protocol the model uses over storage you provide; OpenAI’s conversation state, which keeps a thread server-side so you need not resend it; and Gemini’s context caching, which reuses repeated prompt tokens so you pay less for them. All three are useful. None of them is a store of facts with a contract. Vendor-managed memory services, such as Google’s Memory Bank, which extracts and consolidates memories for you, are a different category and get their own treatment; they are not what this page compares. xmemory fills the gap the three primitives leave, and it fills it beside them rather than instead of them.

Documentation reviewed 23 October 2026: Anthropic memory tool, OpenAI conversation state, Gemini context caching; on our side How xmemory works, XMD and the integration guides for Claude, ChatGPT and Codex, OpenAI Agents SDK and Google ADK.

What each built-in does

Anthropic’s memory tool (memory_20250818) gives Claude six file commands, view, create, str_replace, insert, delete and rename, over a /memories directory. The tool is client-side: Claude requests an operation, your application runs it against storage you own, and the API adds a system instruction to check the directory before doing anything else. There is no search or query command; retrieval is listing a directory and viewing files. It pairs with context editing and compaction so notes survive when the conversation is summarised. It is a well-made scratchpad protocol, and the storage behind it is yours to design.

OpenAI’s conversation state chains Responses with previous_response_id, or keeps items (messages, tool calls, tool outputs) in a Conversations object that persists without the 30-day default TTL of stored responses. Earlier turns are replayed as input tokens on each call. It is a transcript the service keeps for you; the docs describe no API for storing facts across conversations. The Assistants API is listed as legacy.

Gemini’s context caching reuses the processing of a repeated prompt prefix: implicitly for Gemini 2.5 and later, with minimum sizes in the low thousands of tokens, and through explicit cache objects on supported models, whose expiry you can extend and whose content the model can answer questions over. It is about cost and latency, which it is good at. What it does not provide is record-level fact mutation or a structured query interface; cached content is a prompt prefix, not a store.

Where xmemory is stronger

Facts, not files or transcripts. The memory tool stores whatever text the model chose to write, wherever it chose to put it, and str_replace requires the old string to be unique, so the model is doing string surgery on its own notes. Conversation state stores what was said, so knowing the customer’s current plan means the model re-reading the turn where it changed. In xmemory the plan is a field on the customer’s record, set by extraction against an XMD schema, bounded by an enum and updated by key, with the previous value kept as lineage. The argument in full is Schema as the Core of Reliability; the Why page has the file-memory case specifically.

One shared, schema-governed interface, without building it. The memory tool’s storage is yours, so another model could read the same files through an adapter you write; conversation state and caches are the vendor’s and stay inside its API. Either way, a team that runs Claude for support, Codex for code and Gemini for a batch job ends up assembling the shared layer, or living with three disconnected memories. xmemory is that shared layer: the same instance, schema and records from all of them, over MCP or the SDKs, with the resolution rules enforced by the service rather than by each adapter. Toloka’s evaluation ran it under eleven different models for that reason.

The same memory in the apps you work in, not only in the APIs. The vendors’ consumer products each remember things too, and each remembers them for itself: what you told ChatGPT stays in ChatGPT, what Claude Code wrote to its notes stays with Claude Code, and Codex and Cursor start from scratch. xmemory connects to all of them over MCP, so one instance is the memory behind ChatGPT and Codex (setup), Claude.ai, Claude Desktop and Claude Code (setup, agent-guided install), and any other MCP client. A decision you record in a Claude Code session is the one Codex reads the next morning, and the one your support agent on Gemini checks that afternoon, under the same schema.

Queries, not re-reading. None of the three can answer “how many open incidents does this customer have” without the model reading enough context to count. xmemory answers it as SQL over typed records, over all matching stored records, and can return the rows to code. The same goes for joins and for “which required facts are still missing”, which is not a question a transcript or a directory listing can pose.

Targeted reads control context size; caching is a separate optimisation. This one is complementary. Caching reuses an identical prefix: appending turns keeps a growing prefix reusable, while rewriting earlier notes or messages invalidates it, and a prefix below the provider’s minimum size is not cached at all. What xmemory changes is how much context a turn needs in the first place: instead of replaying a transcript or reloading a notes file, the agent reads the slice of state the question needs, and bounded reads keep per-turn input from growing with memory. Cache what is stable; read what is current.

Governance you define. Conversation retention follows the vendor’s defaults and terms; the memory tool’s storage is yours but unstructured. xmemory adds field-level access control and lineage on every stored value, in your cloud or ours, so the memory shared between agents and teams has a permission model rather than a directory.

On evidence. We have not benchmarked these developer primitives directly, because they are not memory layers in the sense our tests measure. The closest number we have: on the Splitwise task the white paper reports around 92% for customer-facing frontier-model applications used as an end user would, against xmemory’s 95.2%. Those are the vendors’ consumer products with their own memory features, not the APIs on this page, and the gap is small. What the figure shows is that the vendors’ own harnesses are good, and that the tested xmemory configuration scored higher on that workload; it does not isolate the reason, or establish anything about the primitives reviewed here. Method and caveats are in Chasing AI memory SOTA.

Choosing

Use the built-ins for what they are: the memory tool as the model’s own scratchpad, conversation state to continue a thread, caching to make a stable prompt cheap. Use xmemory for the facts that have to outlive a session, a vendor and a context window: typed, keyed, queryable, governed, and reachable from whichever model, app or coding agent is doing the work. The integration guides above show each vendor’s agent reading and writing the same instance.

A memory-tool progress log as an XMD schema

Anthropic’s docs recommend a multi-session pattern: a progress log and a feature checklist in /memories, read at the start of each session and updated at the end. The same pattern as records, which any model can read and no model has to re-parse.

xmd_version: v1
title: Project progress
description: Features and decisions for one software project, kept current across sessions and models.
objects:
  Feature:
    description: >-
      One feature of the project, identified by a short stable name. A statement about
      its progress updates the existing record. Mark verified only when the text says
      it was tested end to end, not merely implemented.
    fields:
      name: { type: str, required: true, description: "Short stable identifier such as oauth_login or csv_export." }
      summary: { type: str, required: false }
      status:
        type: str
        required: true
        enum: [planned, in_progress, implemented, verified, dropped]
        default: planned
      blocked_by: { type: str, required: false, description: "What is blocking it, when stated; clear it when unblocked." }
    primary_key: [name]
  Decision:
    description: >-
      A design or process decision, identified by the topic it settles. A later
      decision on the same topic replaces the earlier one.
    fields:
      topic: { type: str, required: true, description: "Short stable label such as database_choice or auth_provider." }
      decision: { type: str, required: true }
      rationale: { type: str, required: false }
    primary_key: [topic]
relations:
  depends_on:
    description: A Feature that cannot be verified until another Feature is. One link per pair.
    objects:
      feature: { type: Feature, on_delete: cascade }
      prerequisite: { type: Feature, on_delete: nullify }
    keys:
      unique_pair: [feature, prerequisite]

“CSV export passed end-to-end verification against the sample files” sets csv_export to verified, where “finished the CSV export” alone would only reach implemented; “we’re going with Postgres over SQLite after all” replaces the database_choice decision and keeps the old one in lineage. The next session, on any model, starts with “what is in progress and what is blocked” as a query instead of a file to read. This instance is scoped to one project; several projects would add a project identifier to each key.

Why we think this matters, and for whom

xmemory works well for short-running agents, and it is at its best for repeated tasks, where each run adds to a body of knowledge the next run can use. Long-horizon agents deserve a special mention, because there is very little objective evidence yet about what memory design works for them. Our working belief, and the reason xmemory exists: an agent running a long, multi-step task does better on structured state than on accumulated context. A schema gives it an explicit feedback loop at write time (what was accepted, what was rejected, what changed), so memory is updated rather than bloated and the trajectory stays on course: fewer re-reads, faster steps, more reliable outcomes.

If that is your workload, try xmemory on it. We are building objective measurements for this claim. The Toloka evaluation is our first independent measurement of the benefits of structured memory; evaluating changing working state over long-horizon tasks is next, and we would welcome collaborators on it. Write to info@xmemory.ai.