Model D · every claim with its data
Model D maps your code once, decides where to look before the model runs, and hands the model only what it needs. It also learns from every exploration, so the next question costs less. Each claim below links to its plan and its data, and one command recomputes them all.
python evidence/verify.pyWhat it does
Every agent pays twice: once to work out where to look, then to reason about what it found. Model D takes the first part off the model. These are measured against the same Claude agent working alone, with the same questions and the same instructions.
ocm build <folder> indexes code, config and docs locally. Nothing is sent anywhere, and no model is called.
Open source, Apache-2.0
Proof: the source · DOI
Over ten years of Django, replayed in order, it put the right file in front of the model 83.9% of the time. Showing the five most-touched files instead finds it 13.9% of the time.
83.9% vs 13.9% · 5,333 real fixes
Proof: plan · results · vs Graphify, 285 issues: 176 vs 131
On 114 real Django bugs, run three times, the model needed fewer requests, at the same accuracy.
4.03 → 2.54 requests per bug · 1.35× cheaper · 325 vs 321 right of 342
Proof: plan · rows e1, f1_r2, f1_r3
On the reworded bug reports it had learned, the model read a quarter of the tokens. Against Graphify's code graph, on 285 real issues, it hands over about 2.4× fewer tokens.
29,046 → 7,166 tokens per question
Proof: report, key E2 · vs Graphify
Research with web search, deep research over code, docs and the web, and research from tickets all cost less. They cost far less when the question comes again.
2.3× first time · 9.8× asked again
Proof: plan · rows e6, f3, g1
The same kit, live, saved more requests on a 10.8M-token codebase than on a 148k-token one. Both arms got every question right.
1.25× on 148k tokens · 1.71× on 10.8M · 60 of 60 right
With its parameters fixed before the runs, the turn law predicted the requests Model D would need, and the learning formula predicted the saving on reworded questions.
within 9% and 4% · 4.80× predicted, 5.38× measured
Proof: report, keys M1 E1, M1 V4, M3 E2 · formula
ocm init wires it into Claude Code, Kiro, Codex or Gemini CLI, and it serves any MCP client. ocm hybrid fuses it with Claude, OpenAI or Gemini.
One command per repository
Proof: the README
How it learns
When a question is new, Claude explores and answers. The line of code it cited becomes a lesson: the question's vector, attached to that code. It is not a stored answer. A later question that means the same thing, in any words, lands on that code, and a small model reads it once.
Across every Claude API run that recorded it, almost every answer that needed exploring left a lesson behind.
1,854 of 1,865 explorations
The 114 Django bugs, reported again in different words. Model D answered 84 of them by one read of code it had learned, and 81 of those were right. The agent alone paid more for the reworded reports.
$0.069 → $0.013 per question · $0.0005 per learned read
On Gemini 2.5 Flash, over three runs, a learned question took about one request instead of five. On a 10.8M-token codebase, all 30 reworded questions landed on what had been learned.
5.1–5.4 → 1.0–1.1 requests · 30 of 30 · bill 6–12× lower
Proof: Gemini report · 10.8M report
A lead, backend, frontend, DevOps and a new joiner asked 100 questions about a real application, three times over. The saving grew as the team taught it.
2.34× cheaper · repeats 3.49× · 2.66× → 3.17×
Proof: plan · strict reader · rows v4, v7, judge
We deliberately taught 57 misleading lessons, each the most similar other bug. The cheap read never answered from one. Each of those bugs was still explored and answered.
57 misleading lessons · 0 false reads · 57 of 57 right
Proof: rows e3
Where it doesn't win
Each of these comes from the same files as the results above.
| Test | What happened | Evidence |
|---|---|---|
| Answer quality, SWE-QA (91 questions) | 73.3 vs 75.9 out of 100: 96.5% of the quality, at 1.90× lower cost | report_retest |
| Writing fixes | Not cheaper per fix yet: SWE-ContextBench 11 vs 12 of 28 resolved ($0.063 vs $0.060 per task); Django's own tests 15 vs 16 of 19 | report_retest, VALUE5 |
| Learning from past fixes | A learned match from an earlier fix misled 2 tasks | report_swecb |
| Ten-year replay, learned shortcut | When it fired, its first pick was right 43% of the time; learning added 0.6 points over the frozen layer | RESULTS_REPLAY |
| Learning curve on Claude Sonnet | Failed (S4, S5); three audits traced it to the issue mix | RESULTS_LEARN |
| Lessons carried through a code move, live | No saving: 142 vs 137 requests | RESULTS_LIFE_LIVE |
| Bug reports with every code name removed | Accuracy fell, and it replicated | VALUE2 (E4, F2) |
| A kit warmed from commit history | Did not beat a cold one | VALUE6 |
| Finding the fixed file in a full repository, full scope | Lost to Graphify on issue titles, 117 vs 131: documentation filled half its top five. The code scope in 0.2.2 was then tested against a plan fixed in advance: 176 vs 131. | score_087, CODEONLY |
| Long sessions | The saving does not compound; clear between tasks | RESULTS, 10-11 |
Check it
The bundle contains each test's plan, the per-question records for both arms, the judges' verdicts, the reports and the scripts that wrote them. The verify script recomputes the numbers on this page from the records. It also checks each plan against the SHA-256 recorded before its first model call.
git clone https://github.com/devkancheti4-design/optimal-context-mapping cd optimal-context-mapping python evidence/verify.py
Python 3, standard library only.
60 plans and inputs in the bundle match the hash recorded before their test ran. Two run scripts changed afterwards. Both changes are written up as deviations, and both were made before any request.