What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Graft’s project documentation reports 42% fewer tokens per task in one efficiency sweep, but that is a project-reported average—not a guaranteed saving or an independently reproduced result. The current repository describes Graft as a codebase-graph and agent-integration tool, which differs from a SitePoint article’s account of Graft as a Claude Code hook system that intercepts and trims tool output. That discrepancy matters when judging both how Graft works and what the benchmark demonstrates.
What Graft is described as doing now
The Graft repository describes software that builds a graph of a codebase, integrates resulting context with coding agents, and keeps that graph up to date with the working tree. It says graph construction is deterministic and does not call a model; summaries may use a provider chosen by the user and the user’s own key. Graft project repository
This is materially different from the SitePoint article’s description of Graft using Claude Code hooks to intercept tool calls and deduplicate or trim their outputs. The repository is the stronger source for the project’s current identity, so that hook-based explanation should not be treated as established product architecture. The available material does not establish the current Claude Code hook API, event behavior, configuration, installation requirements, or version compatibility.
What the 42% figure measures
In its 2026 repository documentation, the Graft project reports a 162-run efficiency sweep across two repositories, with three trials per task grouping. It compared three variants using the same agent and file tools: cold exploration, a Graft context bundle supplied up front, and a pull variant that retrieves context on demand. The project says its cost accounting was cache-aware. It reports mean usage falling from 8,070 tokens per task with cold Claude Code to 4,650 with Graft—a reported reduction of 42%. Graft project benchmark documentation
#1 Best Overall
The same sweep reports lower mean cost, tool calls, and latency, while correctness was unchanged in the project’s results:
| Measure | Cold Claude Code | With Graft | Project-reported change |
|---|---|---|---|
| Mean tokens per task | 8,070 | 4,650 | 42% fewer |
| Mean cost per task | $0.0429 | $0.0292 | 32% lower |
| Mean tool calls per task | 4.2 | 2.3 | 46% fewer |
| Mean latency per task | 39.8 seconds | 15.8 seconds | 60% lower |
| Correctness | 93% | 93% | No difference reported |
These are averages reported by the project for that sweep, not savings established for every task, repository, or developer. The documentation describes the trial design, but the available sources do not provide an independent replication or raw run dataset with which to verify the results.
Rank #2
Why the separate SWE-bench result should not be folded into the 42%
The project also reports a separate comparison on 50 SWE-bench Verified instances. It says both arms used the same model and Docker images and were evaluated with the official grader. The project reports more resolved instances with Graft, alongside lower totals for several resource measures. It says token, cost, and call totals cover only instances both arms resolved, while correctness is calculated across all 50.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute| Measure | Without Graft | With Graft | Project-reported change |
|---|---|---|---|
| Instances resolved | 27/50 (54%) | 33/50 (66%) | Six more resolved |
| Tokens | 142.0M | 109.4M | 23% fewer |
| Cost | $52.34 | $42.43 | 19% lower |
| Tool calls | 1,370 | 1,031 | 25% fewer |
| API requests | 2,455 | 1,875 | 24% fewer |
| Wall-clock time | 13,094 seconds | 8,922 seconds | 32% less |
This is a different evaluation from the 162-run efficiency sweep: it has a different task set and reports outcomes on SWE-bench Verified. Its figures should not be presented as part of the 42% result or as proof that the same savings will occur on an individual codebase.
Rank #3
How to interpret the claim for your own work
- Treat 42% as a benchmark result, not a forecast. The figure is the Graft project’s reported mean for its efficiency sweep; actual changes can vary by task and repository.
- Keep the two evaluations separate. The efficiency sweep reports equal correctness between its variants; the SWE-bench comparison reports 33 of 50 versus 27 of 50 resolved. Those findings belong to different experiments.
- Account for the source. Both sets of results come from Graft project documentation, not an independent evaluation. The project’s own summary says, “An agent that reads the graph should be cheaper and faster without getting more answers wrong.” That is the project’s stated goal, not external validation.
- Check the product description you are relying on. The current repository’s graph-and-context explanation conflicts with the SitePoint article’s hook-and-output-interception account. Avoid choosing or configuring the tool on the assumption that the latter architecture is confirmed.
Verdict
Graft’s reported 42% token reduction is a notable project benchmark, accompanied by lower reported cost, tool calls, and latency without a correctness drop in that particular sweep. It is useful evidence to consider, not a promise of personal savings: the results are project-reported, the tests cover limited task sets, and the product’s current repository description conflicts with the article’s hook-based account.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

