​

Outcome-based AI-agent billing

• Seat pricing — a flat monthly cost per human workspace member, independent of how much they do. Agents that replace headcount do not fit this model at all.
• Per-token pricing — the LLM-spend meter. It tracks cost truthfully but charges for attempts, pass or fail: a conversation that burned tokens and resolved nothing costs the same as one that closed the ticket. That meter is LLM spend attribution and it keeps running unchanged — token costs are an input to your cost-to-serve view, not a revenue line.
• Outcome pricing — one fixed-rate charge per confirmed resolution, attached to the rubric that judged the conversation. If nothing passes, nothing bills.

​

Where the opt-in lives

• outcome_charge_enabled — the top-level boolean gate. While it is false, the metering pipeline never emits a charge for your conversations, whatever the rate config says.
• outcome_pricing — the rate object, { defaultRateMicroCents, perOutcomeRateMicroCents }.

GET /api/v1/billing/outcome-pricing
PUT /api/v1/billing/outcome-pricing

{
  "data": {
    "enabled": false,
    "defaultRateMicroCents": 500000,
    "perOutcomeRateMicroCents": {}
  }
}

​

The pricing model

• defaultRateMicroCents — applied to any resolved outcome whose rubric has no explicit override. Default 500,000 ($0.005).
• perOutcomeRateMicroCents — a map from an outcome key to a rate. The outcome key is the rubric’s stable id, so renaming a rubric never re-prices its historical charges and your per-rubric override keeps holding. Price a “booked-appointment” rubric higher than a “resolved-ticket” rubric by key, not by display name.

​

Where charges come from

1. A conversation completes and the judge evaluates it against your rubric, persisting the outcome row (passed, confidence, rubric id).
2. If — and only if — that row was newly written with passed = true, the producer checks your two settings keys through the shared organization-settings read cache.
3. When outcome_charge_enabled is true, it resolves the rate for the rubric’s outcome key (per-outcome override first, then the default) and emits exactly one billable usage event: quantity 1, the resolved rate carried in the event metadata, currency USD.
4. The charge lands in the same append-only wallet ledger every other Orbit charge uses — Wallets, credits, and charges — and you read it back from the same places, including GET /api/v1/billing/transactions.

• One charge per conversation-rubric pair. The usage event’s idempotency key is derived from the conversation id plus the rubric id — the same pair the outcome row’s uniqueness constraint keys on, so the DB and the billing feed dedupe identically. A replayed evaluation of the same conversation collapses to a single charge; you never get billed twice for one resolution.
• Fail-open on the pipeline, not on the gate. If the usage-event feed hiccups or your settings row can’t be loaded, the error is logged and swallowed — the conversation-close path is never blocked by a billing problem, and the missing-charge fallback is “not enabled,” never “charge by accident.”
• Metering is best-effort, the opt-in is not. You see a skipped charge as a zero row, not as a conversation failure; the audit surface for passed conversations is the outcome row itself (with the judge’s confidence), which is written before metering fires.

​

Worked example

PUT /api/v1/billing/outcome-pricing
{
  "enabled": true,
  "defaultRateMicroCents": 500000,
  "perOutcomeRateMicroCents": {
    "rub_appointment": 2000000
  }
}

GET /api/v1/billing/transactions

​

How it reads next to LLM spend

​

Limits

• No money moves on the config endpoints. GET/PUT on /api/v1/billing/outcome-pricing only reads and writes the two settings keys; charges fire downstream in the metering producer when a rubric marks a conversation PASSED.
• Opt-in is a precondition to any charge. If enabled is false, the metering pipeline records the outcome rows but emits no billable event — enabling is always your explicit action.
• Rates are integers in micro-cents, bounded to $10/outcome. A non-integer rate or a value over the ceiling is rejected with 422 before persistence.
• The rubric is the gate. A conversation that never gets evaluated, or evaluates to not-passed, bills zero regardless of pricing config.

​

Cross-references

• Wallets, credits, and charges — the append-only ledger outcome charges settle into.
• LLM spend attribution — the cost-side feed outcome billing complements.
• QA evaluations and the performance leaderboard — the rubric scorecard pipeline the PASSED gate rides on.
• The call-quality evaluation lifecycle — the operations layer around those scorecards.
• AI agent architecture — where the evaluator and the run lifecycle meet.