Credits and permissions

MCP and HTTP requests use the workspace’s existing credit balance. A separate subscription or balance is not created for an API key.

Three limits apply

• Workspace balance: credits available to the workspace.
• Per-run cap: the maximum one creation or edit may spend.
• Key allowance: the total this key may spend across runs, including active reservations.

An optional credit_cap on a request can lower the key’s per-run cap. It cannot raise it. Admission also considers the minimum required budget and available credits, so a run can be refused before starting.

Reserved and charged credits

While a run is active, its result shows credits.reserved. On settlement, credits.charged reports the actual charge. Unused reserved credits become available again. Stopped, failed or interrupted work can still incur a charge.

Workspace roles still apply

Reviewers can read projects and results. Creators can create and direct their own projects. A write-enabled key does not let someone direct another person’s project. Workspace owners and admins can manage the team’s keys; other members manage their own.

When a limit is reached

insufficient_credits means the workspace needs credits. allowance_exhausted means this key cannot admit more spending. Wait for active reservations to settle or replace the key with an appropriate allowance. API keys cannot buy credits. See errors and retries for details.