Coroid is a hosted platform that does software work end to end. You give it a description of what you want; it produces a pull request against your repository with the code written, the tests run, and a review already attached.
There is nothing to install and nothing to run. Coroid clones your repository into its own sandboxed workspace in the cloud, works there, and pushes a branch.
What you give it
A description of the outcome you want, in plain language. "Add rate limiting to the public API, 100 requests per minute per key, return 429 with a Retry-After header" is a good task. You do not write the implementation plan — that is the first thing Coroid does for you, and you get to approve it.
You also give it access to one repository, and optionally any context that is not obvious from the code: architecture notes, conventions, a style guide.
What you get back
A pull request, on its own branch, containing:
- the code change
- the tests that were written or updated
- the result of running your existing test suite
- a code review pass, with findings either fixed or listed
You review and merge it the way you would review a colleague's work. Coroid does not merge for you.
You do not need to be an engineer to use it
This is the part that changes how teams work, and it is easy to miss.
Submitting work to Coroid means describing an outcome. It does not mean reading code, understanding how the code works, or knowing what a pull request contains. An intern, a marketing manager or a support agent who keeps hearing the same complaint can all file work directly.
Engineering stays in control at the point that matters: the pull request. Every request — whoever it came from — arrives as a reviewed, tested change that a developer approves or rejects before anything ships.
What that does to the backlog
Prioritisation exists mostly because engineering time is scarce. A request that would take an afternoon has to be weighed against everything else an engineer could do with that afternoon, so small, obviously-useful work sits unbuilt for months.
When the cost of attempting a request drops to an agent slot and some tokens, that calculation changes. Work that would never have survived prioritisation can simply be attempted, and judged on the result rather than on a guess about its value.
Be clear-eyed about what still bounds you: review capacity and agent slots. Coroid removes the constraint on who can ask and how much gets built in parallel. It does not remove the need for someone to read the result. Teams that adopt it well tend to find review, not building, becomes the thing to organise around.
Coroid runs its own agents
Coroid is not a wrapper around Claude Code, Codex, OpenCode, Pi, or any other coding harness. It runs a purpose-built agent runtime designed for unattended cloud execution.
For you, that means:
- Nothing to install. No CLI, no editor plugin, no machine or server to provision. Coroid is entirely API-based and runs in the cloud.
- No tool subscriptions. You do not need seats for a third-party coding assistant. Model access runs through Coroid, or through your own provider keys if you would rather contract directly.
- Your laptop is irrelevant. Work continues whether or not anyone is logged in — which is what makes schedules, monitors and event-driven automation possible at all.
See The Coroid harness for what the runtime actually does differently.
Is Coroid the right tool?
Coroid is built for changing a codebase you already run, under review. That is a different job from prototyping — if you are validating an idea rather than shipping it, a prototyping tool will serve you better, and the two compose well.
See Where Coroid fits.
What it does not do
Being precise about the boundaries matters more than the feature list:
- It does not commit to your default branch. Everything arrives as a PR.
- It does not merge its own work. Approval is yours.
- It is not an editor plugin. Coroid is not a coding assistant that completes lines as you type. It operates on whole units of work while you do something else.
- It does not work without a connected repository. See Connect your code.
How work is sized
Coroid works in tasks. A task is one unit of work that ends in one pull request. Larger efforts are expressed as a plan — an ordered set of tasks with phases — which you approve before anything is built.
The unit of parallelism is an agent slot. One slot runs one task at a time. How many slots you have determines how much Coroid can do at once, not how fast any single task completes.
Next
Create your account and organization — set up the workspace your work will live in.