Start here
Billing and credits
How PWR credits, plans, pre-flight estimates, budgets and top-ups work. All prices and credit values are drafts until launch.
PWR bills AI work in credits. A subscription plan sets structural limits such as concurrent runs, and credits pay for the model usage of runs that use PWR's managed provider accounts.
Status: Billing is implemented and tested against a simulated Stripe. It has never been run against a real Stripe account, and no plan is on sale yet. Every price, credit value, markup and package size is a draft and may change before launch.
The credit model
- Each run's provider cost is computed from its real token usage (input, output, cached input and reasoning tokens) using the model's catalog price.
- A pricing policy converts that cost into credits. The policy can include a markup, a per-run infrastructure fee and a per-minute compute rate. Amounts always round up. The values in the policy are not final.
- Credits are recorded in an append-only ledger. Entries are never edited or deleted; corrections are new entries.
Before a managed run starts, PWR places a hold on your balance for the run's estimate. When the run ends the hold is released and the actual amount is charged, the way a card hold works. If a run fails or is cancelled before using anything, the hold is returned.
Credits included with a plan are granted per billing period and expire at the period's end; expiring credits are spent first. Purchased top-up credits do not expire by default.
Managed and bring-your-own-key runs
| Mode | Whose provider account | Model credits |
|---|---|---|
| Managed | PWR's | Charged from your balance |
| BYOK | Your own key, bound to the agent | Metered and shown in usage, not charged |
A BYOK agent never silently falls back to PWR's managed account. At launch PWR charges no additional fee for BYOK runs; your provider bills you for the usage. See PWR Auto.
Plans
PWR has six plans: Starter, Pro, Studio, Team, Business and Enterprise. Starter through Business are bought online and billed monthly; Enterprise is arranged by contract.
Every paid plan runs the same agents and the same models, and every paid plan can use managed models or your own provider key. Plans differ by the monthly credit allowance, how many runs can execute at once, and how many projects and members an organization can have.
Prices, included credits and limits are published on the Pricing page directly from the billing system, and are not repeated here. There is no free plan and no free trial: you can create an account and look around without paying, but running agents needs a paid plan.
The monthly allowance resets at renewal and does not roll over. Credits you buy separately are spent after the allowance and do not expire while the account is active.
When billing is enabled, limits are enforced for organizations with an active subscription: creating a project or adding a member beyond the plan is refused, and the concurrent-run limit is applied when a worker picks up a job. Without an active subscription, runs are refused with subscription_inactive.
Estimates before expensive work
Before you launch a workflow template, PWR Studio shows a pre-flight estimate: a low and high credit range, the number of runs it assumes, the model that would be used, and whether your balance can afford the high end.
Estimates are ranges, not quotes. Each run is priced from a token profile for its purpose at 0.5× to 1.5×. A goal counts one planning run plus an implementation and a review per task, and the high end adds one remediation per task. Actual usage is metered per run.
Budgets and spending limits
Several limits stack:
- Per-run cost cap. Set Max cost per run (USD) on an agent, or a cost cap on a task. A managed run is refused before it starts if its cap does not fit your available balance.
- Goal and sprint budgets. Autonomous goals and sprint execution require a budget. See Sprint execution.
- Monthly hard limit. An organization budget can set a monthly hard limit in credits and a low-balance threshold. When the credits settled in a month reach the hard limit, managed runs are refused with
budget_exhausted.
A run that exceeds its hold by a small grace amount is charged in full; beyond the grace the excess is not charged and is flagged for review instead.
Status: The organization budget is implemented in the API (owner only). PWR Studio does not have a screen for it yet; the Settings page marks spending limits as coming later. Budget and low-balance notifications are recorded in the product only. No email is sent.
Top-ups and the billing portal
- Top-ups are one-off credit packages bought through Stripe Checkout by an admin or owner.
- Subscribing to a plan is done by an owner through Stripe Checkout.
- The billing portal (Stripe's customer portal) is where an owner changes or cancels a plan and manages payment methods.
If a payment fails, the subscription becomes past_due and no credits move. A refunded top-up claws back the matching share of its credits.
Where to see usage
The PWR Studio home page shows Credits remaining, with any reserved amount and the current plan, and the Workspace shows a balance chip. Usage is available per run, per model and per task, and separates model credits from compute credits.
Status: The Billing section of PWR Studio (overview, plans, credits, ledger, usage) is implemented and has been exercised against a simulated Stripe. It has not yet been run against a real Stripe account, and on a deployment where billing is not enabled it says so instead of offering checkout.
Provider costs are estimated from reported usage and catalog prices. Reconciliation against provider invoices does not exist yet.
Refusal codes
| Code | Meaning |
|---|---|
subscription_inactive | No active or trialing subscription |
insufficient_credits | Balance is empty or below the run's estimate or cap |
budget_exhausted | The monthly hard limit is reached or the run's cap would exceed it |
concurrency_limit | The plan's concurrent-run limit is reached |
plan_limit_projects, plan_limit_members | The plan's project or member limit is reached |
plan_feature_disabled | The plan does not include the feature, for example autonomous goals |
billing_disabled | Billing is not enabled on this deployment |
More in Troubleshooting.