Between February and October 2026, I used Enola in 238 coding-agent sessions: 32 Claude Code sessions with Claude Opus and 206 OpenCode sessions with local Qwen models. Their logs contain 4,375 Enola calls. Nothing was staged or re-run.
I used those logs to measure Enola's response tokens and latency, then compared them with two source-reading estimates: one full repository read per session, and only the files named in each answer.
The short answer
Across 4,375 Enola calls:
| Metric | With Enola | Full-repository estimate |
|---|---|---|
| Tokens into the context | 4.1 million | 2.5 billion |
| Time | 1.8 hours | about 6,500 hours of model steps |
| Agent | Model | Sessions | Enola calls | Enola cost | Full-repository estimate | Ratio |
|---|---|---|---|---|---|---|
| Claude Code | Claude Opus | 32 | 774 | 389k | 175M | 450x |
| OpenCode | Qwen 3.8 27B, local | 206 | 3,601 | 3.7M | 2.3B | 623x |
All figures are tokens. Claude Code runs a hosted frontier model with a large context. OpenCode runs a model on my own hardware with a smaller one: Qwen 3.8 27B today, Qwen 3.6 27B before it, and Qwen Coder before that was out. The full-repository estimate is 450× the Enola payload for Claude Code and 623× for OpenCode.
One session, one repository
Totals hide what a single session looks like. This is the median session that snapshots one repository:
| Agent | Source in the repository | Reading it | Enola calls | Enola tokens | Enola time |
|---|---|---|---|---|---|
| Claude Code | 3.0M tokens | 1.5 hours | 24, of which 6 snapshots | 12.6k | 39 s |
| OpenCode | 3.0M tokens | 8.4 hours | 9, of which 1 snapshot | 8.5k | 2 s |
The two agents measure different workloads. A Claude Code session here snapshots, pins a baseline, edits, snapshots again and diffs, often several times. An OpenCode session typically snapshots once and queries. Claude Code also times a call from the model's request to the result landing in the transcript, while OpenCode times the call alone.
With four or five repositories loaded together, the source grows to 9.5M tokens and reading it to about 26 hours on a local model. Enola's cost in those sessions is 28k tokens and 7 seconds on OpenCode.
The hours differ so much between the two because the models do. A model step takes a median of 2.9 seconds on Claude Code and 37 seconds on a local model. On local hardware every file read Enola replaces is worth more time than all of Enola's own latency in the session.
Reading does not fit
The comparison above is generous to reading, because it assumes the model could hold what it read. It cannot:
| Agent | Median context in use | Snapshot sessions with more source than that |
|---|---|---|
| Claude Code | 248k tokens | 27 of 27 |
| OpenCode | 56k tokens | 178 of 183 |
In 205 of 210 sessions the repository is larger than the context the agent was working in. A complete one-pass read would not fit in that context. For repository-wide questions (what is unused, what depends on this, what did my change do to the structure), the agent must either work from a sample or query a representation that holds the whole graph.
Tool by tool
The last column is the conservative comparison: the call against opening only the files its answer names, at the agent's own average cost of reading a file. It assumes the agent already knew which files to open.
| Tool | Answers | Median tokens | Median time | Versus the files it names |
|---|---|---|---|---|
generate_snapshot | builds the graph of one repository | 214 to 247 | 1.3 to 3.1 s | the whole repository |
traverse | what is reachable from here | 116 to 198 | 7 to 15 ms | 9x to 19x |
find_path | how A reaches B | 139 | 19 ms | 13x |
query_facts | symbols, routes, dependencies by filter | 181 to 262 | 5 to 28 ms | 10x to 20x |
show_symbol | one symbol, its definition and callers | 380 to 900 | 7 to 16 ms | 2x to 5x |
explore | one module or symbol in context | 540 to 1,002 | 8 to 84 ms | 4x to 5x |
find_orphans | code nothing references | 332 to 453 | 0.1 to 2.2 s | 14x to 15x |
analyze_performance | complexity and query loops per function | 548 to 842 | 0.1 to 1.5 s | 19x to 24x |
impact_analysis | what a change transitively touches | 260 to 356 | 11 to 15 ms | 3x to 8x |
query_insights | cycles, layer violations, hotspots | 404 to 2,791 | 7 to 14 ms | 3x to 5x |
diff_snapshot | what a change did to the architecture | 408 | 288 ms | 4x |
Ranges are Claude Code and OpenCode. The last six tools need the whole graph to answer correctly, so their real alternative is the full read from the earlier tables, not the files they happen to name.
Most graph lookups complete in tens of milliseconds. Analysis passes take up to 2.2 seconds. Snapshots have a median latency of 1.3 seconds on OpenCode and 3.1 seconds on Claude Code, with the slowest tenth taking 7 to 25 seconds.
What Enola costs
The same logs also show where Enola adds cost.
- Its answers. 4.1M tokens over 4,375 calls. The median call is about 220 to 250 tokens.
- Its tool definitions. Registering Enola's tools adds their descriptions to the agent's requests. Neither Claude Code nor OpenCode records enough to measure that, so it is not in these figures. Agents that load tool definitions on demand pay less of it.
- Large answers. A small share of calls return far more than the median. On OpenCode 6% of calls exceed 5,000 tokens and carry 58% of Enola's tokens. Asking for a summary or setting a token limit can reduce that tail; Claude Code does so on 47% of its calls, OpenCode on 24%.
- Failures. About 1% of calls fail on Claude Code and OpenCode.
The conservative reading
If you do not accept that the agent would have read the whole repository, use the floor: for every answer Enola gave, count only the files that answer names.
| Agent | Enola cost | Opening only the files its answers name | Ratio |
|---|---|---|---|
| Claude Code | 389k | 2.1M | 5.4x |
| OpenCode | 3.7M | 28.9M | 7.7x |
Under the named-file comparison, Enola's payload is 5.4× smaller for Claude Code and 7.7× smaller for OpenCode. Opening only those files also produces a partial view: the files are present, but the graph between them is not.
How it was measured
- The data. The session logs the agents keep on disk: Claude Code transcripts and the OpenCode session database. Nothing was instrumented.
- Tokens per call. No agent records tokens per tool call, so each call is sized as characters sent plus characters returned, divided by four.
- Time per call. The timestamps the agents record around each call.
- Reading the same source. One pass over every source file of each repository a session snapshotted, counted once per session however many questions followed. Vendored code, fixtures and generated files over 200 KB are left out. Sizes are the repositories as they are today, not as they were at each session.
- Reading time. Those tokens at the agent's own observed pace: its average tokens per file read, its tool calls per model step, and its median seconds per step.
- What the estimates omit. Both leave out the tokens a model would spend reasoning over what it read, writing the structure down, and re-sending earlier reads on later steps. The full-repository estimate applies only when a question requires repository-wide structure; the named-file estimate is the narrower comparison.
For what Enola is measured on outside real sessions (reproducibility, delta precision, cross-repository coverage) see the benchmarks page and how we test Enola against 91 repositories. For why context is the cost that matters, see the token economics of a coding agent.
enola is open source under Apache 2.0. Free, local, no data leaves your machine.
curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh