The ExpenseFlow benchmark
Production code benchmark: context wins over model size
We gave the same 14 tasks on the same enterprise application to three setups and asked an independent reviewer, OpenAI's Codex, to score each build on acceptance evidence rather than lines of code. A smaller model with ACE beat a larger model without it.
Book a 30 Minute Working SessionClaude Code alone
Opus 5.5, the larger model
5.7 / 10
2 of 14 tasks complete, 12 partial
ACE with Claude Code
Sonnet 5.5, a smaller model
8.9 / 10
11 of 14 tasks complete, 3 partial
ACE with Antigravity
The same context, unchanged
8.2 / 10
9 of 14 tasks complete, 5 partial
What the reviewer found
Every defect in the build without ACE was a context failure, not a capability failure.
Opus knows how to write an atomic update and a meaningful test. What it lacked, task by task, were the rules behind those choices, which lived in the architecture, the policies and the acceptance criteria. Each of those defects is a rework loop that a human reviewer has to catch, and that is where delivery time goes.
Without ACE
- Policy writes that weren't atomic
- Missing version checks
- Exchange rates a later write could silently overwrite
- Tests that only checked the HTTP status code
With ACE
- Atomic writes where the policy required them
- Version checks in place
- Tests that assert on real results
- A pull request with an acceptance record for every task
Method
An expense system every enterprise runs and nobody enjoys building.
- SOX and SOC 2 controls, multi currency rules, segregation of duties, two stage approvals, a payment batch and an audit export
- The same 14 tasks for every run
- Scored by Codex on acceptance evidence, out of 28 points and scaled to 10
- Reviewed on 23 October 2026
Caveats we'd rather you hear from us
- The runs differed in prompts and iteration budgets as well as models, so the gap can't be credited to ACE alone, though the model difference worked against ACE.
- The scores measure task contracts, not full production readiness.
- One application is evidence rather than proof, which is why we publish the protocol below.
Run it on your own code
The experiment is cheap to set up and hard to fake.
1
Pick an application with history, shared domain models and real policies.
2
Write 10 to 15 tasks with acceptance criteria, some crossing feature boundaries.
3
Hold the model, prompts and budget fixed, and vary only the context.
4
Have an independent reviewer score each task on acceptance evidence.
5
Measure tasks complete, rework loops, tokens per task and violations caught before merge.