Most AI coding tools are harnesses: a loop around a model, plus tools for reading and writing files and running commands. Claude Code, Codex, OpenCode and Pi are all harnesses, and they are built for a developer sitting at a terminal.
Coroid does not use any of them. It runs its own.
Why not wrap an existing one
The tools above are designed around an attended session. Someone is watching, can answer a question, can interrupt, can notice that it has gone wrong. That assumption is reasonable and it shapes everything — how errors surface, how much context is carried, what happens when the model returns something unexpected.
Coroid's assumption is the opposite: nobody is watching. Work runs in the cloud, triggered by a schedule, a monitor or an event, and it has to arrive at a reviewable result or a clear failure without anyone to catch it mid-run.
Those are different problems. Several things below exist because of that difference and would not make sense in a terminal session.
What the runtime does differently
It expects to be alone. When a model returns a malformed response or a mangled tool call, the loop repairs and retries rather than surfacing a prompt nobody is there to answer. An unattended run that stops to ask a question it could have resolved is a wasted slot.
It is multi-agent by construction. The loop is built around a handoff between roles with different permissions, not a single agent doing everything. Verification is performed by an agent that did not write the code, which is a property you get from the architecture rather than from asking nicely.
It has explicit budgets and depth limits. Every execution runs against a token budget and a step ceiling. Without them, an unattended agent that has misunderstood its task will keep going.
It carries governance inline. Policies, quality gates and approval checkpoints are part of the execution path rather than a wrapper around it, which is why a blocking gate can stop work mid-run instead of after the fact.
Caching is a first-class concern
Context is most of the cost of running agents, and in a cloud harness the same project context is read over and over across many tasks.
The runtime leans on prompt caching heavily for that reason. You can see it working in a task's execution trail, where steps report their cache efficiency:
9.1k used (90% cached)A high cache-hit rate is the difference between an expensive run and a cheap one. It is also why a well-structured project with clear context costs less to work in than a sprawling one — stable context caches well, and context that changes every run does not.
This pairs with progressive skills, which keeps the loaded context small in the first place.
What it means practically
- No local setup. No CLI, no editor plugin, no runner to host. Coroid is API-based and runs in the cloud.
- No third-party tool subscriptions. You are not buying seats for a coding assistant on top of Coroid. Model usage is billed as credits or through your own provider keys.
- Work runs unattended. Schedules, Sentinel and hooks are possible because nothing depends on a developer's machine being awake.
- Behaviour is consistent. Everyone's work runs on the same runtime with the same policies, rather than depending on what each developer has installed and configured.
What it does not change
The harness decides how work gets done. It does not change the boundaries: everything still arrives as a pull request on a branch, nothing is merged for you, and your branch protection and review rules apply exactly as they do to human contributors.