We Gave GPT-5.5 a Memory. It Rivaled the Model That Must Not Be Used.

88.31% on Terminal-Bench 2.1 at a quarter of the cost, and a note on what structure gives scale.

There is a new strongest coding model in the world, and you are not allowed to use it. Anthropic shipped Mythos 5 behind a vetted partner program, complete with restricted access and a codename, reported to give 88.0% on Terminal-Bench 2.1, one of the harder public benchmarks for terminal-based coding agents. The version the rest of us can buy, Fable 5, lands several points lower once its safety classifiers do its thing. The strongest coding intelligence on the market is now, quite literally, the model that must not be used, well unless Anthropic deems you safe.

We ran a different experiment this week. We took GPT-5.5, the public model that leads the verified leaderboard at 83.4%, and changed one thing: we gave it the memory system we have been developing at Sentra. It scored 88.31%, while spending 72.6% less money doing it, and we don’t think we have optimized the memory yet so there is a lot more room at the bottom.

Caveats first, because they matter. Our run and Anthropic’s launch numbers are both internal evaluations on different harnesses, and neither has been verified by the Terminal-Bench team yet. We are submitting through the official verification process and releasing every trajectory so you can inspect what the agent actually did. Our report about this result covers all of this. Now the story.

The experiment

Terminal-Bench 2.1 is 89 tasks in containerized Linux environments: build systems, debugging, sysadmin work, security challenges, scientific computing. Each task runs five times, and your score is your mean reward across all 445 trials. The current verified leaderboard leader is Codex CLI running GPT-5.5 at xhigh reasoning effort, at 83.4%.

We took that exact configuration, same agent, same model, same reasoning effort, same harness, same scorer, and made Sentra Code Memory available to it as a tool. The repository gets indexed before the agent starts, and a watcher keeps the memory current as the agent edits. Instead of re-scanning the repo to rebuild context it already had, the agent could just ask.

One variable changed, and every headline measure moved at once. The run succeeded on 393 of 445 trials, a mean reward of 88.31% against 83.37% for the recomputed baseline, which is 4.94 points and 22 additional successes. Total model cost fell from $1,862.98 to $510.30, so the cost of a successful trial dropped from $5.02 to $1.30. Token usage fell 41.2% under the leaderboard’s display convention. And the runs got steadier: tasks solved in all five trials rose from 63 to 68, tasks that failed every trial fell from 5 to 3, and of the five tasks the baseline never solved once, the memory-enabled agent cracked four.

It was not uniformly better. Twenty tasks improved, eight regressed, and sixty-one tied, for the net gain of 22 trials. The regressions sit in a small cluster we are analyzing before the official submission, and every per-task number is in Appendix A of the report if you want to check our math.

One statistic explains most of the run. Input tokens fell 52.1% while output tokens fell only 13.0%. The agent read half as much and built the same amount. The savings did not come from doing less work; they came from not reading the same repository for the fourth time. You can watch it happen at the task level. On compile-compcert, which involves building a formally verified C compiler, the baseline went four for five at $99.89, and the memory-enabled run went five for five at $13.47. On train-fasttext the baseline failed all five trials and burned $138.90 doing it, while the memory-enabled agent got two successes for $14.70. The baseline was not dumber. It was paying frontier prices to rediscover things it had already seen.

What the memory actually is

Sentra Code Memory is a memory construction layer for agentic work. It is not a bigger context window, and it is not a static map of the repository. As the agent works, the system decomposes the task environment into units that mean something: files, symbols, commands, edits, failures, build signals, test results, the task objective, and the relationships among them. The goal is not to preserve every token the agent has seen. The goal is to preserve the parts of the work likely to matter later, keep them attached to their evidence, and hand them back in a form the agent can use while it is still acting. A plain code graph can tell an agent that one function calls another. This layer holds the broader working state: what the agent has learned so far, which hypotheses already failed, which tests are relevant, what changed during the run, and which evidence supports a given recall. It is closer to a task-scoped semantic memory than a repository index.

Internally we describe the process as semantic decomposition followed by ontological lens projection. Decomposition breaks the environment into meaningful objects and events at the right level of abstraction for the task. The lens then organizes those objects through a domain-specific view of what matters. In code, that lens covers modules, dependencies, runtime errors, tests, configuration, and edit history. In a sales workflow it would cover accounts, commitments, objections, stakeholders, and renewal risk instead. Nothing in the mechanism is tied to code as a category. Code is simply the domain where the value is easiest to measure, and where the layer drops into an existing agent loop without touching anything else. The agent still plans, edits files, runs commands, and verifies its work through the same interface. Memory sits alongside that loop as one more recall surface it can call.

This is why three measures moved together, which almost never happens on agentic benchmarks. Score improvements are normally bought with more sampling, longer runs, or heavier reasoning. A large share of what looks like an agent’s reasoning budget is actually spent reconstructing context: re-deriving repository structure, re-reading command history, re-establishing which test matters. Hand that structure to the agent and the model starts where the real work begins, so accuracy goes up while cost and tokens go down, all from the same change.

And to be clear about what we are not claiming: this is not an argument against the bitter lesson. Sutton was right that general methods riding compute beat hand-crafted cleverness, and the model doing the work in our run is itself a product of that lesson. Our claim is narrower and, we think, more interesting. The bitter lesson is about how capability should be acquired. It says nothing about how much of that capability you should waste rebuilding the same context five times in a single run. The memory layer is not hand-coded task knowledge; it is a general mechanism that spends compute once on structure so the model does not have to spend it repeatedly on rediscovery. Scale sets the ceiling. Structure decides how much of that ceiling you actually get to use, and at what price.

Where 88.31 lands

For every number that is not ours, we will point you at BenchmarkList’s aggregated Terminal-Bench 2.1 tracker, which collects the self-reported launch figures and the independent Vals runs in one place. Mixing verified leaderboard results, vendor launch numbers, and independent Vals runs, the ladder this week looks like this::

• Claude Opus 4.8: 82.7%

• GPT-5.5 via Codex CLI, the verified leaderboard leader: 83.4%

• Claude Fable 5, the new model anyone can buy: 84.3% on Anthropic’s own table, and 80.5% in Vals’ independent run

• Claude Mythos 5, same weights as Fable but restricted: 88.0%

• GPT-5.5 with Sentra Code Memory: 88.31%

Two claims fall out of that ladder, and they are not equally strong, so let me state them separately. Against every model the public can actually use, the gap is four to five points, and that is before you notice that the independent measurement of Fable 5 came in lower than the launch table. That claim is comfortable. The second claim needs more care: against Mythos 5 itself we land 0.31 points higher, across different harnesses, comparing two unverified internal evals. Call it a tie if you like, but a tie is the story. A rented public model with a memory layer has no business being anywhere near the most restricted frontier system in the world, and yet here we are. The gap between the model you are allowed to use and the model you are not turned out to be about the size of a memory.

Note: Our result is pending verification by the Terminal-bench folks (if you know how to speed it up, let us know).

Why we are not open-sourcing it

Now the question we will get in every comment section, answered honestly. No, Sentra Code Memory will not be open source. We understand the irony. We just spent half a post criticizing restricted access, and we are restricting access too. The difference is that we are not dressing a business decision up as something else. We are a company. This is core infrastructure. We intend to sell it.

The longer version is not much longer. Code Memory is one surface of a larger product: a company brain, where the work of everyone in the organization, human or agent, feeds a shared queryable structure. Every decision stays connected to its rationale, every answer stays connected to its evidence, and the system ships with the access control, audit trails, and uptime guarantees required in places where losing context costs real money.

Open-sourcing our foundation would lower the barrier for every enterprise to build the same thing internally. Giving away your moat to look virtuous is not strategy, it is vanity.

We also see the symmetry, before anyone points it out. We spent a section above teasing a lab for restricting access to capability, and here we are restricting access to capability, minus the costume. That is fair criticism. Everyone gates; the only variable is the story they tell about why, and ours comes with no story at all. What we are releasing is the part that lets you check us: this full technical report with per-trial results on all 89 tasks, the complete run trajectories alongside our official Terminal-Bench verification submission, and the product itself shortly. The source stays closed. The evidence does not.

What happens next

Section 3 of our technical report has the methodology, Section 8 has the limitations, and Appendix A has all 89 tasks if you want to audit us trial by trial. Trajectories drop with the verification run. If you want early access to Sentra Code Memory, or you want to argue with us about any number in this post, DM me or ashwin at sentra.app .

We started with code because code has the crispest utility function of anything inside an organization: make the tests pass. That clarity is what made the result easy to measure, and it is also why code is only the first domain. The same move, structure first and then intelligence, is what a company brain does for everything else your organization knows and keeps forgetting. That part is harder to benchmark. It is also the part we find more interesting, and it is where we are going.

Sentra Code Memory on Terminal-Bench 2.1: Technical Evaluation Report (June 2026). Sentra results pending official benchmark verification; baseline figures recomputed from the published Codex CLI + GPT-5.5 (xhigh) per-task trial data. All third-party model figures via BenchmarkList’s Terminal-Bench 2.1 tracker, which aggregates Anthropic’s June 9, 2026 launch table and Vals’ independent runs.

At Sentra, we’re building what can be described as a “company brain”, a shared intelligence/memory layer that sits on all communication channels, knowledge bases, action and agent traces to understand how everyone in an organization actually works as well as how work actually gets done, constructing a living world model of the entire company in near real time.