The private AI coding agent, as it ships.

Terminal · macOS, Windows, Linux

Terminal AI coding agent for bastions and build servers.

On a build server, a jump host or a locked-down workstation, a desktop application is not an option. Same models, same gates, same project context — in a terminal.

$ topsoil models
Models in us-east-1 (refreshed now)

OpenAI
  openai.gpt-5.6-terra              GPT-5.6 Terra         tools · docs
  openai.gpt-5.4                    GPT-5.4               tools · docs

Anthropic
* us.anthropic.claude-sonnet-4-5    US Claude Sonnet 4.5  tools · docs · images
  us.anthropic.claude-opus-4-5      US Claude Opus 4.5    tools · docs · images

xAI
  us-gov.xai.grok-4.6               US-GOV Grok 4.6       tools · docs · images

Amazon
  us.amazon.nova-pro-v1:0           US Nova Pro           tools · docs · images

* default model     tools / docs / images: what the CLI sends

Models come from your account. Enable a family and it appears here. The default is marked; /model opens a scrollable picker rather than asking for an id.

Topsoil  ·  us.anthropic.claude-sonnet-4-5  ·  act/default  ~/Projects/route-planner

› Explain the stale ETA cache and propose a fix

· search     etaCache                  4 matches
· read       src/eta/cache.ts          41 lines
· read       src/eta/reroute.ts        28 lines

The cache key is route.id only, and a reroute keeps the same id while it changes the
stops, so the next request serves the old entry until the five-minute TTL
runs out.

Fix — add the route's revision to the key:

  const key = `${route.id}:${route.revision}`;

Review patch  src/eta/cache.ts  (+1 −1)
  −  const entry = etaCache.get(route.id);
  +  const entry = etaCache.get(`${route.id}:${route.revision}`);

  y accept  ·  n reject  ·  a always this path  ·  esc stop the turn

› Ask anything · / for commands · @ for files

Real work, and the same gate. Search the repository, read the file, explain the defect, propose the change — and the patch waits for a keystroke before it is written.

Plan, read, then explain. Asked why Pro tenants get 429s after a quiet period, Topsoil plans three steps, greps and reads the limiter, names the root cause, and asks before writing a regression test.

Reproduce first, and nothing is written without a keystroke. The new test fails on npm test, then apply_patch shows the exact lines of the fix — y allows it once, a always allows it for the session.

Then it proves the fix. All five tests pass, the change is summarized by file, and Topsoil checks in a scratch copy that the new test fails without the change.

A review before the pull request. Ask for a review and Topsoil reads its own diff against main: ready to open, nothing blocking, with each suggestion anchored to a file and line.

The whole run, in seven frames. Plan, permission, the failing test and the fix, the passing suite, the review and the pull request description. 460 KB, and it only loads when you press play.

› /goal --budget 1 the ETA cache tests pass

Stages: explore, design, plan, implement, verify, review, document

…

Topsoil run budget exceeded. This run spent $1.20 of its $1.00 run budget in 2
attempts. The work so far is on topsoil/goal-x. Raise it with
TOPSOIL_TASK_BUDGET_USD (or taskBudgetUsd in ~/.topsoil/config.json), then run it
again. A /goal can also be started with --budget <amount>.

Hand over a piece of work, with a ceiling. /task, /goal and /loop plan first, work in an isolated worktree and verify before they propose. The first line lists the stages the run will go through; a budget stop says which budget, where the work is, and the process exits with code 3, so a scheduler can tell it from a failure. The messages are Topsoil's; the amounts and the branch are an example.

Delivery

From backlog to pull request with isolated git worktrees.

A walkthrough of /task, from an issue to a pull request a person reviews.

1. Pick the work. /tasks lists what Topsoil can see in GitHub Issues, or in Jira Data Center inside your network. /task <id> takes one.
2. Explore and design. Topsoil finds where the change belongs and picks an approach, writing nothing.
3. Approve the plan. The file-by-file plan is shown to you once. Nothing is written before you approve.
4. Implement in a worktree. The change is made on its own topsoil/ branch in its own git worktree; your working tree is untouched.
5. Verify. The project’s checks run, and new tests must fail without the change before verify can pass.
6. Review and document. A second model, which can be from another vendor, reviews; its findings and how the change was verified go into the pull request.
7. A person merges. The pull request opens on GitHub or Bitbucket Data Center. Topsoil does not merge it.

The diff opens itself. topsoil -w fix-idle-429 runs in the integrated terminal on its own git worktree; when the turn ends, the extension opens a side-by-side diff of the files it wrote.

Your checkout stays clean

Source Control shows two repositories: your main checkout with no changes, and the agent's worktree holding the fix. Commit there and merge worktree-fix-idle-429 with plain git when you are satisfied — Topsoil never merges on its own.

Desktop · macOS and Windows

A workspace, not a chat box.

The fix, awaiting approval. The new test has failed, so the bug is proven; the fix waits as a patch until you choose Accept once, Reject or edit the new text. The working folder stays in view on the right, and a shell and terminals are one click away in the Console.

$ /report Route Planner 2.4 readiness
write document docs/route-planner-2.4-readiness.pdf

Control

Approve, deny or always allow: permission prompts.

−  const entry = etaCache.get(route.id);+  const entry = etaCache.get(`${route.id}:${route.revision}`);

Get started

See it against your own codebase.

A proof of concept runs in your own AWS account with your models and your material, and ends with findings you can act on.