Features
Everything in the box,
grouped sensibly.
Six groups, in the order the work moves through them: planning, building, review, deployment, control and visibility. If a capability is not on this page, we have not built it — the things we intend to build are dated on the roadmap.
Group one
Planning and coordination
The part a code generator skips. Work is read, understood and ordered before anything is written.
The request board
File work as a request with a type and a priority. Reorder it, park it, archive it. The board is the single place the state of everything lives.
Plain-English plans
The Project Manager turns a request into a plan summary you can read in a minute — what it intends to do and why, before it does any of it.
Task dependency graphs
Tasks carry a depends_on relationship, so a migration lands before the code that reads from it and unrelated work runs side by side.
Owners on every task
Each task is assigned to the role that should hold it: architect, backend developer, database engineer, QA engineer, and the rest of the team.
Approval gates
Plans wait for your approval unless you have deliberately raised the autonomy level. Approve, edit, or send it back with what it missed.
Talk to the Project Manager
Chat about a project when you are still working out what you want. The conversation can become a request when it is clear enough to plan.
A director brief
The Executive Director frames a request against the project as a whole before the tasks are drawn up, so plans are not written in a vacuum.
Capability substitution
Work planned for a role your team does not have is reassigned to a role that can cover it — and the substitution is recorded, never silent.
Projects and repositories
A project holds connected git repositories and its own team of specialists. Work spanning a front end and an API is still one request.
Group two
Building
Parallel work that cannot collide, because no two tasks share a working directory.
A branch per task
Every task runs on its own branch, cut from the base branch you nominate, and merges back into it once the gates pass.
An isolated git worktree
Each branch gets its own worktree on disk. One specialist cannot read another's half-finished edit, because it is not in its directory.
Parallel dispatch
Independent tasks run at the same time. Dependent tasks wait, visibly, until the work they need is finished.
Fourteen specialist roles
From Architect and Security Engineer to iOS and Android Developer. Staff a project with the roles it needs and leave out the rest.
Agents that ask questions
A specialist facing genuine ambiguity pauses mid-run and puts the question to you, rather than picking an answer and building on it.
Design previews
Front-end tasks produce a shareable preview link, so the people with opinions can look while changing it is still cheap.
Cheap abandonment
Killing a task deletes a branch. Nothing has reached your default branch, so there is nothing to unpick.
Existing codebases
Role contracts instruct every specialist to read your conventions, make the smallest safe change, and reuse patterns rather than invent new ones.
Model and effort per run
Override the model and the effort level for a project, or for the single request that deserves more thought than the rest of the queue.
Group three
Review and quality
Gates before speed. Governance roles read the work rather than produce it, and they can reject.
Roles that require review
Flag any role as requiring human review. Dependent work then stops until a person approves — at every autonomy level, with no override for urgency.
Structured completion reports
Every task ends with a summary, files modified, risks, assumptions, recommendations and blockers. The same shape every time, so it is skimmable.
Code review as a role
The Code Reviewer reads the diff against your contracts and can send work back. A reviewer that can only approve is decoration.
A security pass per request
The Security Engineer reviews exposure on the work in front of it. Not a scan bolted on at the end of the quarter.
QA as a distinct role
The QA Engineer checks the work against what the request actually asked for, which is a different question from whether the code is good.
Architectural review
The Architect reviews shape and fit before and after the build, so a fast change does not quietly become a structural one.
Blockers surfaced early
A task that cannot finish says so in its report, with the reason, instead of producing something plausible and leaving you to find out.
Nothing merges quietly
You see the diff, the reviewer's verdict and the security note before the branch goes anywhere near your base branch.
Editable role contracts
Every role's behaviour is a Markdown document. Tighten a standard, loosen one, or write the rules your codebase already lives by.
Group four
Deployment and operations
Past the pull request, which is where most of this category stops. Your servers, your commands.
Deployment targets over SSH
An SSH host with a deploy path. No agent is installed on your machine; Capybari runs the commands you gave it and nothing else.
Your deploy command
Whatever your deployment already is — a script, a compose file, a systemd restart — stays what it is. We run it, we do not replace it.
Health checks
A deploy is not called good because it finished. It is called good because your health check came back healthy.
Automatic rollback
A failed health check runs your rollback command and restores the last commit known to be healthy, without waiting for anyone to wake up.
Diagnostics on demand
A diagnostics command you define gives an investigating agent something reliable to run when it needs to know what the host thinks is happening.
Deployment runs, in phases
Merge summary, deploy output and health-check output are kept with the run, so the post-mortem has something real to read.
Production investigations
A failed run opens an investigation with an agent assigned. Access is read-only by default and only becomes write access if you grant it.
Follow-up requests
An investigation can open the request that fixes the problem, linked back to the run it came from, so the history reads in order later.
Merge into your history
One branch per task, one report per branch. Your git log stays something a human can still read next year.
Group five
Control and configuration
Every one of these is yours to set, and every one of them is reversible.
Three autonomy levels
Manual, Supervised and Autonomous, set per project. Start where nothing runs without you and climb only when the plans stop surprising you.
Per-project teams
Choose which specialists exist on which project. A marketing site does not need a database engineer; your billing service probably does.
Contracts you can edit
Role behaviour is Markdown, versioned and readable. Change it and the next run follows the new contract.
Investigation access levels
Read-only by default. Raising an investigation to write access on a production host is a deliberate act you take one investigation at a time.
Model and effort overrides
Set the model and effort for a project, or override both for a single request. Cheap work stays cheap; hard work gets the headroom.
Base branch control
Tasks branch from the base you nominate and merge back into it. Your branching model does not have to change to suit ours.
Owner and admin roles
Capybari is multi-tenant with owner and admin roles, so an organisation can decide who may change a deployment target and who may not.
Usage per agent account
Agent accounts track their own usage, so cost is attributable to the work that caused it rather than to a single line on an invoice.
An admin dashboard
Organisation-level administration in one place: members, projects and the accounts running your work.
Group six
Visibility
Show the work. An organisation you cannot observe is not one you can trust, however well it behaves.
The board
Requests, planned tasks, running work, review gates, deployment runs and open investigations, in one view rather than five tools.
Live run streaming
Watch a task as it works: the commands it runs and the output it gets back, streamed while it happens rather than summarised afterwards.
Reports you can skim
Summary, files modified, risks, assumptions, recommendations, blockers. The same six headings on every task, which is what makes them fast to read.
Plan summaries
The intended shape of the work in prose, on the board, before any of it is built.
Dependency state
See which task is waiting on what. Work that has stalled looks stalled, instead of looking like nothing.
Shareable design previews
Send a preview link to someone who has never seen the board and has no intention of learning it.
Deployment history
Every run keeps its phases and its output, including the ones that rolled back. Especially the ones that rolled back.
Investigation summaries
A written cause and resolution you can read, forward, or paste into the update you owe a customer.
Usage you can attribute
Runs are the unit of work and the unit of billing, so what you spent maps to what got done.
In context
Capybari, an AI coding assistant, and a contractor
Three different things that all end with code in your repository. Here is where each of them actually helps — including the rows we lose.
| Capybari | AI coding assistants | Hiring contractors | |
|---|---|---|---|
| Plans the work before writing it | You plan; it types | ||
| A dependency graph across parallel tasks | — | In someone's head | |
| Isolated branch and worktree per task | — | Whatever they do locally | |
| Review by a role that can reject the work | — | If you hire a second one | |
| A security pass on every request | — | Rarely in scope | |
| Deploys to your own servers | — | ||
| Health check with automatic rollback | — | Only if you asked for it | |
| Investigates a production failure at 3am | — | During office hours | |
| Runs while nobody is at a keyboard | Needs you in the chair | — | |
| Sits in your editor as you type | No — different job | — | |
| Judgement about your market and your customers | No. It knows the repository, the request and its contracts. That is all | — | Yes, and it is why you hire people |
| Ready for enterprise procurement | Not yet — see pricing for the list | — |
The last three rows are the ones we lose, and they stay in the table. A comparison with nothing but ticks in our column would tell you more about our marketing than about our product. Cursor and its relatives are genuinely excellent at the thing they do — they are complementary to this, not competitive with it.
Questions
What people ask about the list above
Which of these need a server connected?
Only deployment, automatic rollback and production investigations. Planning, building, review gates, reports and design previews all work with a git repository and nothing else.
Plenty of teams run Capybari to the merge and handle deployment themselves.
Do I have to use all fourteen roles?
No. Staff a project with the roles it needs. Work planned for a role that is not on the team is reassigned by capability substitution, and the substitution is recorded so you can see it happened.
Can I change what a reviewer enforces?
Yes. Each role's contract is a Markdown document you can edit. If your codebase has a convention worth defending, write it into the Code Reviewer's contract and it will be defended on every task.
Is there an API?
A public API is on the roadmap rather than in the product today. We would rather say that plainly than let you find out after you have signed up.
How does this compare on price to a contractor?
We meter agent runs — one task executed end to end by one specialist — because that is the thing that produces something. The pricing page shows the tiers and the included runs. Going over your allowance bills at the overage rate; it never blocks a deploy mid-pipeline.
What about SSO, SOC 2 and an uptime SLA?
We do not have them. They are on the roadmap with the quarters we expect them in, and the Enterprise section of the pricing page lists exactly what is missing. If procurement needs those today, we are not your platform yet.
Where do I see all of this working together?
The platform page walks one request through all six stages in order, and the agent team page explains how the specialists divide the work between them.
Looking for something not listed? Tell us what it is.
Read the list, then file something
Connect one repository and file one request. The free plan runs at Manual autonomy, so nothing on this page happens until you press something.
No card required · Free plan forever · Export everything, any time