Watch a coding agent fix a bug and the edit itself is rarely the slow part. It finds the function, changes a condition, and then the long tail begins: re-open the file, read the diff, run the tests, read the file again, run a different test, check an unrelated caller just in case. I have stared at enough Claude Code transcripts to recognise the pattern, but I never had a number for it.
FlowPlan, from Melika Sepidband, Jiho Shin, Song Wang and Hadi Hemmati, puts one on it. In their Claude Code baseline, about two-thirds of all tokens were spent after the agent's first edit, across roughly 31 further calls of re-reading, diff inspection and testing. Their fix is not a smarter model or a bigger context window. It is making the agent say, in a checkable format, what its edit is supposed to change before it makes it.
The agent can't tell when it's done, so it keeps checking#
That post-edit tail exists for a reason. A vanilla agent has no explicit statement of intent, so the only way it can convince itself the edit is right is to look at the code again and run things. Each look re-sends a growing context. The paper measures this directly: cache reads account for 96–98% of baseline tokens. The agent is not writing much. It is re-reading.
FlowPlan's bet is that if the agent commits to a structural plan up front, verifying the edit becomes a cheap comparison instead of an open-ended investigation.
A plan written as a graph diff#
The mechanics are concrete enough to copy. For each function in play, FlowPlan builds a control-flow or data-flow graph on demand (from the AST for Python, from a Joern code property graph for C/C++). The agent then works through four phases, prescribed by a /flowfix skill and backed by five MCP tools:
Locate: find the faulty function and the graph element inside it, not just a file and line.
Plan: write the fix as typed graph operations such as add_guard, remove_branch, change_condition or rewire_edge (or add/remove/move a def-use relation), each with a target function, anchor line and rationale.
Edit and check: make the source change, then flow_check fingerprints the graph and grades the observed delta against the plan as exact, same_family or mismatch.
Verify: flow_verify checks the whole plan and flags any modified function the plan never mentioned.
Retries are capped at one extra edit-and-check, one replan and one corrective edit. Notably, none of this is enforced at runtime. It is a skill plus tools, and the agent is told to follow it.
That last detail is what made me take the paper seriously. This is not a custom scaffold you would have to rebuild. It ran on Claude Code 2.1.220 in headless mode, which means the whole intervention is something you could drop into your own setup as an MCP server and a skill file.
The tail drops from about 31 calls to 12#
The evaluation covers SWE-bench Pro (158 instances), SWE-bench Verified (218) and SecBench (169 C/C++ sanitizer crashes), with Claude Haiku 4.5 and Claude Sonnet 5 at low reasoning effort. Mean tokens per instance, baseline versus the CFG variant:
Haiku 4.5, SWE-bench Verified: 3.41M → 1.09M (0.32×)
Haiku 4.5, SWE-bench Pro: 3.72M → 1.76M (0.47×)
Sonnet 5, SWE-bench Pro: 1.15M → 0.84M (0.72×)
Sonnet 5, SecBench: 681K → 642K (0.94×, not significant)
The token reduction was significant in five of six benchmark-model settings after Holm–Bonferroni correction. The post-edit phase shrank from about 31 calls to 18 on Pro and 12 on Verified, and that phase alone accounts for roughly three-quarters of the savings. Pre-edit exploration also halved, from 1.20M to 0.55M tokens on Pro. The planning and verification overhead costs only 2.8–3.7 extra calls per session.
The pattern across models matters. The weaker, chattier Haiku saves the most because it has the longest tail to cut. Sonnet 5 already wanders less, so the gains are smaller, and on SecBench, where trajectories are only about 15 calls long, there is little tail left to remove.
FlowPlan also beat the other token-reduction methods the authors reimplemented. The strongest prior method, simply forbidding execution, landed at 0.68–0.81× with Haiku. AgentDiet and SHERLOC trimmed some tokens on SWE-bench (0.79–0.93×) and then cost more than baseline on SecBench.
Resolution didn't move, and I'm not fully comfortable with that#
The headline claim is that FlowPlan cuts tokens without hurting resolution. Statistically that holds: no difference passes McNemar's exact test, and the deltas run from −4.6 to +4.5 points with no consistent direction. But look at where the minus signs are. On SWE-bench Verified, Haiku went from 61.0% to 58.7% (CFG) and 56.4% (DFG), and Sonnet 5 from 73.9% to 70.6% with CFG. Pro moved the other way, up 3–5 points for both models.
With one run per instance and samples of 158–218, those swings sit inside the noise. That cuts both ways, though. "Not significant" is not the same as "no cost", and a team running thousands of tasks would want to know whether a 3-point dip on Verified is real before trading it for cheaper runs.
The paper's own protocol analysis is the more interesting warning. Pooled over 1,090 Haiku sessions, the agent localized the right function 77% of the time, but the right graph element only 47% of the time. Only 22% of sessions got every step right. Those sessions resolved 53–81% of instances, versus 28–46% for the rest. The authors put it plainly:
The main remaining challenges are precise fault localization and complete repair planning.
Put differently, the verification step is very good at confirming that the edit matches the plan (it did 91% of the time) and has no way of knowing whether the plan was right. A wrong plan, faithfully executed, now passes a structural check instead of a test run. The savings come partly from skipping exactly the work that would have caught it.
There are other limits worth naming. Every number is from Claude Code, two models from one provider, and Python plus C/C++. There are no component ablations, so we can't separate the value of the graph from the value of simply writing a plan down. And the paper reports tokens, not dollars, even though 96–98% of those tokens are cache reads, which are billed at a fraction of normal input tokens. A 0.32× token ratio is not a 0.32× bill.
Stating intent is the cheap part to steal#
I don't think most teams should adopt CFG fingerprinting tomorrow. Graph-level plans fit bug fixes inside a few functions, and they fall apart on cross-function changes, new code and anything whose meaning isn't captured by control or data flow, all of which the authors acknowledge.
What I would steal is the shape: a phase in the skill where the agent writes down what its edit should change, in a form a tool can compare against the diff, plus a hard cap on retries. Even a lightweight version, a list of functions the agent expects to touch, checked against the actual diff, attacks the same tail and catches scope creep. Keep the tests, though. Run them once, at the end, instead of letting the agent poll them for reassurance.
My prediction: within a year, "declare intent, then verify against it" becomes a standard phase in coding-agent skills, and the interesting research moves to the part FlowPlan exposed and didn't solve, which is checking whether the plan itself is right before the agent burns a single edit on it.