# Orbi — Open-source agent line turning labelled GitHub Issues into reviewed merges and tagged releases, self-hosted or hosted.

> Source: The Agents Index — https://theagentsindex.com/orbi (structured, researched, re-verified)
> Facts last verified: 2026-10-14

Orbi is an open-source, self-hostable delivery line that takes a labelled GitHub Issue through an AI coding session, an independent AI review that repairs the branch, an exact-head merge and a tagged GitHub Release. Orbi Cloud runs the same loop as a hosted runner.

| Fact | Value |
| --- | --- |
| Website | https://orbi.build/ |
| Price | free, then from $29/month billed monthly, $24/month billed annually |
| Free tier | Yes |

Self-hosting is free forever under AGPL-3.0 or the Sustainable Use License (US$0, bring your own model key). Separately, Orbi Cloud starts with a trial of 3 successful merged deliveries, no credit card required, and failed deliveries don't count.

## What it does

**Writes code** · Yes — An Issue labelled ai-ready is implemented by a coding session in an isolated git worktree, so new code is authored from the Issue description rather than from a chat prompt.

> Orbi picks it up and writes the code in an isolated worktree.
> — https://orbi.build/ · How Orbi automates GitHub Issue to tagged release, step 01 'Label an Issue ai-ready'

**Debugs and fixes** · Yes — The independent review session does not only comment: it edits the branch, reruns the full suite against its own repairs and judges the repaired head, which is the diagnose-and-fix loop.

> The reviewer changes code, reruns the suite, and judges the repaired head.
> — https://orbi.build/ · Production evidence section, bullet 01 'Independent review that can fix'

**Writes tests** · Partly — Deliveries are gated by the repository's own test suite and coverage tiers, and the documented contract requires tests in the same PR, but the site never advertises test authoring as a standalone capability.

> When you change code, update or add tests in the same PR and keep the coverage gate green.
> — https://docs.orbi.build/testing · Testing page, closing paragraph under 'What the tests cover'

**Reviews code** · Partly — Review is the core of the product, but it reviews the diff Orbi's own implementing session produced; the site documents no path for reviewing a pull request a human opened.

> It checks the PR against the Issue's acceptance criteria and fixes what fails.
> — https://orbi.build/ · How it works, step 02 'A second session reviews it'

**Whole-codebase work** · Partly — It works inside a whole existing repository including large ones, but each tick handles at most one Issue and the vendor states there is no task DAG, so a staged multi-Issue migration is not orchestrated for you.

> Orbi has no task DAG, multi-agent parallelism, risk model, policy engine, or fallback path.
> — https://docs.orbi.build/security · Security page, 'Delivery boundaries' bullet list

**Ships it** · Partly — It goes past the diff to a merged commit, a frozen SHA, a git tag and a published GitHub Release, but a human must label the release Issue and nothing is deployed to your infrastructure.

> Releases are never automatic. You open the release Issue and apply the ai-release label — a label only humans set.
> — https://orbi.build/cloud/ · What Orbi Cloud is, 'RELEASES — You start the release, Orbi runs it'

**Done-for-you service** · No — No people are sold with it: you either run the open-source runner yourself or subscribe to a hosted runner on the vendor's machines, with setup described as a GitHub sign-in and App install.

> Orbi Cloud runs the same GitHub-native delivery line as self-hosted Orbi — Issue in, worktree, tests, independent review and repair, exact-head merge — on infrastructure we operate.
> — https://orbi.build/cloud/ · What Orbi Cloud is, opening paragraph

## How much it does unattended

**Runs autonomously** · Yes — From a labelled Issue to a merged pull request nobody is required in the loop; the human gates are the ai-ready label at the start, branch protection, and the release label at the end.

> AI coding agents write the code, a separate AI reviews it, and Orbi merges and ships the release with nobody watching.
> — https://orbi.build/ · Hero paragraph under 'File an Issue. Get a release.'

**Multi-agent** · Partly — Two separate sessions act on one delivery, implementer and independent reviewer, optionally on different models, but the vendor explicitly denies multi-agent parallelism or a task graph.

> A second session that did not write the code reviews the PR and fixes findings in-session. `review_pi_*` lets that session run on another model.
> — https://docs.orbi.build/ · Docs index, 'What makes it different' card 'Independent review, optionally on a different model'

**Agent permissions** · Partly — The agent is fenced hard: it commits but never pushes, never opens the PR, never merges and never touches protected branches; only the runner process merges, and only the reviewed head.

> The Pi does not merge, does not push `main`/`master`, does not force push, and never auto-resolves conflicts.
> — https://docs.orbi.build/security · Security page, 'The AI never merges or pushes protected branches', first bullet

## Which models it runs on

**Claude** · Partly — The vendor states Orbi can wrap Claude Code as the coding engine inside its delivery line, but no Anthropic entry appears in the published provider template catalogue, so it is a claim without a configuration recipe.

> Orbi is not a Claude Code alternative: it can run Claude Code as the engine inside its own delivery line.
> — https://orbi.build/compare/claude-code/ · 'Claude Code alternatives' section, opening bold sentence

**GPT** · Yes — An OpenAI path is documented two ways: a ChatGPT/Codex subscription login inside an interactive session, and a GitHub Models template pinning an OpenAI model id in the provider catalogue.

> A ChatGPT/Codex subscription works too: run `/login codex` inside an interactive `pi` session.
> — https://orbi.build/guides/self-hosted-coding-agent/ · 'What running it on your own machine takes', step 02 MODEL

**Open models** · Yes — Open-weight models are a first-class path: a local Qwen template ships with the provider catalogue, and any OpenAI-compatible local server fills the same slot with no vendor key.

> The [providers guide](https://docs.orbi.build/providers) ships a Local Qwen template (`local-qwen.json`, Qwen3.8-27B), and any OpenAI-compatible endpoint fits the same slot.
> — https://orbi.build/guides/self-hosted-coding-agent/ · FAQ 'Can I use a local model?'

**Model choice** · Yes — You choose the model when self-hosting and can change it later by editing two selectors; Cloud includes a default model instead, with bring-your-own-key supported there as well.

> Orbi drives the agent through your credentials, using any OpenAI-compatible API or a locally hosted model, and you can change your mind later without changing your workflow.
> — https://orbi.build/ · FAQ 02 'Which AI models can I use?'

## Where you use it

**In your editor** · No — The vendor positions Orbi against editors rather than inside them: there is no IDE or editor extension, and the product is defined as what runs when nobody is typing.

> Those are editors — they make you faster while you are typing. Orbi is what happens when nobody is typing
> — https://orbi.build/ · FAQ 03 'How is this different from Copilot or Cursor?'

**On the command line** · Yes — The self-hosted product is a command-line runner: an orbi CLI with setup, doctor and sync subcommands, started by a systemd user timer on Linux or launchd on macOS.

> `orbi setup` checks the prerequisites; it never installs system packages or `gh` for you.
> — https://orbi.build/guides/self-hosted-coding-agent/ · 'What running it on your own machine takes', step 01 INSTALL

**In your pipeline** · Yes — It acts on pull requests end to end and is bound to your CI result: the merge gate requires a concluded, mergeable check state, and the release gate uses the repository's GitHub Actions run.

> The release's test acceptance is your repository's CI result — the GitHub Actions check runs on the release commit
> — https://orbi.build/cloud/ · What Orbi Cloud is, 'RELEASES — You start the release, Orbi runs it'

**In a browser** · Partly — Cloud adds a hosted web path, with GitHub sign-in, a connect page and a status page, while the self-hosted core is documented as having no web UI at all.

> GitHub Issues and labels are the only state store; Orbi has no database, message queue, or web UI.
> — https://docs.orbi.build/security · Security page, 'Delivery boundaries' first bullet

## Whose machine it runs on

**Self-hosted** · Yes — Running it on your own machine is the primary mode, with your repository, keys and test suite staying local and nothing uploaded to the vendor.

> Self-hosted: your repository, keys, and test suite stay on your machine; nothing is uploaded to us.
> — https://orbi.build/ · FAQ 01 'What does Orbi actually need to run?'

**Open source** · Yes — The core runner is published source under a copyleft licence, with an alternative non-AGPL licence offered for teams whose policy rules out AGPL, and self-hosting free under either.

> Open source under [AGPL-3.0](https://github.com/orbi-build/orbi/blob/main/LICENSE), or the [Sustainable Use License](https://github.com/orbi-build/orbi/blob/main/docs/licenses/sustainable-use-license.md) if your policy rules out AGPL.
> — https://orbi.build/ · FAQ 06 'Is it really free, and what is Managed Cloud?'

## What it costs to run

**How it meters** · Yes — Cloud is a flat monthly subscription with a monthly token allowance and a repository count, not a seat price; self-hosting carries no platform fee and you pay your model provider per use.

> Solo includes 400M tokens a month and Pro includes 1.2B tokens a month. When the applicable allowance runs out, new deliveries pause — there is no per-token overage billing.
> — https://orbi.build/cloud/ · 'Before you start' FAQ 02 'What happens when the monthly tokens run out?'

**Free tier** · Yes — Two free routes with no sales call: the self-hosted core is free forever under either licence, and Cloud starts with three merged deliveries without a credit card.

> Self-hosted: US$0 under AGPL-3.0 or the Sustainable Use License; bring your own model key.
> — https://orbi.build/cloud/ · Pricing section, line under the Solo and Pro plan cards

**API access** · Partly — You drive it from your own stack through GitHub itself and the orbi CLI rather than an Orbi API: the vendor states the product exposes no database, queue or web service of its own.

> GitHub Issues and labels are the only state store; Orbi has no database, message queue, or web UI.
> — https://docs.orbi.build/security · Security page, 'Delivery boundaries' first bullet

**Bring your own key** · Yes — Bring your own model is the self-hosted default and spend goes straight to your provider; Cloud also accepts a customer-configured key, stored encrypted and decrypted only for runner injection.

> Model API keys: BYOK keys are stored AES-GCM encrypted in the control plane; API reads return only a masked value, and decryption is only for runner injection.
> — https://orbi.build/cloud/ · 'Before you start' FAQ 04 'Can you see my code?'

## Buying it for a team

**A company can buy it** · Partly — Anyone can subscribe through Stripe self-serve, but the only published plans are a single-repository Solo and a five-repository Pro; no organisation, team or enterprise tier is offered.

> Cloud has two paid plans, Solo and Pro.
> — https://orbi.build/cloud/ · 'Before you start' FAQ 01 'What are the Cloud plans and how do I cancel?'

**Seat model** · No — Nothing is priced or counted per user: the plan limits are connected repositories and monthly tokens, so there is no seat floor, ceiling or per-user charge to negotiate.

> Solo connects up to 1 repository at a time; Pro connects up to 5. Once you reach the limit, deactivate a repository on the connect page before connecting another.
> — https://orbi.build/cloud/ · 'Before you start' FAQ 03 'How many repositories can one subscription connect?'

**Pooled budget** · Yes — One monthly token allowance belongs to the subscription and is consumed by every connected repository, so Pro's five repositories draw on the same balance and pause together when it is gone.

> Solo includes 400M tokens a month and Pro includes 1.2B; when the applicable allowance runs out, new deliveries pause — there is no per-token overage billing.
> — https://orbi.build/cloud/ · What Orbi Cloud is, 'MODELS — Model usage included, cost in the open'

**Admin controls** · Yes — A repository may carry a delivery-policy file whose keys are whitelisted, credential-routing and prompt keys stay host-only, and a file declaring a host-only key fails the claim immediately.

> A repository file that declares any host-only key fails the claim fast and the Issue becomes `ai-blocked` with the offending keys named.
> — https://docs.orbi.build/security · Security page, 'Repository-level config: the trust model'

**Audit log** · Partly — Every delivery action is recorded as inspectable GitHub evidence plus a local journal with run ids and merge facts, but there is no administrative audit log of account or policy changes.

> Issues, labels, comments and the PR are the complete delivery record. Orbi uses no database or second task system.
> — https://docs.orbi.build/ · Docs index, 'What makes it different' card 'GitHub is the whole ledger'

**Single sign-on** · Partly — Sign-in is GitHub OAuth only, with no separate Orbi credential to manage; no SAML or OIDC identity-provider integration is documented on any plan.

> Sign in with GitHub    One OAuth click. Your repositories, your account — no separate Orbi credential.
> — https://orbi.build/cloud/ · 'After you click' step 01

## What happens to your code

**Opt out of training** · Partly — Self-hosting removes the question entirely since nothing is uploaded, but on Cloud the delivery data reaches a model provider and the vendor defers retention and processing to that provider's terms.

> With a customer-configured key, the selected model provider receives that delivery data instead. Provider retention and processing are governed by that provider's terms.
> — https://orbi.build/privacy/ · Privacy policy, 'Processors that make Cloud work'

**Data residency** · Partly — The vendor names its hosting provider and the control-plane store, and worktrees are destroyed after a quiet period, but no country, region or choice of jurisdiction is published.

> The hosted runner runs on machines operated by Orbi at Vultr and clones the connected repository for the duration of a delivery.
> — https://orbi.build/privacy/ · Privacy policy, 'Processors that make Cloud work', closing paragraph

**Getting out** · Partly — Your work never leaves GitHub so there is nothing to export, and account deletion is by email request rather than self-serve; monthly token allowances are stated per month, not as carried credits.

> To request deletion of your Orbi account and associated Cloud records, email privacy@orbi.build with the GitHub account or tenant to identify.
> — https://orbi.build/privacy/ · Privacy policy, 'Access, deletion, and contact'

## What changed

- 2026-10-18 — Website
- 2026-10-14 — Capabilities · Free tier · Price · Terms

## Keeping it current

These facts are re-checked against Orbi's own pages and updated when they change. If you represent Orbi, sign in and update the listing from your dashboard at https://theagentsindex.com/dashboard. The operations this site accepts from an agent are listed at https://theagentsindex.com/.well-known/agents.json — that catalog needs no key to read, and each entry states its own auth.