Most of what you pay an AI coding agent for is search: grepping, reading, re-reading, re-verifying. Talon solves the discovery problem. It predicts what each task needs, serves the agent exactly that context, and steers it clear of the loops. Proven, not promised: 45% measured on sealed paired tasks, at solve-rate parity, with the losing cell published beside the wins.
Three outcomes, all sealed, all paired against an unassisted agent on the same tasks:
And before any of that: run talon estimate, a 30-second read-only scan that tells you your saving band before you pay a cent. Methodology in /research.
For any given task there is a smallest number of steps that genuinely moves it forward: read the right code, make the change, check it once. We computed that floor on real tasks and measured agents against it. An unassisted agent takes 14 tool calls where 4 would do, and roughly 60% of the excess is the same two behaviours: rediscovery and verification. Re-finding code it already saw. Re-checking things it already established. That gap is not the model being slow. It is the model working blind.
The agent greps, opens a near-miss, greps again, reads wider than the task needs. Then it re-verifies its own earlier findings, because nothing tells it they still hold. Every one of those calls bills real tokens, and the wide reads it took along the way are carried forward and re-billed on every turn that follows.
Talon's tuned serves reach the computed task floor: 4 tool calls. The agent begins with what the task needs and spends its calls on the change itself. Fewer calls, but also narrower context per call, so the compounding carry cost never builds up in the first place.
Three verbs cover what Talon does to a coding session. We publish what each one achieves and where it fails; the recipe underneath is sealed methodology, and it stays sealed. Judge us on the measured cells, not on a diagram.
Before the agent takes a turn, Talon works out what this specific task will touch: which parts of the codebase matter, and how deep an answer the question deserves. Not everything plausibly related. What the task needs, and no more. Serving too much is its own failure mode: it costs more than serving nothing, and we measured that too.
This includes the structural context that flat search can't reach, which is why the saving runs deepest on code that is hard to grep.
The predicted context reaches the agent up front, sized to the question. The agent starts where its own search would eventually have ended, without paying for the journey. This is where the floor comes from: the calls that remain are the ones the task genuinely requires.
The waste in agent transcripts is not random noise. It concentrates in two loops: rediscovering code already seen, and re-verifying conclusions already established. Talon steers the agent past both, so the saving from a good start survives the whole session instead of leaking back out by turn ten.
One agent with Talon, one without. Same tasks, same model, both arms best-configured, workspace sealed before either runs. Cost is compared only at resolve parity, so no cell below trades quality for spend. And the table keeps the cell where we lose. That is the point of it.
| Cell | Cost vs unassisted | Detail |
|---|---|---|
| Python | 0.41–0.63× | 44K–1.3M LOC · K=2 · at resolve parity |
| Java | 0.605× | 11/12 cost wins · resolve 7/12 v 7/12, exact parity |
| TypeScript | 0.761× | 10/11 cost wins |
| TypeScript, small | 1.236× | ~1K files · below the size floor · a published loss |
| Large codebases | 35–50% saving | >400K LOC · the band deepens as search gets harder |
| Unfamiliar code | 0.84× | private / post-cutoff code the model has never seen · n=23, contamination-probed |
The shape of this table is the product thesis: the saving tracks how hard your codebase is to search. Deepest on large, private, heavily-indirected code; shrinking to a loss on a small repo the agent can grep in one pass. Which is why we let you measure yours before you buy; see below. Full per-task tables and caveats in /research.
talon estimate is a static scan of your repository: read-only, no LLM calls, about 30 seconds. It measures how hard your code is to search, the property the sealed savings correlate with, and returns a savings band for your stack, not ours.
Is it a precise predictor? No, and we won't dress it up as one. The anchor set behind it is small, so treat the output as a screen: it sorts codebases into bands, it does not forecast your invoice. What it is honest about is the direction. If it comes back low, believe it and keep your money.
Paired runs: the same tasks, the same model, one arm with Talon and one without, both best-configured, the workspace sealed before either starts. Cost is compared only where both arms resolve the task equivalently. The 45% is the measured result across those cells. And the per-cell table above includes the small-TypeScript cell where we cost 1.236×, because a claims table that hides its losses is not a claims table.
It depends on how hard your code is to search. Large, private, heavily-indirected codebases sit in the deep band (35–50% on >400K LOC). Small greppable repos sit near or below the floor. Run talon estimate (30 seconds, read-only, no LLM) and you'll have your band before you've paid anything.
Below the size floor, and on NO_HEADROOM tasks. On very small repos the overhead isn't repaid: the TS-small cell measures 1.236×. On tasks where the unassisted agent is already near the floor, there is simply nothing to save, and serving context anyway can make things worse. We measure and publish both.
No, and this is the claim we gate hardest. Solve rate is ~60%, parity with the unassisted agent, and Talon-assisted runs ship 2× fewer broken tests on SWE-bench-100. Cost is only ever compared at resolve parity, so a cell can't buy its cost win by shipping worse work.
Talon runs inside Claude Code, where you already work. You install it, point it at your repository once, and keep working exactly as before: no prompt engineering, no wrapper CLI, no workflow change, no lock-in. Your source files stay on your machine — the indexer uploads structure (names, paths, call edges), never file contents. Because Talon proxies your agent, whatever your prompts and the model's replies contain does transit our servers; see our data-handling policy for the full picture.
Because the recipe is the product. We publish what Talon achieves (the sealed cells, the floor, the failure modes, the losing cell) and the methodology those numbers were measured under. How the prediction and serving are done stays ours. If you want to verify us, the evidence trail in /research is built for exactly that.
Full per-task tables, the sealed methodology, and honest caveats about where the approach fails. Every figure on this page traces to a sealed benchmark cell, and we publish where we lose.