Documentation

The Coroid harness

Coroid runs its own agent runtime rather than wrapping an existing coding tool, and that choice affects what it can achieve.

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 working 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 for an attended session. Someone is monitoring, can answer questions, can intervene, and can spot when something goes wrong. That assumption is reasonable and shapes everything — how errors appear, how much context is carried, and what happens when the model produces an unexpected result.

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 must produce a reviewable result or a clear failure without anyone to intervene during the run.

These are different challenges. Several features below exist because of this difference and would not be useful in a terminal session.

How the runtime differs

It operates without supervision. When a model returns a malformed response or a faulty tool call, the loop fixes and retries rather than displaying a prompt that nobody is there to answer. An unattended run that pauses to ask a question it could have resolved is a wasted opportunity.

It is inherently multi-agent. The loop is built around a handoff between roles with distinct permissions, not a single agent handling everything. Verification is carried out by an agent that did not write the code, a feature that stems from the architecture rather than a manual request.

It has explicit budgets and depth limits. Every execution runs within a token budget and a step limit. Without these, an unattended agent that has misunderstood its task would continue indefinitely.

It integrates governance directly into the process. Policies, quality checks and approval points are part of the execution path rather than an external wrapper, which allows a blocking gate to halt work mid-run instead of afterwards.

Caching is a core consideration

Context accounts for most of the cost of running agents, and in a cloud-based harness the same project context is accessed repeatedly across multiple tasks.

The runtime relies heavily on prompt caching for this reason. You can see it in action in a task's execution trail, where steps report their cache efficiency:

9.1k used (90% cached)

A high cache-hit rate makes the difference between an expensive run and a cheap one. It also explains why a well-structured project with clear context costs less to work with than a disorganised one — stable context caches effectively, while context that changes every run does not.

This complements progressive skills, which keep the loaded context small from the outset.

What this means in practice

  • No local setup required. No CLI, no editor plugin, no runner to host. Coroid is based on API and runs in the cloud.
  • No third-party tool subscriptions. You are not purchasing licences for a coding assistant on top of Coroid. Model usage is billed as credits or via your own provider keys.
  • Work runs unattended. Schedules, Sentinel and hooks are possible because nothing depends on a developer's machine being active.
  • Behaviour is consistent. Everyone's work runs on the same runtime with the same policies, rather than relying on what each developer has installed and configured. What is installed is detailed in language support and the agent environment.

What remains unchanged

The harness determines how work is carried out. It does not alter the workflow: everything still appears as a pull request on a branch, nothing is merged automatically, and your branch protection and review rules apply exactly as they do to human contributors.