Understand a codebase you have never seen
Paste a public GitHub URL and say what you want to understand. It clones the code, reads it, and writes what it finds to a file you keep.
How it works
Three steps, and none of them is “configure”.
- 01
Give it a URL
Any public GitHub repository. It makes a shallow clone into scratch space, so thousands of files never end up in your workspace.
- 02
It starts where execution starts
The scripts in package.json, a Dockerfile’s CMD, go.mod — the things that tell you what actually runs. The top of an alphabetical file list tells you nothing.
- 03
It writes as it reads
An ARCHITECTURE.md that grows while it works, with supporting notes underneath it. You watch the document fill in rather than waiting for a wall of text at the end.
What it can do
Every claim carries its path
src/server/router.ts:120, not “the router handles this”. A sentence with no path behind it is a guess, and being consistent about it is what lets you tell the two apart.
It reads the code, not the README
And it says so plainly when the two disagree. That gap is usually the single most useful thing it can report.
It is honest about coverage
It will not read all of it, and pretending otherwise is this job’s failure mode. It ends with what it did not look at and what it would check next.
How it is set up
The mechanics, so you know what you are getting before you sign in.
- Environment
- A Linux container with git, curl and a network. The clone goes to scratch space; what it writes goes to your workspace.
- Tools
- A shell for exploring the clone, plus read, write, edit, glob and grep for your workspace.
- Model
- Any chat model. This is the agent that gains most from a large context window — it reads a great deal before it writes anything.
- Starting files
- Nothing seeded. The input is a URL, which you already have; a sample repository would be one more thing to explain rather than a shortcut.
- What persists
- The note survives the session. The clone does not — scratch space is scratch on purpose.
Things people ask it
- “Explain https://github.com/sindresorhus/got — what it is, and how the code is organised.”
- “Clone this repo and trace what happens to an incoming request, start to finish.”
- “Where does this project keep its state, and what writes to it?”
- “Does the README match what the code actually does?”
What it will not do
Every one of these is a real constraint we have hit, not a roadmap item.
- Public repositories only. It holds no credentials, and it tells you which of “private”, “gone” or “needs authentication” the clone actually hit.
- It reads a subset and tells you which subset. No repository of any size is read line by line.
- It explains; it does not change. Nothing is written back to the repository.
Which model does this best
Measured over real runs of this agent, per model. A run counts as finished when it produced the answer on its own — nothing failed, nobody was asked to approve anything, and it did not run out of steps. Read all three columns together: a model that finishes fast by giving up scores badly on the first, and one that completes everything by grinding scores badly on the second.
| Model | Completion rate | Median cost | Median time | Runs |
|---|---|---|---|---|
| claude-sonnet-5anthropic | 75% | $0.026 | 22s | 4 |
- Completion rate
- Runs that finished the job without you having to step in.
- Median cost
- What a typical run costs, in credits.
- Median time
- Wall clock, from the first message to the answer.
Medians over the runs behind each row. A model appears once it has 3 runs on this agent, and the run count is shown so you can judge how much a figure rests on.
Understand a codebase you have never seen
It is already set up. Open it and ask it something.
Explain a repository