Credits

Understand how credits power usage-based billing in SaaS deployments.

Credits are the platform’s unit of usage measurement. In SaaS mode, your organization uses credits as sandboxes run. Credits are shared across all members of the organization.

Only Pro and Enterprise tiers are available. New organizations start on the Pro tier with 25,000 free credits.

How credits work

Credits are consumed in real time while sandboxes are active. Usage is recorded automatically so you can track spend and remaining balance.

Event	What happens
Sandbox keepalive	Extends sandbox timeout based on remaining balance
Metering loop	Credits are deducted from running sandboxes
Sandbox pause/stop	A final deduction is recorded
Balance reaches zero	All running sandboxes are terminated

The current billing UI shows a reference sandbox-runtime rate of 0.0552 credits per second (about 3.3 credits per minute), and also explains that 1,000 credits is about 5 hours of sandbox runtime. The same billing page notes that credits are used for AI inference costs, not just sandbox uptime.

What the billing page shows

In the app, open Settings → Billing for the operational billing view. That page groups:

current balance and low-balance warnings
a Buy Credits flow backed by Stripe checkout
auto-refill controls and saved payment-method details
transaction history for purchases, refunds, auto-refills, and signup allocation
a usage view showing sandbox runtime and inference consumption

Control boundaries

Different billing actions belong to different roles:

Action	Typical actor	Why
view balance and transactions	org members with billing visibility	understand current spend and warnings
buy credits	org members using the billing flow	top up shared organization balance
configure auto-refill	organization owners	changes background spend behavior
set member monthly credit limits	organization owners	applies guardrails to other members
grant credits manually	platform admins	deployment-wide admin operation, not org settings

Purchasing and balance

Organizations receive an initial credit allocation at signup and can purchase additional credits through Stripe. Each purchase increases the shared org balance. The checkout flow accepts a quantity (1-10) to buy multiple bundles in a single session.

The exact bundle size and price are returned by the pricing endpoint and surfaced in the app billing flow, rather than being hardcoded into every integration.

Auto-refill settings

Auto-refill keeps your organization’s credits topped up automatically. When your balance drops below the configured threshold during a deduction, the platform charges your saved payment method in the background and adds credits without interrupting the running workload.

Enable auto-refill from Settings → Billing. Only organization owners can configure it. When enabled, you can choose:

Threshold — the balance level that triggers a refill.
Refill amount — the number of bundles to purchase per refill (1-10).
Monthly cap — the maximum number of auto-refills allowed per month.

The monthly cap is a safety rail to prevent runaway spend. The billing page also shows the saved payment method (brand, last 4 digits, and expiry) and a status line for auto-refills used this month.

If a payment fails (card declined or expired), auto-refill is automatically disabled. You can update the payment method in billing settings and re-enable auto-refill, or disable it any time from the same page.

Transaction types

Type	Description
`signup_allocation`	Initial credits granted at org creation
`purchase`	Stripe-backed credit purchase
`auto_refill`	Credits added automatically when balance drops below threshold
`usage`	Runtime deductions from sandbox activity
`inference`	Model inference deductions
`web_search`	Hosted web search call deductions
`storage`	Periodic deductions based on cached object storage usage
`refund`	Credits returned after a purchase reversal
`admin_adjustment`	Manual credit changes by platform operators

Zero-balance enforcement

When an organization’s credit balance reaches zero in SaaS mode, ingestion and upload paths are blocked with HTTP 429 until credits are replenished. This includes:

OTEL span ingestion
OCI blob uploads and task package imports

Workspace STS uploads are metered retroactively and may be rejected on later ingestion.

Storage usage visibility

The /api/v1/user/limits response includes storage_gb, sourced from the storage scanner cache used by billing. This value is refreshed on the storage scan interval rather than every request.

Usage breakdown endpoints

GET /api/v1/org/{org}/credits/usage returns per-dimension credit usage for sandbox runtime, inference, web search, span ingestion, and storage, plus total_credits, estimated_span_count, and current_storage_gb (from the storage billing cache).
GET /api/v1/admin/billing/usage-breakdown returns platform-wide per-organization usage rows with the same five credit dimensions and aggregate totals for each dimension.
GET /api/v1/org/{org}/credits/web-search-usage returns hosted web-search totals (request count + credits) scoped to the calling user by default; org owners can pass user_id=all for an org-wide breakdown with per-member rows.
GET /api/v1/admin/billing/web-search-usage returns platform-wide hosted web-search aggregates per organization. Pass org_key to drill into a single org with a per-member breakdown.

Balance fields

The credits balance returns the current balance and warning state.

Field	Meaning
`balance`	Current credit balance.
`is_low_balance`	`true` when the balance is below the warning threshold.
`auto_refill_enabled`	`true` when auto-refill is active.

Deployment modes

In Enterprise mode, credit endpoints are unavailable and sandboxes are not limited by credit balance. In practice the credits API returns “not available” style responses rather than acting as a hidden no-op.

Member limits

Organization owners can set per-member monthly credit limits to prevent a single user from consuming the entire org balance. When a member exceeds their limit, any running sandboxes for that member are paused. Other members continue running normally.

What agents should assume

credits are org-scoped, not user-scoped
auto-refill and member limits are owner-controlled safety rails
sandbox runtime and inference both contribute to usage
deployment-wide admin billing is a separate platform-admin surface from org billing settings