Today we are releasing Orcacode, our terminal coding agent, as a public binary for macOS, Linux, and Windows. It installs with one command, ships as a single 6.7 MB static executable, and finishes a measured live workload on roughly half the tokens of the leading harnesses. This post is the full introduction: why we built our own agent, what is inside it, and where it opens up, through Agent Plugins, MCP, and an embeddable Rust SDK.
Your context window pays for the harness. We wanted the bill itemized.
Every coding agent is two things: a model, and the machinery that drives it. The machinery, the harness, is what decides how many tokens a task really costs. Tool schemas the model must re-read every turn, transcript framing, oversized tool output, re-reads of things it already saw: none of that is intelligence, all of it is billed like intelligence. When we measured popular harnesses on identical tasks with an identical model, the spread was not marginal: the most expensive harness spent 5.2x the tokens of the cheapest one to attempt the same work.
So we set three design goals and refused to trade any of them away. First, token efficiency: the harness should add as little as possible to what the model must read and write. Second, execution efficiency: the loop, tool dispatch, and concurrency live in a small Rust kernel measured in microseconds, gated in CI so they cannot quietly regress. Third, customization: every layer above the kernel, providers, tools, skills, plugins, extensions, is a surface you can change, because it is exactly the layer where teams differ.
The result is Orca Harness, the kernel, and Orcacode, its terminal host. The kernel's design and full benchmark methodology have their own engineering deep dive; this post is about the product you can install today.
One command on macOS and Linux. A zip on Windows.
curl -fsSL https://orcapods.ai/orcacode.sh | sh
The installer detects your OS and architecture, downloads the right binary from GitHub Releases, verifies its SHA-256 checksum, and installs to ~/.local/bin. Five builds ship per release: macOS on Apple Silicon and Intel, Linux x64 and arm64 as fully static musl binaries that run on any distro, and a Windows x64 executable. There is no runtime to install, because there is nothing interpreted inside: the binary is the whole product.
Run orcacode and it starts against a local Ollama server with no key at all; /provider switches to OpenAI, OpenRouter, or a ChatGPT subscription through device login. The product page has direct download links for every platform.
The same work on roughly half the tokens.
The claim that matters is measurable, so we scripted it: 16 tasks over a synthetic project fixture, three repetitions each, four harnesses driven headless on the same model (anthropic/claude-haiku-4.5 through OpenRouter) with the same prompts, tools policy, timeout, and step ceiling. The baselines are the two harnesses a public third-party comparison crowned, Oh My Pi on correctness and Pi on efficiency, plus Claude Code.
Where does the difference come from? A small core toolset with tight schemas, so every turn re-reads less. Truncation that caps tool output before it floods the context, while keeping the full result pageable through read_tool_result instead of forcing a re-run. MCP schemas that stay deferred until the model actually selects a tool. And a kernel that adds nothing else to the conversation. Token efficiency is not one feature; it is the accumulated absence of waste, compounded over every turn of every task.
Six megabytes, eight megabytes resident, one process.
The efficiency discipline that saves tokens also shrinks the artifact. No bundled JavaScript runtime, no helper processes, no wrapper scripts: a stripped, fat-LTO Rust binary that cold-starts in 3.3 ms and idles at about 8 MB of memory.
Small is not an aesthetic. A harness this light is cheap enough to spawn per session, per sandbox, per CI job; it starts before you finish pressing enter; and it leaves the machine's memory to the compilers and test suites the agent is there to run.
The second copy is the one that costs you.
On a laptop the difference between 8 MB and 400 MB resident is invisible. On a host running agents for other people it is the whole bill. A harness is not one process on one machine; it is one process per session, per branch under review, per nightly job, per sandbox handed to a customer. At that point footprint stops being a spec and starts setting how many agents fit on a box, which is the number the invoice is computed from.
The same three numbers decide it. Resident memory sets density, so the gap between 8 MB and a few hundred is the difference between packing agents by the hundred and packing them by the dozen. Cold start decides whether a session can be created on demand or has to be kept warm, and a process that is ready in 3.3 ms can simply be started when the request arrives, which means idle capacity you are not paying to keep alive. Shipped size decides how fast a sandbox becomes useful, because an image layer measured in single-digit megabytes pulls and starts in the time a heavier one spends unpacking.
This is why the kernel is a Rust binary with no interpreter under it rather than a package on top of a runtime. Sandboxes are the sharpest version of the constraint: per-tenant isolation means a fresh environment for every session, and anything the harness carries is paid for again on every one of them. Orca runs this shape in production, which is where the requirement came from in the first place. The platform side of that story is in agent applications are not agent infrastructure.
Everything a daily driver needs, none of what it does not.
Each turn renders a transcript spine with a live activity rail; parallel tool calls, subagent trees, and background work collapse into expandable records. Prompts queue while a run is in flight, Esc cancels a run and kills the processes it spawned, and the clipboard reaches through SSH via OSC 52.
The safety column is worth a pause. Plan mode is an allowlist, not a denylist, because MCP servers and skills add tools the CLI has never heard of, and unknown must mean denied. The write guard refuses to overwrite a file the model has not read through the harness. And yolo mode, which exists because sometimes you do want approvals off, is never persisted and never quiet: the status line says yolo for as long as it is on.
Stop the model for security. Defer to it everywhere else.
A harness encodes an assumption about how much the model can be trusted to figure out on its own, and that assumption is the thing most likely to be out of date. The frontier today is crowded: nine different creators are within ten points of the top of the Artificial Analysis Intelligence Index, and the cost of a task across those nine spans 8.7x. Capability at that level is no longer scarce, and it is not concentrated in one lab whose habits you could design around.
Two things follow. Because the models are close, a harness tuned to one model's quirks is tuned to a moving target, so the loop stays generic and the model choice stays yours. And because the models are capable, scaffolding meant to compensate for weaker ones has become a cost rather than a safeguard. Prescribed tool orderings, retry ladders that re-explain a task the model already understood, and framing repeated every turn all bill as intelligence without adding any, which is the same waste the token section measured, arriving through the loop instead of the schemas.
So the kernel draws its line at consequences rather than competence. It intervenes where a wrong answer is expensive to undo: tools stay behind an allowlist, plan mode denies anything it has not been told about, the write guard refuses to overwrite a file the model has not read, and approvals sit in front of the actions that touch your machine. Within that boundary the model picks its tools, orders its own work, and decides when to spawn subagents. The harness does not have an opinion about how the job gets done.
The judgement it deliberately does not make is what your work should look like, because that is the one thing it cannot know. Which conventions your repository follows, which steps your review demands, which service is the one that must never be touched on a Friday: none of that is derivable from the kernel, so the kernel does not guess at it. It is expressed where it belongs, in Agent Skills and Agent Plugins that you write and version, which is what the rest of this post is about.
Customization all the way down.
Every layer above the kernel is meant to be changed. Providers: any OpenAI-compatible endpoint, OpenRouter's full catalog with a model picker, a ChatGPT subscription via device login, or local Ollama, with keys and preferences persisting per provider. Standing instructions load from AGENTS.md at three scopes (machine, project, checkout), the same convention other agents already read, so one file serves them all. Themes, extension toggles (output truncation, tool retry), tool allowlists for headless runs, and MCP servers are all managed from inside the session and persist to one config file.
MCP deserves its own line, because it is where most harnesses quietly bleed tokens. Orcacode exposes three stable meta-tools (mcp_search_tools, mcp_select_tool, mcp_features) instead of dumping every server's full schemas into context; a tool's real schema appears only after the model selects it, and guessed tool names are rejected until then. Connect a ten-server setup and the model-facing surface stays constant. The Orca platform reaches the same result from the other side, keeping full schemas in its MCP bridge and handing the model a small card on demand; that took one stress-test tool from an estimated 54K tokens to 1.3K, which we measured in how we cut MCP tool-schema tokens by 97%.
Think on a frontier model. Do the legwork on a cheap one.
A coding task is not uniform. Deciding the approach, holding the whole change in view, and judging whether the result is right are the parts that need the strongest model you can afford. Writing the component once the shape is settled, applying a mechanical edit across twelve files, or running something and reporting what happened are not. Those are also where most of the tokens go, which means paying frontier prices for all of it is paying a premium on the majority of the work that benefits from it least.
So the subagent tool takes a model per call. The orchestrator, the model you are talking to, keeps the plan and spawns workers, and it names which model each worker runs on. Choices are grouped into four tiers, and the prefix is the whole interface:
local/qwen3-coder-next free, on your machine, 256K context
flash/deepseek-v4-flash $0.04/M in $0.08/M out
mid/kimi-k2.7-code $0.67/M in $3.40/M out
frontier/claude-opus-5 $5.00/M in $25.00/M out
That spread is the point. A worker that writes a component to a spec the orchestrator already wrote can run two orders of magnitude cheaper per token than the model that wrote the spec, and the review can come back to a frontier worker at the end, where a wrong judgement is expensive. The local/ tier matters for a different reason: it runs against Ollama on your own machine and is offered whether or not you have an API key, so work that must not leave the building has somewhere to go without turning the rest of the session off.
Everything about that is yours to move. /subagents opens a picker for which model serves each tier, along with nesting depth, step ceiling, timeout, output cap, and retries, and /subagents 3 sets depth directly. Worker budgets default below the orchestrator's on purpose, at 24 steps and five minutes, because a worker that has stopped making progress should surface rather than keep spending. The catalog itself is static by design: a model you named that is not reachable fails in the open instead of being quietly swapped for something else, which is the kind of substitution you want to hear about rather than discover in a diff.
Agent Plugins: portable packages, guarded hooks.
Orcacode is an Agent Plugins 1.0 client: plugins package Agent Skills and MCP-over-stdio servers in a portable layout that other compliant hosts can also load. All three are open specifications rather than our own formats, which is the point: a plugin you write here is not stranded here. Scaffold one in Python or TypeScript, validate it, exercise it, then install and enable:
orcacode plugin init review-loop --py
orcacode plugin validate ./review-loop
orcacode plugin test ./review-loop
orcacode plugin install ./review-loop
orcacode plugin enable review-loop
On top of the portable spec, Orcacode adds lifecycle hooks as a client extension: before_tool can allow, deny, or rewrite a tool call before it executes, after_tool can replace its output, and observation hooks watch the run. Hooks are structured process launches with one JSON object on stdin, a bounded timeout, and a sanitized environment; a deterministic hook failure stops the run instead of silently bypassing policy. Plugin skills join the ordinary skills catalog, and plugin MCP servers appear read-only in /mcp. Installation links the source directory rather than copying it, and everything starts disabled until you enable it.
The same crates are an embeddable Rust SDK.
Orcacode is a host built on library crates, and those crates are the SDK. Embed the kernel and you get the same loop, dispatcher, concurrency semantics, cancellation, and limits the CLI ships with:
use orca_harness_core::Agent;
use orca_harness_model_providers::openai::OpenAiModel;
use orca_harness_tools::{core_tools, Workspace};
let model = OpenAiModel::new("gpt-4o")
.api_key(std::env::var("OPENAI_API_KEY")?);
let ws = Workspace::current_dir()?;
let mut agent = Agent::new(model)
.extension(EventStream::new(sink)); // typed NDJSON-ready events
for tool in core_tools(&ws) { // shell, files, search, compute
agent = agent.tool_arc(tool);
}
let result = agent.run("Fix the failing test").await?;
The SDK guide in the field manual covers setup, models, tool presets, runs, sessions, memory, skills, MCP, recovery, and errors, with runnable examples. Testing is first-class: a scripted fake model drives the kernel end to end in integration tests, so an agent you embed can be tested without a provider key. Extensions compile their hook subscriptions into per-event arrays, so the extensibility you do not use costs an empty-slice check.
A field manual, a fleet runtime, and a measured roadmap.
Orcacode ships with a complete field manual: install, approvals and plan mode, providers, tools, memory, sessions, subagents, MCP, skills, plugins, the SDK embedding guide, headless automation, troubleshooting, and the benchmark methodology with its checked-in results. Headless mode is part of the product, not an afterthought: -p for one-shot prompts, --json for NDJSON harness events, --bare and --tools for locked-down automation.
The roadmap follows the same rule that built it: nothing lands on the hot path without a benchmark, and nothing joins the kernel that could be an extension instead. If you want the numbers behind every claim in this post, the deep dive has all of them, with run IDs. If you just want an agent that is fast, cheap, and yours to shape:
curl -fsSL https://orcapods.ai/orcacode.sh | sh
orcacode