ctx-optimize
Built fastest. Answered cheapest.
Section titled “Built fastest. Answered cheapest.”The fastest graph build of any agent-context graph tool on real repos — ≈2× CodeGraph, 7–16× Graphify, 10–23× GitNexus across six repositories in four languages.
And once it is built, a cheaper model gets the same answer: on the Linux kernel, Haiku 4.5 scored 72/80 where Opus 4.8 scored 79 — at half the wall time.
The graph does the structural work once, up front. The model stops paying to re-derive it on every question.
The short version
Section titled “The short version”| ctx-optimize | best of the rest | |
|---|---|---|
| Build · java-spring, 10,142 files | 10.1 s | 19.2 s · CodeGraph |
| Build · Linux kernel, 144,011 files | 118 s* | 290 s · CodeGraph |
| Query · Linux kernel | 4.11 s | 0.98 s · CodeGraph |
| Re-gather after an edit · big repos | 1.4–11.7 s | 0.2–0.4 s · CodeGraph |
| Store on disk · java-spring | 142 MB | 720 MB · CodeGraph |
| Added to your repo | 52 KB | 3.6 MB in-tree · Graphify |
Two of those are losses. Both are on the roadmap and neither is buried.
* That kernel figure is conservative: it was measured on an older build whose gather still produced the markdown wiki, dropped from the default path in v0.12. HEAD does the same gather in 61.2 s. We leave 118 s in the table because the CodeGraph figure beside it is from that same older run, and mixing a fresh number of ours with a stale one of theirs would flatter us. Full tables and the provenance of every run →
Against the field — CodeGraph, GitNexus, Graphify, Serena, potpie — including who to pick instead of us: compare →
Install
Section titled “Install”Pick your agent. Three commands.
npm install -g @muthuishere/ctx-optimizecd your-repo && ctx-optimize upctx-optimize install --claudenpm install -g @muthuishere/ctx-optimizecd your-repo && ctx-optimize upctx-optimize install --codexTrust the hook once with /hooks.
npm install -g @muthuishere/ctx-optimizecd your-repo && ctx-optimize upctx-optimize install --copilotnpm install -g @muthuishere/ctx-optimizecd your-repo && ctx-optimize upctx-optimize installGrok reads the Claude skill dir; Devin reads ~/.agents/skills.
up detects monorepos, writes the config, and gathers — seconds, not minutes. Your agent then answers with query, card, change-plan, affected and boundaries, citing file:line. It may still grep; we do not block it. After you edit, sync.
Or do the whole thing in a browser
Section titled “Or do the whole thing in a browser”ctx-optimize serve # http://127.0.0.1:4747Onboard a repo, watch it gather, run queries, and read the graph — without touching the CLI. Binds loopback only; writes need a per-process token and land in an audit log. The UI is compiled into the binary, so no CDN and no external request, ever.
The dashboard · Read the picture
What makes it different
Section titled “What makes it different”It knows what your system talks to. boundaries answers what no other tool has a row for — env vars, hosts, spawned binaries, served routes, each cited and flagged for secrets by name, never by value. On this repo: 94 ports.
It extends without a release. 12 languages embedded; any other language from its tree-sitter grammar URL, compiled in pure Go. Same drop-in door for your framework’s routes, your build tool’s manifests, and adapters for anything else — Postgres, Kafka, S3 and OpenAPI ship as native connectors.
It stays out of your repo. The store lives outside the tree. What gets committed is 52 KB of config. Your teammate pulls that, not a gigabyte of index.
Monorepos are the designed case. One store per module plus a federating navigator, so editing one service re-gathers that service — not the whole tree.