Rates
Obol publishes two usage schedules. They are not a volume discount of each other (ADR-0060). The public ladder is the quote. The assisted first-five partners are billed on a grandfathered Team schedule — the meters this page and the shipped biller implement.Public ladder
The public quote, per 1,000 dispatched calls. This is what the marketing site states, and what hosted Pro meters at public launch.Design-partner meters
The grandfathered Team schedule for the assisted rollout. Control’sPLAN_RATES and the Stripe catalog charge these amounts today. They are not a discount from the public ladder.
Usage is billed in arrears using per-call decimal rates, without rounding up to blocks of 1,000. For example, on the design-partner meters, 100,000 LLM requests, 100,000 reads, 10,000 writes, and 1,000 destructive calls cost 1,740 before configured taxes. The invoice is not capped at $2,000.
You bring your own provider credentials and pay providers directly. Token counts and Vendor cost estimates in your workspace are informational; editing those estimates never changes these Obol rates. Obol does not charge a percentage of payment volume or act as a merchant of record. The one exception to “you pay the vendor” is Obol’s own built-in tools, below.
Built-in tool fees
Obol operates four built-in tools itself and charges a published fee per action, written in cents (ADR-0215). They are rolling out: Obol Cloud does not run the built-in tools service yet. The fee is charged once per logical call. It is paid from the organization’s monthly included built-in allowance, then from the organization’s prepaid balance. It is never metered to Stripe, never invoiced in arrears, and never added to a Team or Enterprise invoice: when neither source covers it, the call is refused before dispatch withbuiltin_credits_exhausted. Each built-in call also counts as one ordinary
tool call at the rates above.
The allowance is per organization, shared across its workspaces, and does not
roll over. On Obol Cloud enforcement is on by default; while a deployment runs
the dry run (
OBOL_BUILTIN_TOOLS_ENFORCED=false), a built-in call draws only the
included allowance and never the prepaid balance, and a call beyond it runs and
is recorded unenforced. A deployment that is not Obol Cloud records built-in
fees not_chargeable, and they never reach Stripe.
Workers compute and the prepaid balance
Obol Workers is in early access, and Obol Cloud provisions no Workers runtime yet. Its published compute price is 2¢ per active minute ($1.20 per hour), rounded up per active interval with a one-minute minimum (ADR-0185). It is paid from the same prepaid balance before an environment is allocated, and never from the included built-in allowance. Your prepaid balance pays for usage on Obol Cloud: built-in tools after the monthly included amount, and Workers compute. Your plan’s monthly fee is billed to your card, and your model and app providers bill you directly. Balances and amounts are shown in dollars with two decimals. Obol Workers and built-in tools are Obol Cloud services. They are not part of Free Self-hosted.What counts as a call
One logical request becomes billable when upstream dispatch starts. A vendor error after dispatch still counts. Obol’s internal retries, provider fallbacks, approval resumes, and receipt revisions do not add another fee for the same logical request. Policy denials and failures before dispatch are free. Discovery, dashboard management requests, and verification probes are not separately billable. Tool categories come from the reviewed tool definition captured at dispatch time, not from a caller’s labels or later catalog changes.Billing records dispatch. It does not certify that a tool achieved its intended effect. A receipt still states its evidence class; federated routes do not gain native, gateway-observed outcome evidence through billing.
Enroll and activate
Design partners receive founder-approved assisted onboarding. There is no public trial or unapproved self-serve Checkout.1
Review the startup offer
Open Settings → Billing or continue onboarding. The owner of the designated billing workspace manages payment for the linked startup.
2
Pay through Stripe Checkout
Checkout collects a card and billing address. It creates one monthly subscription with the base price and four metered prices. Obol activates execution after the control plane confirms the initial payment; returning from Checkout alone does not activate it.
3
Connect and make a first call
Choose models, tools, or both. Connect your provider, publish policy, create a virtual key with a budget, and make a successful dispatched call. Onboarding resumes from recorded state. Inviting teammates is optional.
Renewal and payment recovery
A confirmed failed renewal starts a fixed seven-day grace period. At the deadline, new execution is blocked while in-flight calls finish and the dashboard, audit, and receipts remain available. Use the Stripe-hosted payment portal in Billing to update payment details. Payment recovery restores billing readiness, but cannot remove a manual workspace freeze. A Stripe outage or an Obol reconciliation failure alone does not suspend an active partner. Cancellation takes effect at the end of the paid period; the final invoice collects accrued usage without starting another base subscription period.How usage reaches Stripe
The gateway emits an immediate dispatch fact separately from completion usage. Control stores the dispatch source and allocates one immutable charge per workspace, request kind, and logical call identity. The allocation pins the customer, meter, price version, amount, and dispatch timestamp. Completion metadata can recover the same fact without charging it twice. Each allocation reports one unit to its matching sum meter. Stripe receives a stable identifier, event name, customer ID, value, and original dispatch timestamp. It receives no tool arguments, vendor credentials, receipt bodies, token counts, or vendor cost estimates. Delivery uses durable claims, fenced leases, and bounded retries. Ambiguous requests stop before the remote idempotency window expires; they require reconciliation. Known ingestion gaps pause delivery. A successful meter request acknowledges receipt, while Stripe aggregates asynchronously.Usage invoices require review
Before activating a paid partner, control persists Stripe subscription collection behaviorkeep_as_draft with no resume deadline. Every subsequent usage-bearing invoice is held in draft with automatic advancement disabled, including during a control outage. Control compares local allocations and delivery status with Stripe’s meter summaries, invoice quantities, and rounded amounts. Disagreement, missing data, or ambiguous delivery keeps the invoice on hold.
For this assisted rollout, even matching observed totals require operator review and explicit payment of the individual invoice in Stripe; the subscription-wide draft setting stays in place. Stripe meter summaries require minute-aligned windows, so an invoice period with other second boundaries also remains under review. The gateway’s asynchronous queue can lose events before Redis; matching two downstream totals cannot prove that no earlier event was lost. Initial base-only payment collects normally. See Metering for the transport boundary.
Billing distinguishes complete, delayed, gap, and reconciliation required projections. Here, complete means the observed projection has no known gap or outstanding delivery problem; it is not a guarantee of invoice-complete ingress.
Deployment
The control API and worker use Obol’s platform Stripe secret and the billing webhook signing secret. These are distinct from customers’ vaulted Stripe connector credentials and never reach the gateway or dashboard configuration. The repository’sinfra/scripts/stripe_billing_catalog.py prints the reviewed catalog by default and provisions only an authenticated sandbox with --apply. It verifies existing immutable prices and meter semantics before reuse. Runtime configuration includes one base price, four metered prices, meter IDs, event names, and separate STRIPE_BILLING_WEBHOOK_SECRET and STRIPE_BILLING_METER_WEBHOOK_SECRET values for lifecycle and thin meter-error endpoints. Automatic tax defaults to false until the account’s tax setup is configured.
Legacy tool-only deliveries remain separate. Enrollment never releases historical waiting rows into the new design-partner meters. The implementation lives in apps/control/app/services/billing/; the legacy pipeline remains in stripe_meter.py.