CheckrailGet a key

Checkrail

Checkrail is a code review API for the pull requests your agents open.

Your agent pipeline calls one endpoint when a draft opens. A code model reads the diff against the agent's ticket and posts comments on the pull request. $0.30 a review, with no hourly cap per developer.

Get a key

POST /v1/reviews with the repository, the pull request and the ticket key.

Back, by signed webhook: every finding and one of three verdicts.

One engineer’s twelve agent pull requests from before standup, each reviewed and grouped by verdict: a person first, back to the agent, ready for a person.

5 an hourreviews per developer on CodeRabbit Essentials

Five reviews per developer per hour. One engineer's agents open twelve before standup.

The cap on CodeRabbit's Essentials plan, $24 a seat billed annually. Team lifts it to eight, at $48.

Before standup, a staff engineer queues twelve agent tasks. Inside the hour, twelve pull requests open. Five get a review.

Seven wait for the next hour or bill $0.25 a file. A forty-file refactor: $10. Reviewers, already the slowest step, open them cold.

Over 5,000 reviews a month · $0.22 each

$0.30 per review

  • One review: one pull request, one head commit, any file count
  • Over 4,000 changed lines: refused with a split suggested, not billed
  • No seats. An engineer who dispatches no agents adds nothing
  • Not billed: indexing, failures on our side, a repeat call on one commit
  • First 300 reviews free. No card, no time limit
  • Price held 24 months. Keys take a spend cap and stop at it

$0.30 a review. Twelve pull requests in one hour cost $3.60.

An Essentials seat is $24 a month, billed annually. Here $24 buys 80 reviews, at any hour, and the forty-file refactor is one review. Past 5,000 reviews in a month, each is $0.22.

Get a key

State as of September

Each review takes minutes, because it reads the ticket and the callers. A key runs 30 at once and queues the rest in order. Today the first wave of a morning waits for GPUs to start.

One finding as the code model proposes it: what it read, its category, a score of 0.87, a suggested patch, and Resolve and Dismiss with no Approve button.

A code model reads each change against its ticket. Findings post at 0.80 or above.

The model is open-weight and Checkrail runs it. Four fixed checks go first: secrets, removed tests, CI and dependency edits, paths another team owns. Their hits always post.

  1. What it read the hunk, its whole file, the callers, the ticket
  2. Category missed the task, went past it, defect, weakened test, security
  3. Score 0.80 posts. 0.50 to 0.80 returns unposted. Lower is dropped
  4. Suggested patch where the model can write one
  5. Resolve, Dismiss each verdict retrains this account's scorer overnight
  6. No Approve button approval stays with whoever CODEOWNERS names

One agent pull request, from the call to the verdict

The step your pipeline adds, the comments on the pull request, the findings held back, and the verdict: back to the agent, ready for a person, or a person first.

One review: the draft opened, the call with the ticket, two findings posted, one held back between 0.50 and 0.80, and the verdict, back to the agent.
The call, the findings posted and held, and the verdict. Held findings come back to your pipeline and are never posted.
The pull request on the code host: a Checkrail comment with its category, score and suggested patch, Resolve and Dismiss, and approval left to the code owner.
On the pull request: a comment with a suggested patch. The approval box still waits for the person the code-owners file names.

Repository, ticket and code are drawn. No customer's pull request appears.

Where the diff is read, and what is left of it after

The open-weight code model and your account's scorer read each diff on GPUs Checkrail runs in Frankfurt, next to where the diff is stored.

  • Checkrail Tecnologia Ltda.

    registered in Curitiba, 2022

  • Two permissions

    read code, write comments

  • Review done

    fetched files and full diff deleted

  • 90 days

    findings and task text, then gone

  • Opt-in only

    pairs that train the shared model

Checkrail comments. Approval stays with a person.

It never approves or merges, and no setting turns that on. The app is never granted the permission.

  • Decidedcomments and a verdict, never an approval or a blocking review
  • Becausethe person who approves answers for the merge. A bot approver answers to nobody
  • Costs youno auto-merge, even for a one-line dependency bump
  • Unchangedthe wait before a reviewer opens it. Only the reading gets shorter

Finance budgets a seat a year ahead. A per-review bill has no fixed line.

Correct. A month of agents running all day costs more than a quiet one.

The screen is one key's month against its cap. A key at the cap stops reviewing.

A $48 Team seat buys 160 reviews here, about eight a working day per engineer. A pull request resent after the agent's fix bills as a second review.

One key’s month against a $48 spend cap, reviews by working day at $0.30 each, and the line where the key stops reviewing.

Count one engineer's pull requests in their busiest hour.

Five or fewer, and the seat plan you pay for reviews them without a queue. Keep it.

One key’s reviews by hour across a working day: a wave of twelve before standup from one engineer’s agents, a smaller one after lunch, an empty night.
  • Your busiest engineer opens more than five in an hour, mostly through agents.
  • No coding agents on the team. Your seat plan covers it.
  • Code may not leave your network. No self-hosted install here; CodeRabbit's needs Enterprise and 500 seats.
  • You want agent work merged without a person reading it.

Drawn here: one key's reviews by hour. The morning wave is a single engineer's agents.

CodeRabbit reviews what opens on four code hosts. Checkrail reviews only what your pipeline sends.

A team that wants every pull request reviewed from one install, hand-written ones too, should keep CodeRabbit.

The one step your platform team adds sits between draft and ready.

The call carries the ticket key or the prompt. Without either, Checkrail checks for defects only.

The agent pipeline with one step added between draft and ready: the call to Checkrail with the ticket key or the prompt, or defects only without either.

The app installs on GitHub, GitLab or Bitbucket. The task comes from Linear or Jira.

Each install needs an admin to approve it. The tracker token reads tickets and writes nothing.

  • GitHubapp on the organization
  • GitLabapp on the group
  • Bitbucketapp on the workspace
  • Linear, Jiraissue key in the call, ticket fetched read-only
  • No trackerthe pipeline sends the prompt text instead
  • Gerrit, Giteano app, so no reviews
GitHubGitLabBitbucketCheckrailLinear, JiraNo trackerGerrit, Gitea

300 reviews free on a key sent to your work address.

Send back your busiest engineer's count: pull requests opened in one hour last week. At five or fewer, we will tell you to keep the seat plan.

  1. Install the app. Add one call after the agent opens a draft, reading the key from Azure Key Vault or your own secret store.
  2. A repository's first call waits for its index. Indexing is never billed.
  3. Set a spend cap before the agents run.
  4. Close the key any time; the last invoice covers finished reviews.

Your request has been received.

Expect a message from Checkrail. It goes to the address you gave.