runcastle vs T3 Code

Both are free, MIT-licensed, open-source, and both put a UI in front of coding agents you already pay for. They are not, however, the same kind of tool. T3 Code is a control plane: one surface for five different agent CLIs, reachable from your desktop, your browser, or your phone. runcastle is a pipeline: it structures the work before any agent starts, and gates what is allowed to merge.

What T3 Code is

T3 Code comes from Theo and Ping Labs. Its README calls it an “agent harness control surface”; the site's headline is “the open-source control plane for coding agents.” It is not a model and not an agent — it drives agent CLIs that are already installed and authenticated on your machine.

The scope is deliberately wide. It works with your subscriptions on Claude Code, Codex, Cursor, Grok Build and OpenCode, and reaches you through an Electron desktop app, a web app at app.t3.codes, and native iOS and Android apps. You can start it with npx t3@latest, or install the desktop build through winget, Homebrew or the AUR. Billing stays yours: the site is explicit that it doesn't resell tokens.

Inside a thread you get the things a GUI is genuinely better at than a terminal: a diff viewer, checkpoints, git worktree support so threads on the same repo don't collide, model switching mid-thread, and “one button to commit, push, and make a PR” with a generated title and body. It is moving fast and says so — the README's own warning is “We are very very early in this project. Expect bugs”, and the project is mostly not accepting outside contributions yet. As of August 2026 the repository has passed 17,000 stars since its February 2026 creation, which tells you how quickly the category is forming.

What runcastle is

runcastle is an opinionated programming system layered on Claude Code — the IDE to Claude Code's text editor. Every feature you build gets a persistent session that walks a pipeline: ideation, spec, tickets, build, review, shipped. You get grilled on an idea until a spec and a set of tickets fall out; sandboxed AFK agents burn those tickets on the feature's branch; you test drive the result and merge. Human in the loop at only the two ends.

It runs entirely on your machine — a Bun server plus a browser UI at http://localhost:4512, with no runcastle account and no hosted backend. It is MIT-licensed, installs from npm with bun add -g runcastle, runs on macOS, Windows and Linux, and requires Claude Code (on a paid Claude plan) as its engine. AFK burns additionally need Docker or Podman. The narrower engine support is the price of the opinion: everything runcastle knows how to do — injected skill packs, phase rules, hooks, its own MCP server — is built on Claude Code's extension points.

Side by side

The real difference is how much opinion you want

Everything below follows from one choice each project made. T3 Code assumes you know what you want built and need a better surface for running it. runcastle assumes the expensive failures happen earlier — that an agent which builds the wrong thing beautifully has cost you more than one that is merely slow.

Planning: bring your own, or produced for you

In T3 Code, a thread starts when you describe a task. The tool is neutral about how good that description is; plan mode and reasoning controls help, but the framing is yours. That neutrality is a feature — it never gets between you and the agent.

runcastle refuses to be neutral there. Ideation opens a real Claude Code terminal whose job is to argue with you until the idea is concrete, and what falls out is a spec and a set of atomic tickets in a dependency order. The spec and the decisions are committed into your own repo under docs/features/<slug>/ as plain markdown — versioned, diffable, and still useful if you stop using runcastle. If you already think in specs, this is the whole product. If you find it ceremonial, it will feel like ceremony.

Parallelism: threads you watch, or tickets that run without you

Both tools are built for more than one agent at a time, but they cut it differently. T3 Code's unit is the thread, mapped to a git worktree, and it will happily run threads across several repositories at once — you supervise them from one surface, on whichever device you have.

runcastle's unit is the ticket. The dependency order produced in the tickets phase is what makes the build phase parallel: everything unblocked starts at once, headless, inside containers, all committing to the same feature branch — with the human in the loop at only the two ends. Meanwhile interactive planning sessions get instant docs-only worktrees, so you can be grilling the next feature while the current one builds, and your main checkout stays reserved for you.

Merging: a button, or a gate

T3 Code ends a thread with review in the diff viewer and, when you are happy, one button that commits, pushes and opens the pull request. Your existing review process — GitHub reviewers, CI, whatever you already run — takes it from there.

runcastle puts a gate between every pair of phases. Gates block by default, and every one takes an override with a one-line reason recorded in the feature's history: seatbelt, not cage. Two of them are the human ones. You review the ticket list and click burn; you test drive the finished branch — runcastle sets your own work aside, checks the branch out, and starts it on its own port — and click merge. Review findings feed fix cycles inside the burner, so only hard blockers reach you.

Model choice and lock-in

This one is not close. T3 Code lets you pick among five harnesses and switch models mid-thread; if a better model ships next quarter, that is a dropdown. runcastle drives Claude Code and nothing else, and inherits Claude Code's requirements, including a paid plan. If multi-model is a hard requirement, stop reading and take T3 Code.

When T3 Code is the better choice

• You want more than one model. Codex for one task, Claude Code for another, and the freedom to switch mid-thread — runcastle cannot do this at all.
• You want to work away from your desk. Native iOS and Android apps plus a web app mean you can kick off and review work from a phone. runcastle is a browser tab pointed at your own machine.
• You want less opinion, not more. For small, well-understood changes — a bug fix, a refactor you can already describe in a sentence — grilling and a spec are overhead, and a thread plus a diff viewer plus a PR button is exactly the right amount of tool.
• You juggle many repositories. T3 Code manages multiple projects simultaneously with per-repo thread history; runcastle's pipeline is organised around features inside a project.

When runcastle is the better choice

• The work is a feature, not a task. Something that wants a spec, a dozen tickets, and a dependency order before anyone writes code.
• You want to be absent, not attentive. The build phase is designed for you to close the tab, not to watch turn by turn.
• You want the reasoning to survive. Specs, decisions and research land in your repo, so the next agent — or the next you — can read why the code is like that.
• You want the tool to say no. Gates that block until checks pass, with overrides that are recorded rather than silent.

Sources

Everything above about T3 Code was checked against these on 10 August 2026. It is early software that ships quickly — if you are reading this much later, check the repository before trusting the details.

• pingdotgg/t3code on GitHub — README, supported harnesses, install paths, MIT licence, project status.
• t3.codes — positioning, mid-thread model switching, the commit/push/PR button, platform list.
• Better Stack's T3 Code guide — walkthrough of the worktree handling, diff viewer, integrated terminal and multi-project behaviour.

Everything about runcastle comes from its README and CONTEXT.md, or from the docs on this site. If you spot something out of date or unfair to T3 Code, open an issue — an inaccurate comparison is worth less than no comparison.