Pricing · Credits
Credits, explained without the small print.
Consumption pricing only works if you can predict the bill. So here is the whole mechanism: what a credit buys, which meter charges you, how a single matter settles, and exactly what happens when the balance runs low mid-run.
- One credit
- S$0.01
- 1,000 credits
- S$10.00
- Prepaid
- Always, never post-billed
- Reserved
- At run admission
- Settled
- At every checkpoint
What a credit is
One KrewOS credit is one unit of metered platform consumption. Credits are prepaid, drawn down as your crews run, and always visible in your wallet with a runway estimate attached. The conversion is published and does not move: 1 credit = S$0.01. We publish it because an abstract token you cannot convert to money is the single most common reason consumption pricing fails to convert.
What a credit buys
A slice of real work: a retrieval against a Knowledge Pack, a reranking pass, one node execution with its trace written, an evidence record indexed and stored, a scorer run in the Evaluation Lab, a human task opened and routed, a year of audit retention on one run.
What a credit is not
Not a seat, not an API call quota, not a token count you have to convert. Seats are licensed in the subscription. Domain assets are licensed in the Pack. Credits meter the run and only the run.
Where you see them
Balance and runway in the workspace top bar; per-run settlement itemised by node in the Cost & Outcomes screen; per-project and per-tenant burn in the ledger; and a cost-per-outcome figure computed from the same records that enforce your budgets.
Two meters, one wallet
Every run charges two meters against a single prepaid balance. The distinction matters because one of them can be switched off entirely, and the other cannot.
| Meter | What it covers | Managed keys | BYOK |
|---|---|---|---|
| Platform credits | Run orchestration and node execution, knowledge retrieval and reranking, evidence storage and indexing, evaluation runs, human-task management, audit retention, artefact storage, effect verification and policy evaluation | Charged | Charged, unchanged |
| Model credits | Inference through KrewOS-managed provider keys, at published per-model rates plus a stated margin, attributed to the node and model profile that made the call | Charged | Zero |
Bring your own keys and your model spend leaves our bill entirely. You still consume platform credits, because orchestration, evidence, evaluation and audit are the platform. We would rather say that plainly here than have you discover it on the first invoice.
One matter, from reservation to settlement
A LawCrew document review of a 24-page tenancy agreement for Tanglin Holdings. Reservation happens once, at admission. Settlement happens at each checkpoint, against actual consumption, and the unused reservation is released the moment the run closes.
Run RUN-8F2C41 · credit ledger
| Event | Checkpoint | Platform | Model | Held | Available |
|---|---|---|---|---|---|
| Admission — reservation taken | CP-0 | — | — | 600 | 248,300 |
| Jurisdiction router settled | CP-1 | 2 | 4 | 594 | 248,300 |
| Evidence Research Pod settled · 11 retrievals | CP-2 | 34 | 96 | 464 | 248,300 |
| Drafting settled | CP-3 | 6 | 140 | 318 | 248,300 |
| Adversarial Reviewer settled | CP-4 | 6 | 88 | 224 | 248,300 |
| Regulatory Review Pod settled · deterministic gates | CP-5 | 18 | 12 | 194 | 248,300 |
| Human task opened · waiting 3 days for sign-off | CP-6 | 9 | 0 | 185 | 248,300 |
| Approved by S. Rajah · audit written, artefacts stored | CP-7 | 3 | 0 | 182 | 248,300 |
| Run closed · unused reservation released | — | — | — | 0 | 248,482 |
| Settled total | 78 | 340 | — | S$4.18 |
Waiting is nearly free
Three days parked on a human task cost nine platform credits, not three days of anything. Durable runs hold committed state; they do not hold compute.
Reservation is not a charge
The 600-credit hold is sized from what this crew actually costs: its recent P90 of 521 credits, multiplied by 1.15 and rounded up. The arithmetic is published because a hold you cannot predict is indistinguishable from a charge. You are only ever charged what settles, and the remainder returns to the wallet at close. Notice that the available balance moves twice and only twice — down by the hold at admission, up by the unused 182 at close. Settling a checkpoint converts a hold into a spend, so it does not move it at all.
With BYOK, the same matter
78 platform credits — S$0.78 — and 340 model credits' worth of inference billed by your own provider at your own rates. The ledger still itemises the model calls; it just does not price them.
What happens if credits run out mid-run
This is the question that decides whether a firm can put a client matter through the platform at all. The answer is the same for every tier: a run in flight is never killed for money.
- Reserve at admission
A run is only admitted if the wallet can cover its reservation — the crew's recent P90 run cost, never less than 8 credits, multiplied by 1.15 and rounded up to the whole credit. If it cannot, the run is rejected before it starts, with a clear message — not half-way through a client matter.
Admission gate - Settle per checkpoint
Actual consumption is settled at each checkpoint, so the wallet reflects reality continuously rather than at the end. A long-running matter cannot accumulate an invisible debt.
Continuous - Alert at 50 / 80 / 95%
Threshold notices go to the workspace administrator and the billing contact, with the current burn rate, projected exhaustion date and a one-click top-up.
Soft - Degrade before failing
Against a soft cap the runtime drops to a lower model tier and reduces concurrency first. It also stops issuing new side-effect Actions — nothing external is sent, filed or posted while the wallet is short.
Degraded - Park at a checkpoint
If the balance still cannot cover the next checkpoint, the run completes the checkpoint it is on and parks in awaiting_credit. State is committed, evidence is retained, and the reviewer queue shows the reason.
awaiting_credit - 72-hour grace, then auto-resume
You have 72 hours to top up. The moment credits land, parked runs resume from their last checkpoint in submission order — no re-run, no duplicate Actions, no lost evidence. Idempotency keys guarantee the same external effect is never fired twice.
Auto-resume - After the grace window
Unresumed runs move to suspended. Nothing is deleted: the run, its state, its evidence and its audit record are retained on your normal retention schedule and can still be resumed or exported once the wallet is funded.
Suspended
Hard caps behave differently on purpose. A hard cap — per run, per project or per tenant — fails closed before spending, because a hard cap is a control you set deliberately. An empty wallet is an accident, and accidents should degrade, not detonate.
Failed runs. A run that fails consumes the credits used up to the failure point, itemised in the ledger. If the failure is attributable to a KrewOS fault — a control-plane incident, a gateway defect, a checkpoint that did not commit — the credits are refunded automatically and appear as a ledger reversal, without you having to ask.
Expiry, rollover and top-ups
Three rules, and we would rather you read them here than find them in a schedule.
Expiry policy
| Credit type | Validity | Rollover | On expiry |
|---|---|---|---|
| Plan-included, monthly | The billing month | No None | Allowance resets on the billing date |
| Plan-included, annual contract | The billing month | Yes Up to one month's allowance | Rolled balance expires the following month |
| Purchased top-up bundle | 12 months from purchase | Yes Full | Expires 12 months from purchase. We email you 30 days, 7 days and 1 day before |
| Trial credits | 30 days | No None | Expire with the trial and cannot be topped up |
| Goodwill credits | 90 days | Yes Full | Expire 90 days after we issue them, with the same notices |
Drawdown order is fixed and shown in the ledger: plan allowance first, then the oldest expiring bundle, then the newest. You are never silently spending the balance that lasts longest.
Controls
- Auto top-up
Optional, off by default, with a monthly ceiling you set
- Per-run cap
Rejects admission above the envelope
- Per-project cap
Monthly, resets with the billing cycle
- Per-tenant cap
Hard ceiling, fails closed
- Threshold alerts
50%, 80%, 95% to admin and billing
How BYOK changes the maths
The same 400 matters a month, priced both ways. Nothing about the platform behaves differently — only the meter does.
| Line | KrewOS-managed keys | BYOK |
|---|---|---|
| Platform credits per matter | 78 | 78 |
| Model credits per matter | 340 | 0 |
| Credits per month at 400 matters | 167,200 | 31,200 |
| Credit value drawn | S$1,672 | S$312 |
| Against a Professional allowance of 250,000 | Covered · 82,800 spare | Covered · 218,800 spare |
| Matters per month before a top-up | ~598 | ~3,205 |
| Model inference billed by | KrewOS, at published rates | Your provider, at your rates |
| Where the keys live | Platform-managed secret store | Tenant-managed encrypted secret reference |
What BYOK actually buys you
At a volume inside your allowance, BYOK does not reduce this month's invoice — it buys headroom, rate control and a model contract your risk committee has already reviewed. Above the allowance it reduces the bill directly, because top-ups are the only variable line.
What it does not change
Governance is identical. Evidence, sufficiency scoring, effect declarations, approval gates, evaluation and audit run the same way against your keys as against ours, and the ledger still attributes every inference call to a node, a model profile and a prompt version.
Work out your own number
Enter your crew, your volume and your own manual baseline. We do not supply a default baseline — a vendor-supplied one makes the return look manufactured.
Open the estimatorBook a demo with these numbers