Shoji

I build most of my work with an AI coding agent now, this site included. Watching where the money went, most of it paid a top model to do things a cheaper one does just as well: finding files, summing them up, reading a diff. The judgment that needs a strong model is the plan.

Shoji is the tool I wanted: describe a change, and a small team of models carries it out, each one chosen for its step. It's my biggest project so far, and the first one with a runtime, a desktop shell and a design system of its own.

A change is really a series of steps. Shoji names four: Scout reads the code, Plan writes the steps, Build makes the change and runs the tests, and Review reads the diff and says if it's ready. Then you decide.

• Give each step the model that suits it, and let me change any of them.
• Show every step as it runs, with its model, its work and its cost so far.
• Never touch my checkout or commit anything until I accept it.
• Stop before spending more than I set, not after.
• Prove the savings on real work before claiming them.

Before building an app around routing, I needed to know it held up. I took six real commits from one of my own projects and ran each task twice through the first version of the runtime: once routed, once with every step on Opus 5.5. A cheaper run only counts if its change is accepted, so I compared cost per accepted change.

All six routed changes were accepted, the same as Opus alone. That became the Balanced stack, the default: Opus plans, Sonnet builds, Haiku scouts and reviews.

The cheapest seat worried me most. A reviewer that waves bad code through makes every saving worthless, so I wrote a check that hands the review seat diffs with planted bugs, like an annual price computed as 20% of the year instead of 80%, alongside clean controls. On Haiku at low effort it got all 24 verdicts right, catching every planted bug and approving every clean diff, for less than half a cent.

Handing code to a team of models only works if you can see what they're doing and undo it. So a thread shows each step as it happens, with the model behind it and what it has cost so far, and the code opens beside it the moment a file changes. You can ask a question at any point; Scout reads the code and answers, and nothing changes.

Every thread works on its own branch, in its own copy of the project, so your checkout stays as it was and several threads can run at once. When it's done, you accept or revert file by file and commit the rest under your own git name. Shoji never pushes on its own.

Every task leaves a receipt: the model behind each step and what it cost, set against an estimate of the same task on one strong model. The estimate is checked against the spike's real Opus runs, so the savings shown are not a guess.

Models change every few months, and the right stack for one project isn't right for another. Stack lets you choose the model and effort for each role, or start from Balanced. The choice is saved to a stack.lock file with its history, so you can see what changed and when.

Changing a stack shouldn't be a leap of faith. A trial replays your latest accepted tasks on the new stack, in scratch copies of your project, and tells you what it would have cost and whether the work still passes. Watching compares each model's week with the four before it and names one that got slower, dearer or worse at its role. The list of models updates once a day from the repo, so a new model needs no new release.

Running several threads at once needs limits that hold. A role can run your project's checks at any time; any other command, like installing a package, waits for you to allow it once, always for that project, or not at all. Each thread has a spending limit, and a daily limit asks before a new thread could pass it.

Shoji is named for the paper screens of Japanese houses: panels that divide a space and let light through. Its design system, Zone, follows that. Panes, groups and figures meet on hairlines with square joins, like a bento box. A choice sits in a shallow tray and the pick rises as a tile. White fill is kept for the one button that moves the work on.

Color carries meaning and nothing else. Red only means running or spending. Green and a softer red only say how something came out, on small marks and short words, never on surfaces. Everything else is ink on a ground, so it turns over cleanly between the two themes.

Darkroom

Paper

Shoji is a Tauri 2 app: a React and TypeScript interface in a Rust shell. The agent runtime that plans, builds and checks is a separate TypeScript program, compiled with Bun and bundled with the app, so a crashed run never takes the window down. It also runs on its own from the command line, on any git project.

• The Rust shell owns what touches the system: git worktrees, the keychain, the terminal, pushing with your own git sign-in.
• Each thread gets a git worktree on its own branch. It links to your installed packages instead of installing them again.
• Build can open your page in a headless browser at 360, 768 or 1280 px and check what it shows.
• It reads the same commands, skills, AGENTS.md and CLAUDE.md that Claude Code does, and connects to MCP servers.
• Private files such as .env and keys are off limits to every role, and no usage data leaves your computer.

Every model call goes through one meter, which costs it, logs it and holds it to the thread's limit. It checks before the call, using the most the answer could cost, so a run stops short of the limit rather than discovering afterwards that it went over.

async send(role: Role, step: string, request: ModelRequest) {
  if (this.spent + worstCaseOutput(request.model, request.maxTokens) > this.cap) {
    // Near the cap, a call may still answer at shorter length,
    // as long as that leaves it room to work.
    const room = Math.floor(((this.cap - this.spent) / worstCaseOutput(request.model, 1e6)) * 1e6);
    if (room < LEAST_OUTPUT) {
      throw new BudgetExceeded(
        `Stopped at $${this.spent.toFixed(2)}: the next call could pass the $${this.cap.toFixed(2)} limit.`,
      );
    }
    request = { ...request, maxTokens: room };
  }
  // …send, then record the call's real cost.
}

I built Shoji with Claude Code as my engineering pair. I set the direction, worked out each screen on a design board before it was built, and made every product and design call; it wrote and tested much of the code against that board.

Once Shoji could carry a change through, I gave it its own work. Seven of its early fixes were made by Shoji itself on the Balanced stack, from a step that should show as unfinished when a run stops to a friendlier message when Anthropic rejects a key. Each commit records the models that made it and what it cost: $1.71 for all seven.

• Over 300 tests. They replay recorded model answers for each role, so the suite never calls a model or spends money.
• A review check that hands the review seat planted bugs and clean controls, with its results kept in the repo.
• An estimate check that compares Receipts' one-model estimate with the spike's real Opus runs, without calling a model.
• Every change builds the app for macOS, Windows and Linux in CI.
• Live development runs on Haiku only, with a hard spending cap.

Shoji 0.1 is its first public release: free, open source under the MIT license, with installers for macOS, Windows and Linux and a website with a film of one change going all the way through. You bring your own Anthropic key.

Next, I'd sign the builds so no system has to warn before opening them, add model providers beyond Anthropic, and run the routing test again on more tasks and other people's projects, since six tasks from one of mine is a start, not proof.

The lesson I'll keep: with AI doing the work, the product is the trust around it. Showing every step, keeping each thread on its own branch and putting a price on every task mattered more than any single model.