Billing and pricing guide

ROST is priced for company-wide adoption. A Seat is a function, not a paid human license, so inviting the whole team should not create a per-person tax on running the operating system.

Package model

The launch billing model has two parts:

• Company base subscription. One company subscription covers the operating system: Compass, Responsibility Graph, Cascade, Signal, Friction, Sync, Settings, reference docs, and governed agent setup.
• Governed-agent usage. The base subscription includes a configurable allowance for billable successful agent work. Usage above the included allowance is metered from service-owned closed-period billing finalization.
• Add-ons. Some advanced capabilities ship as separately purchased add-ons gated by their own account entitlement, not part of the base subscription — for example the Software Factory (Forge) developer-agent add-on (software_factory.access), which is opt-in and never bundled into the base plan.

Human members are not the billing unit. A company can invite the people needed to run the operating rhythm without paying for each human login. Seat or member limits may still exist as entitlement controls for abuse prevention, package design, or enterprise contracts, but they are not the default subscription meter.

How usage is measured

Agent usage is measured from the same billing-grade records that power the AI-workforce ROI view:

• Agent runs record token/cost data as they execute.
• usage.snapshot freezes usage into usage_period_snapshot for ROI/reporting.
• Billing true-up uses a service-owned closed-period finalization path, not mutable running totals and not a tenant-created current-period snapshot.
• A true-up must be idempotent and no-overcharge: the same closed period should not be reported twice.

The first meter is billable-successful-agent-run based because the current platform records per-run usage and cost. The v1 overage quantity starts from successful real runs, excludes setup/sandbox dry runs and other non-billable rehearsals, and keeps failed, timed-out, and cancelled runs visible in the ROI and exception views without charging them as overage. The usage layer should keep enough metadata to support future accepted-value or outcome-based units without changing the subscription model.

Billable true-up is service-owned and runs after a period is closed. The tenant-facing usage.snapshot command is an ROI/reporting tool; an early current-period snapshot must not become, replace, or block the final billable close. The billing close records a separate billing_usage_true_ups row keyed by tenant and period with the source kind, included allowance, billable overage, status, and Stripe meter event identifier. A closed usage snapshot is preferred only when it was captured after the period ended; otherwise the service close uses a live rollup for that closed period so an early ROI snapshot cannot undercount the invoice true-up.

Launch credits and recovery access

Eligible launch tenants can receive one configured launch credit for ROST-managed variable costs. Managed LLM, Exa, browser, and sandbox costs are estimated before the provider call, reserved atomically against the active launch credit, and then settled to actual usage or released if the call does not complete. BYOK model calls do not draw down launch credit, but they still keep their ordinary audit and usage records. Settings surfaces 50%, 80%, and exhaustion posture so a tenant can choose subscription recovery, BYOK cost reduction, export, cancel, or delete before operations pause.

Launch-credit notifications are informational and idempotent: owners may see threshold, exhaustion, or expiry notices with recovery actions when the remaining credit drops or the credit approaches its expiry window.

When an unsubscribed tenant's launch credit expires, ROST enters a recovery-safe posture instead of deleting the workspace or letting agents continue spending. Billing, BYOK setup, export, cancel, and delete/recovery routes stay reachable so a human can restore or leave cleanly. Operational writes, schedules, cloud agent runs, and other cost-creating actions pause until the tenant has an active subscription or active launch credit again.

Stripe boundary

Stripe owns payment collection, payment methods, invoices, and hosted customer self-service.

ROST stores only safe commerce metadata: Stripe customer/subscription identifiers, plan state, entitlement state, usage true-up state, and safe audit/error metadata. Card numbers, bank details, payment-method secrets, Stripe API secrets, webhook signing secrets, and raw payment details must never be stored in ROST, entered into an agent prompt, written to logs, or copied into tool arguments.

Beta testers, design partners, and test tenants

Test, beta-tester, and design-partner companies may run without a Stripe customer or subscription. They are invite-flagged plans with explicit billing state and model safety caps. Invite-only beta testers receive a $10 platform inference allowance behind a $5 soft and $10 hard monthly managed-inference cap. That allowance is not a Stripe credit, and beta access cannot require a BYO key at invitation time. Do not use fake coupons or hidden payment workarounds to represent these cohorts.

Cohort owner invites are minted only through the server-only typed route after an authenticated active tenant owner session is established and the platform-prepared tenant has its server-controlled cohort_invites_enabled bit enabled. The bit defaults off for every ordinary signup tenant and cannot be enabled through the invite body or ordinary onboarding/member surfaces; Full Operator bearers, ordinary commands, agent or MCP calls, and public signup cannot mint cohort invites. Beta acceptance rejects any active tenant-level Anthropic credential, even when a BYO setting is false. Design-partner BYO mode must match the authoritative active tenant credential and acceptance preserves an existing credential rather than revoking it. Cohort acceptance also requires a fresh, unbilled tenant: every Stripe field — customer, subscription, subscription status, price, current period end, and last event id/created — must be null, and acceptance rejects any tenant that already carries Stripe metadata rather than converting it. A Stripe-backed tenant therefore never enters a cohort; it uses the ordinary audited checkout/conversion path instead.

When a company converts to paid, Stripe subscription state plus the tenant plan become the authority for the company subscription. Account entitlements remain user/account-scoped capability grants or limit overrides; they should not make the whole company's paid access depend on one owner's account grant. Limitable gates resolve through a paid-plan-aware entitlement helper: explicit service-owned account_entitlements rows override the tenant default for a specific user and tenant, while active paid tenant state selects the paid-plan default. Empty metadata means unlimited today; future tenant-wide caps must use a service-owned billing configuration surface, not client-editable tenant settings.

Billing versus inference budget

There are three separate allowances or caps:

• Subscription usage allowance: the included billable-successful-agent-run allowance in the paid company plan.
• Platform onboarding model allowance: the app-provided setup tokens used during assisted onboarding.
• Inference hard cap: a safety and spend-control setting for ROST-managed model calls.

The inference hard cap is not the subscription invoice, and raising it is not the same as buying a plan. The onboarding model allowance is also separate from the subscription usage allowance.

A company may bring its own provider key. BYOK changes which provider account pays eligible model calls; it does not change the company base subscription, the Charter, the tool guard, human confirmations, or billing for governed-agent platform usage.

What users should see

The billing area in Settings answers:

• Which plan is active.
• Whether the company is on free setup, invite-only beta, design-partner, or paid Stripe-backed access.
• Where tenant owners can start Checkout or open Stripe's hosted portal for payment method and invoice management.
• Recent Stripe invoice summaries when Stripe billing is configured for the company.
• Human/member coverage plus agent-seat and live-agent coverage.
• The latest subscription usage snapshot from the immutable usage-period table.
• The latest true-up status, including whether overage was reported, skipped because the included allowance covered the period, or needs retry.

Settings labels subscription usage separately from the setup model allowance and the inference hard cap. Payment methods and invoice payment stay in Stripe. ROST renders subscription ids/status and invoice summaries only; it does not store card, bank, payment-method, or invoice-payment details.

Do not claim that a live charge happened unless Stripe test/live evidence proves it. For internal or design-partner validation, use Stripe test mode only unless a human owner explicitly completes a real live-payment step.