Kit: Claude Code but Concise

Kit, an open-source project in the Speakeasy API GitHub organization, is a Rust coding agent runtime for writing and running code through one programmable tool. It deals with a very specific pain in agentic coding: coding agents often spend too many model turns calling tiny tools one at a time. The useful takeaway is simple: Kit is worth studying because it makes tool use smaller and more composable, but you should try it first on a narrow repo task with visible permissions and review steps. That is the same practical seam we cover in the related training topic: less agent ceremony, more verifiable work.

Understand the one-tool bet

Kit’s main trick is that the model gets one tool, compose, instead of a menu of separate file, shell, edit, search, and delegation tools. The argument to compose is a short Runlet program that can read files, run tests, edit code, retry commands, call subagents, and return structured output.

A coding agent runtime is the harness around a model that lets it inspect a repository, call tools, edit files, run commands, and hand back results. Kit’s opinion is that the runtime should move more of that sequencing into a compact program, not into repeated chat-and-tool round trips.

That is why the Hacker News pitch landed. Claude Code, Anthropic’s coding agent, and Codex CLI, OpenAI’s terminal coding agent, are already familiar to many developers. Kit’s claim is narrower: keep the agent experience, but make the execution path more concise.

The trap is to read “one tool” as “simple.” It is simpler at the model boundary, but the complexity moves into Runlet and the runtime. That trade is attractive only if the program is easier to inspect than a long scroll of tool calls.

Notice what Kit bundles into one binary

The repository describes Kit as a terminal client, an Agent Client Protocol server, an A2A endpoint, and a subagent orchestrator in one static binary. As of September 2026, the repo was still small: 19 GitHub stars, mostly Rust, MIT licensed, and recently pushed.

That smallness matters. This is not a mature enterprise agent platform wearing a new name. It is closer to an engineer’s sharp experiment that turned into a daily driver, with a compact architectural bet at its center.

The bundle is interesting because agent tools are fragmenting. Editors want agent runtimes. Runtimes want protocol bridges. Agents want MCP servers for external context. Subagents want a way to delegate without building a bespoke queue every time.

MCP, the Model Context Protocol, is a standard way for agent clients to connect to external tools and data sources through servers. Kit’s value is not that it replaces MCP; it sits beside protocols like MCP and ACP and tries to make the model’s working loop shorter.

The trap is to confuse protocol support with safety. An MCP server can expose GitHub, Slack, a database, or a private document store. A concise runtime still needs a clear boundary around what the agent can read, write, and execute.

Try one real repo task, not a whole workflow

The safest way to evaluate Kit is to give it a boring task where success is easy to check. Pick something like “rename an internal helper and update the tests,” not “modernize the auth service.”

A good first task has three properties. It touches a few files. It has a deterministic test command. It can be reviewed as a normal diff without trusting the agent’s explanation.

For a Codex-heavy repo, keep the existing repo rules in AGENTS.md and run Kit beside your usual verification loop. The point is not to crown a winner. The point is to see whether Kit’s compose shape produces less noise for the same kind of change.

Here is a small boundary note I would put in a test branch before trying any new coding agent runtime:

# AGENTS.md

## Agent boundaries for this repo

- Do not modify files under `infra/prod/` or `.github/workflows/`.
- Prefer small diffs. Keep unrelated formatting out of the patch.
- After edits, run `npm test -- --runInBand` and paste the failing test names if any fail.
- Do not add new runtime dependencies without explaining why in the final handoff.
- Treat MCP tools as read-only unless this task explicitly says otherwise.

Then compare the result with a normal Codex CLI loop:

git checkout -b kit-compose-smoke-test
npm test -- --runInBand
# run the Kit task in the terminal client
npm test -- --runInBand
git diff --stat
git diff

The trap is to benchmark vibes. “It felt faster” is useful as a note, not as a conclusion. Count the diff size, test result, number of manual corrections, and whether the final handoff named the files and commands that mattered.

Treat concision as a review problem

Kit’s README says fewer round trips can repeat less context and complete more work per request. That is plausible, and it matches a real frustration: many agent sessions burn tokens narrating small file reads and shell calls.

But concision changes the review shape. If one compose call can search, edit, test, retry, and delegate, the transcript may be shorter than the actual work performed. That can be good for speed and bad for auditability.

So the review artifact matters more than the chat log. Ask for a final receipt that lists changed files, commands run, failures observed, and unresolved risk. This is ordinary ai code review hygiene, not special Kit bureaucracy.

For more on the search side of this debate, the same theme shows up in Grep Beats LSP for Coding Agents?: agents often do better when the tool path is direct, inspectable, and cheap enough to repeat.

The trap is to make the runtime prove too much too soon. Kit’s strongest early use case is a contained code change where the runtime can show its compactness without touching credentials, production automation, or migration scripts.

Try it safely checklist

Use this as a small experiment plan, not a ceremony.

One nice starter task is a failing test with a narrow stack trace. Let Kit inspect the repo, make the patch, and run the test. Then review the diff exactly as you would review a human patch from a new teammate.

Common questions

• Is Kit trying to replace Claude Code?

  Kit’s README frames it as “Claude Code but faster, cheaper and more to the point,” but the concrete claim is about runtime shape, not model superiority. It gives the model one compose tool and can run as a terminal client, ACP server, A2A endpoint, and subagent orchestrator.

• What makes Kit different from a normal coding agent CLI?

  Kit moves many small tool calls into one short Runlet program passed to compose. That means a single model turn can read files, run tests, edit code, retry commands, delegate to subagents, and return structured data instead of asking the model to choose each tool step separately.

• Should I connect Kit to an MCP server on day one?

  No, start without write-capable integrations. If you add an MCP server, make the first one read-only and boring, such as documentation search or issue lookup. The runtime being concise does not reduce the need to inspect what external systems an agent can touch.

• Is a 19-star repo too early to trust?

  It is too early to trust blindly, but not too early to study. As of September 2026, Kit was a small MIT-licensed Rust project with recent activity, so treat it like a sharp prototype: sandbox it, read the source path you depend on, and keep the first task reversible.

• How should Codex users compare it fairly?

  Use the same repo, same branch base, same prompt, and same verification command. For example, ask Codex CLI and Kit to fix one failing test, then compare final diffs, test output, manual edits required, and whether each tool respected AGENTS.md constraints.

Best ways to use this research

• Best for: developers comparing coding agent runtimes who care about token use, tool-call overhead, and reviewable execution.
• Best first artifact: a short AGENTS.md boundary plus one deterministic test command, so the agent has rules and you have a receipt.
• Best comparison angle: Kit’s one-tool compose model vs. multi-tool agent harnesses that call file, shell, edit, and search tools separately.
• Best caution: do not treat protocol support, subagents, or a static binary as safety features by themselves. Permissions and review still carry the weight.

Further reading

• kit — source
• Claude Code — getting started
• Model Context Protocol — specification
• OpenAI Codex CLI — source

Try the smallest useful task

Clone Kit, read the compose examples, and run one reversible repo task with a clean test command. If the final diff is smaller, the receipt is clearer, and you corrected less by hand, you learned something real.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.