Saltar al contenido

Docs / Facturación

Billing

Seats, entitlements, spend caps and the Stripe portal: and why inference never appears on our invoice.

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.

A seat buys Amount
Concurrent AI-dev runners 1
Enrollable servers 3 (inclusive of the AI-dev box)
Queue depth 50 waiting tasks
Code review Full, merge-gating, can drive auto-merge

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.

Tier Shape
Solo Self-serve. A graduated ladder, later agents cost more than the first, and the per-agent price levels off at the top band.
Pro Self-serve. Flat price per seat.
Enterprise Custom contract. No self-serve checkout.
OSS Donor Flat monthly donation. Your runners pull the OSS donation queue, not your own work.
OSS Verified Waived. For approved public repositories, see below.
Free Personal accounts only. No AI-dev seats; review is off.

Only Solo and Pro can be bought self-serve. Enterprise is a conversation; OSS Donor goes through the donation flow.

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.

Method Path Scope
GET /v1/billing/entitlements read:billing
GET /v1/billing/usage read:billing
POST /v1/billing/checkout write:billing
POST /v1/billing/portal write:billing
PATCH /v1/billing/cap write:billing

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 and still defaults to a $50 / month cap.

Once you set a cap you get an email when you cross 50% and 80% of it, one per crossing. At 100% dispatch stops until the window rolls or you raise the cap.

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. The per-session cost cap (see BYOK) bounds a single session; this one bounds the window.

Nothing is billed per handled issue or PR. The old $1-per-unit price is retired, and no tier meters usage today: every tier on this page is either a seat price or waived. The handled-unit counter still runs and GET /v1/billing/usage still reports it alongside spend_usd, 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.

  • 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.