Skip to main content
How execution is funded, how spend is governed at the org level, and what to expect on an invoice. Two things are true about pricing on this page: every dollar figure below comes directly from Praxa’s published pricing proposal, and every dollar figure below is a proposal, not a locked price list. Nothing here has been validated against real conversion or usage data yet. Treat the tables as a starting point for a conversation, not a quote.

​
Two ways to fund execution

Status: Developer preview
The fabric supports two funding models side by side, at the same time, from day one. You are not locked into one.

​
Bundled (the default)

Praxa’s own provider keys run your tasks. You’re priced through Praxa’s existing credit machinery: a minimum margin floor (at least 25%) plus a payment-processing fee, with an immutable price version locked to every run — the price that applied when a run executed cannot change retroactively.

​
Bring your own keys (BYO)

Your own provider credentials run your tasks instead. Keys are encrypted at rest using the same envelope-encryption pattern Praxa uses for connector credentials elsewhere, and they never leave the runtime boundary — Praxa’s routing layer uses them to call the model provider, but the fabric doesn’t expose them back out, and the model-routing failover ladder is constrained to only the lanes you’ve funded. Instead of a token margin, BYO is charged a platform fee targeted at 5–10% of routed spend, plus a per-run fabric fee.

​
When each wins

Routing quality doesn’t change based on which you pick: routing telemetry — the data that makes model/tool selection better over time — is priced and collected identically in both modes.

​
Budget policies at the org level

Status: Developer preview
Every execute call carries an optional policy parameter — a constrained view of the same policy engine that gates approvals (see Deployment and Isolation). For budget purposes, that parameter can set:
  • A budget cap for the run or the tenant
  • A risk ceiling (which approval mode applies before spend-adjacent actions execute)
  • A model-lane pin (constrain routing to specific cost/quality lanes)
  • A tool allowlist
Underneath, spend is held against a reservation before a run executes, then settled against actual usage and reconciled — not billed after the fact with no prior hold. Per-key rate limits and org-level pooling (spend shared across a tenant’s keys rather than tracked key-by-key) are part of the same build. Be precise about enforcement today. The reserve-settle-reconcile machinery itself already runs in production for Praxa’s existing product. What is still in build is fail-closed metering enforcement on the new paid API lane specifically — moving billing enforcement out of shadow mode for /v1/execute traffic is a named gate before that lane is considered billing-complete. Until it lands, don’t assume API-lane usage is being enforced against a cap in production; assume it is being built toward that, deliberately, before general availability.

​
Usage readback API

Status: Developer preview
GET /v1/usage returns tenant-scoped usage and spend — a programmatic way to pull what a tenant has consumed without waiting for an invoice. Usage is tracked from raw token counts down through fractional-currency units before settling into credits, which is what keeps reservation holds and reconciliation from drifting against the eventual charge.

​
Invoice expectations

Status: Developer preview
  • The API meters runs and spend — not raw model steps. Raw step counts remain an internal cost guardrail, never the customer-facing meter. A more efficient agent that does the same job in fewer steps should not cost more, and doesn’t.
  • Every run’s price is version-locked at execution time. Your invoice ties back to the specific price version that was active when a run executed, not a number that could move underneath you after the fact.
  • Outcome-metered features are a separate layer. Some Praxa product surfaces (outside the execution-fabric API itself) are priced per outcome — for example, per approved send or per generated report. Those meters belong to the specific feature, not to /v1/execute; if you’re integrating against the fabric API directly, runs-and-spend is your meter.

​
Indicative pricing (proposal — subject to change)

Status: Developer preview (Solo–Team rows) / Planned, enterprise tier (Business–Enterprise governance rows)
The table below is the current tier-ladder proposal. It has not been validated against real conversion data. Every figure is anchored to public competitor pricing as of mid-2026, not to Praxa’s own measured costs or revenue. The “unlocks” column names the feature; it is not a claim that the feature is built — cross-reference Deployment and Isolation for what’s actually shipped versus planned. A note on how the Business row is priced: an earlier plan had a separate flat platform fee for governance features; the current proposal folds that into the per-seat price instead, on the reasoning that a single legible number reads better to a buyer than a seat price plus an opaque add-on fee. On the funding-model fees above: the bundled margin floor (≥25%) and the BYO platform fee (5–10% of routed spend) apply on top of whichever tier an org is on — tier price governs seats and feature access; funding-model fee governs how inference itself is priced.

​
What’s not enforced yet (say this plainly)

Status: Developer preview
No metering exists in enforced form on the execution-fabric API today. Until fail-closed billing enforcement ships and is reconciled against real model, compute, and connector costs, usage revenue on this API is effectively zero and margins on it are unknown — this is a stated, first-class launch blocker, not a footnote. This is separate from approval enforcement, which is fail-closed today (see Deployment and Isolation); billing and approval are two different gates, and only one of them is complete.
Related: Teams and Organizations · Deployment and Isolation