one binary · your own Claude Code

Write the issue. Press Code it. Review the pull request.

Crewbit reads an issue from the tracker you already use and writes the code test-first on your own machine, with the Claude Code you already pay for. A pull request reaches you only after an independent pass has checked it against your acceptance criteria. An issue too thin to plan comes back naming what is missing. It is built for a team that already pays for Claude Code and has a backlog of small, well-understood issues nobody gets to.

Start free Questions and answers

Free plan, no card. The setup is one binary on a machine of yours, and the install guide is all of it. The model is never billed through us: the work runs on the seat you already pay for.

app.crewbit.sh/runs/run_8f2a

Refuse a token whose expiry has passed plan_review

The plan: affected files, approach, ordered steps, and the tests to write first.

Approve plan Reject

Nothing runs past this without you.

This is the path for an issue that needs a plan. One that already says what done looks like can skip straight to code, but the readiness check and the independent review run either way: nobody gets a pull request built on a guess.

Merged is not the same as done

A study of 567 agent-written pull requests across 157 open source projects found 83.8% accepted, and 45.1% of the merged ones still needed a human to change them afterwards. Merge rate overstates ready-without-rework, and a pull request that takes longer to review than to write is worse than none.

Pull requests accepted: 83.8%; Across 567 agent-written pull requests

Merged, then fixed by a human: 45.1%; The number this whole design answers to

From the button to the pull request: 26min; One-line issue, private repository · 65 turns, $5.10 of shadow price, merged the same afternoon

So two steps cannot be turned off. A thin Spec is refused before anything is planned, and no change reaches you until a separate pass has read it against the plan and the test output. Green tests are not evidence on their own, and neither is a confident summary.

The third number is one Run, and the whole issue read: "We should update the config to update the LiteLLM version to 1.100.0, just to staging env." The pull request said which of two files was the config, checked the registry for the version, and named the check it had to narrow. That repository is private. The runner's own is public, and every pull request Crewbit has opened on it is there to read: this one fixed a bug in the runner itself.

What happens to a Spec

You write a Spec
An issue in the tracker you already use. Crewbit refuses one it cannot plan without guessing, and names the acceptance criterion that is missing rather than planning around the gap.
It plans, or Code it goes straight to code
An issue that already says what done looks like goes straight to code. Anything thinner gets a plan first, and the Run waits in plan_review until you approve it, send it back with what you want changed, or end it.
It writes the code, tests first
On your own machine, in a fresh clone with the remote removed, so it has nowhere to push even if it tried. Your project's own verify command is what says the change works.
A reviewer that did not write it judges it
A separate pass reads the change against your acceptance criteria, with the test output as evidence. It defaults to fail: a false pass costs a merged change, a false fail costs one fix round.
You get a pull request worth reading
It carries the plan it worked from and the verify output, and it opens the moment the code is done. A failed review becomes a fix round instead of becoming your problem.

What each part can touch

Four parts, and what each one is allowed to do to your repository.

Plan

Reads the issue against a readiness check, then writes the brief: your acceptance criteria quoted straight from the issue, and how it means to meet each one. It can only read the repository. When the issue leaves a real choice, it asks on the run's own page instead of guessing; it only refuses outright when there is nothing on the issue worth reading.

Code

Writes the tests first, then the change, in a workspace with its git remote removed before it starts. There is nowhere for it to push even if it tried: your runner holds the only credential that can, and it is the one that pushes.

Review

A separate pass that did not write the code reads the diff against each acceptance criterion, with your own test output as evidence rather than a summary it wrote about itself. It defaults to fail: an unproven claim of success counts as failing, not passing.

Pull request

Opens the moment the code is done, carrying the plan or the reading it worked from and the test output. It never talks to GitHub on its own: opening it, updating it and asking for your review are calls the server makes from what your runner already reported.

One page holds every Run and what each one wants

A human watching six repositories checks six Actions tabs and six issue boards. Crewbit holds the state itself, in a schema, so the fix-round count is a column rather than a count of comments somebody can delete. What is in flight and what waits on you is one list.

A Run's own page shows the plan it produced, or why it refused, with the buttons for what happens next, and only the ones the state machine will accept. A button that posts something the state machine would refuse is a button that teaches you to distrust the page.

plan_reviewcodingevaluatingin_reviewneeds_human

app.crewbit.sh/runs

Refuse a token whose expiry has passed run_8f2a · acme/api

Waiting on you

Export the billing report as CSV run_31c7 · acme/web

Writing the code

Retry a webhook that timed out run_5d40 · acme/api

Evaluating

Drop the unused settings column run_a119 · acme/jobs

In review

What it does not do

Stated here rather than discovered later. A page that implies a capability the tree does not have costs more than the capability was worth.

It does not merge anything

The pull request opens the moment the code is done and is marked ready for review only when the review passes. A human merges. The autonomous path is a dead end on purpose.

It does not run without a machine of yours

Work waits in the queue until a runner dials in, and a runner only ever sees its own org's. Cloud runners, which would run on an API key you give us, are a plan and not a feature yet.

It reads specs from GitHub today

The pipeline asks for Capabilities rather than for providers, so a second tracker is an adapter rather than a redesign. No second adapter exists yet.

It does not fix a thin Spec for you

The bottleneck is the spec, not the model. Crewbit tells you what is missing and stops. If your team does not write specs down, this is the wrong tool and the answer will not change.

The model is never billed through us

The work executes on machines you control, driving the Claude Code you are already signed into. Crewbit holds the state and the pull request; your machine holds the code. Nothing on the invoice is a token.

One-turn stage: ~$0.31estimated; Measured $0.25 to $0.33, almost all of it cache creation

A merged Run: ~$8estimated; Roughly $7 to $10 of shadow price, end to end

Billed by Crewbit: $0.00; Per Run. You pay for the platform, not the tokens

Those figures are shadow price: locally computed estimates at list rates under a subscription, not amounts owed. They are here so a Run's cost is legible to whoever approves the spend, not because anybody will send you a bill for them.

One binary, one credential, and the Claude Code you already have.

The free plan is 1 machine, 2 Projects and 5 repositories, enough to decide whether this works on your own code tonight.

Start free See the plans