Billing

We charge for orchestration. We do not charge for inference, and we do not charge for the minutes your own machines spend running your own jobs.

What we never bill for

Tokens. BYOK is the only mode: the agent calls your provider with your key, on your account, and your provider invoices you directly. We are not a reseller and there is no markup, because we are not in the billing path at all. See BYOK.

CI minutes. Jobs run on boxes you own. There is no per-minute meter, no cache egress charge and no static-IP fee. See self-hosted CI.

The seat model

A seat is one AI dev: one concurrent AI-dev runner.

Boxes are fungible: the two servers beyond the AI-dev box serve CI, tests and review at no extra charge. Enrolling past seats × 3 returns 402 Payment Required rather than silently accepting the box.

Work beyond your concurrency waits in the queue. It is not rejected and it is not billed differently, you are buying parallelism, not permission.

Tiers

Current prices are on the pricing page; this page describes the shape rather than restating numbers that live in one place.

There are three plans, and the one you are on follows the GitHub account type your repositories live under.

Solo and Enterprise are bought self-serve.

OSS verification

Public repositories can apply for verified OSS status, which waives the bill. Apply from the dashboard. A human reviews it, submitting the application grants nothing, and approval is not automatic. Verified accounts get full review in advisory mode (comments, never a merge gate) and are never metered.

Auto-merge stays opt-in on free and OSS-verified accounts.

Buying and managing

# Start a checkout for N seats (solo or pro only)
curl -X POST https://api.developerz.ai/v1/billing/checkout \
  -H "Authorization: Bearer dev_pat_…" \
  -H "content-type: application/json" \
  -d '{"tier":"pro","seats":3}'

Scope: write:billing (owner or admin). Seats are granted by the Stripe webhook after payment settles, not by the checkout response. So a completed checkout and an active seat are two separate moments, usually seconds apart.

Invoices, cards and cancellation live in the Stripe billing portal, not in our dashboard. POST /v1/billing/portal returns a one-time redirect URL. We do not mirror your invoices into a second system that could disagree with the first.

Spend caps

The account spend cap is a ceiling on the model spend of every agent session run for your account in the window: the real metered cost of the sessions themselves, summed across your repositories and your account.

There is no default cap. An account has one only if you set one, with PATCH /v1/billing/cap, the dashboard Billing panel, or billing set_cap. Until you do, there is no budget and nothing to enforce. A donated BYOK key is a separate control: it carries a monthly cap of its own even when you set none.

Once you set a cap you get an email when your spend crosses 50%, 80% and 100% of it. One session that jumps past two of those at once sends only the higher notice. At 100% no new sessions are dispatched until the window rolls or you raise the cap; sessions already running finish, so concurrent sessions can take the total a little past it.

Inference is still BYOK, so that spend is on your key, with your provider. The cap does not move money through us; it stops us from dispatching more work once your own metered spend reaches the budget you set. It cannot see spend that never went through a session, so your provider's own console limits remain worth setting. There is no per-session cost cap: this cap, over the window, is the account's spend ceiling, and it is yours to set (see BYOK).

Nothing is billed per handled issue or PR. Every tier on this page is either a seat price or waived. The handled-unit counter still runs and GET /v1/billing/usage reports it as handled_units alongside spend_usd and waived, where "handled" means a session that completed or escalated and a failed session never counts. It is a transparency counter, not a charge, and it is NOT what the spend cap meters: the cap meters spend_usd. Read a handled count as work the agent did, never as money owed.

The billing window is the UTC calendar month.

Payment failure

A failed invoice pauses the account: dispatch stops, the pause is written to the audit log, and you are emailed. Paying resumes it and re-drains the work that was waiting. Nothing is deleted, and nothing runs silently in the meantime.

Related

• Teams & roles: who in your org can spend money.
• BYOK: the other half of your bill, and why we never see it.
• Rate limits: API budgets, which are not billing.