The design-partner offer is $1,500 USD per startup per month, plus usage from the first dispatched call. Your linked development, staging, and production workspaces share one subscription. Adding a teammate does not add a seat fee.

​
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’s PLAN_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 240inusage.Arenewalwiththatusageis240 in usage. A renewal with that usage is 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.

​
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.
The startup’s billing workspace owners can see aggregate rates, linked workspaces, billable counts, and invoices. Membership in another linked workspace alone does not reveal startup-wide finances. Other members retain their workspace’s Usage view. New workspaces in an enrolled organization inherit its payer without granting access to other workspaces. Enrollment does not bill historical traffic. Existing unenrolled and self-hosted workspaces retain their existing behavior.

​
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 behavior keep_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’s infra/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.