Our specification, and a benchmark that does not flatter us.
The dctx Context Management Specification, and an isolated comparison with Trail-Code: wins, losses and what comes next.
Historical post. These results describe dctx as of October 2026, before call edges and byte-stable answers. For current measurements, read dctx 1.1.
An engineering organisation should be able to check every claim a tool makes. So we wrote down exactly what dctx is meant to be, and then measured where it stands today.
The specification
The dctx Context Management Specification turns our core belief, prompt-processing efficiency, into five testable constraints: every answer is bounded, deterministic, prefix-stable, non-redundant and honest about its precision and freshness. It names ten ways chunk retrieval fails and the mechanism that rules out each one, defines a seven-layer organisation policy in which every layer can only narrow the one above it, and lays out the roadmap with an acceptance gate for every step. Each item is marked as available, under contract or a target.
The benchmark
We ran dctx and Trail-Code side by side on a dedicated machine: seven pinned code bases in Rust, Go, Python and TypeScript, no network during the runs, every command pinned to the same CPUs, and an adversarial corpus with planted secrets. The full report, raw data and scripts are public so anyone can rerun it.
Where dctx led
- Cold indexing on every code base: 0.09–6.05 s against 2.4–95 s, with 1.6–27× less memory.
- Footprint: one 9.2 MB binary against 405.6 MB of Node.js packages.
- Bounds: map answers never exceeded their token budget.
- Network: dctx opened no sockets and wrote nothing into the repositories.
Where Trail-Code led
- Call graphs: dctx's map command did not yet expose call or import edges.
- Answers to agent questions: 122 of 140 points against 69 of 140, with fewer tokens.
- Stability under edits: Trail-Code kept most answers byte-identical after an unrelated change; dctx did not, which costs prompt-cache hits.
- Incremental refresh after an edit.
What happens next
The findings are now the first items on our roadmap: call and import edges with honest confidence labels, a persistent incremental index, answer headers that stay stable across unrelated edits, a bounded repository overview, a search verb, and safer defaults for secrets when packing a whole project. Each one ships only when it passes the gate the specification sets for it, and we will publish the next measurement the same way.