Pricing and limits
See current pricing and allowances for plan prices, included usage, retention, and saved-rule limits. Your signed-in quote and accepted written terms show the final amount, currency, and capacity.
Personal
Each user can have one Personal account. Create custom Python rules and connect your own LLM judge within the plan's saved-rule limits and execution allowances. Personal supports Guard audit mode: rules record findings while the tool call proceeds.
Team
Team capacity is purchased in units. Each unit adds its included traces, Python rule runs, and LLM-judge evaluations. These allowances are configured independently. The pricing selector shows available unit counts, volume discounts, and included capacity.
What counts
Each allowance is counted separately:
- Traces: accepted traces. Their spans do not add trace usage.
- Custom Python-rule runs: one admitted execution of one custom Python rule. Three rules executed for one tool call use three runs.
- LLM-judge evaluations: one dispatched LLM-judge evaluation.
- Built-in static checks: fixed checks from the rules catalog, counted separately from Python and LLM usage. Current plans show whether an allowance is capped or unlimited on the pricing page.
Both Test code and Test connection consume a run when they execute Python. A timeout or runtime error after dispatch still counts. Code rejected before execution and requests rejected for insufficient allowance use no runs. Creating or saving a rule uses no runs; saved-rule count limits still apply. Audit and enforce executions count the same way. See Python rules.
Shared allowance and resets
All workspaces in an organization share its allowances. Selecting a workspace on Home, Usage, or Monitoring shows that workspace's contribution to the organization totals. Custom-rule counts show saved rules; Python-run counts show executions.
Paid Team allowances reset at the end of the billing period shown on Usage and Plan. Increasing the number of Team units scales each allowance by its own per-unit limit.
Capacity increases after successful payment. A refund that reverses purchased capacity removes that capacity. One-time additions end at the paid-period boundary shown on Plan. Capacity changes do not reset usage already recorded in that period.
When Python allowance runs out
A Guard request that needs more Python runs than your organization has remaining is rejected before any rules execute. The SDK reports an unavailable decision with failure_kind="capacity_exhausted". Fail-open returns allow; fail-closed returns block. An unavailable evaluation creates no rule finding.
Add Team capacity or wait for the allowance reset shown on Usage. You can still create or save rules within your plan's saved-rule limits. See Guard failure behavior before relying on enforcement.
Other limits
Staso enforces plan allowances in the service, not in the Python package. Published prices and limits can change independently of an SDK release.
Current plans do not impose a per-trace span ceiling. Monthly allowances, request limits, and service rate limits still apply.
Guard has two configured policy modes:
auditrecords a failed rule and would-block evidence while the call proceeds.enforcecan returnblockand stop a provider-proposed tool call.
The dashboard shows which Guard modes are available to the current organization.
Ingestion can return 403 when the organization or key cannot ingest and 429 when a current monthly or rate limit is reached. Enable STASO_DEBUG=1 to inspect SDK delivery responses, then review the organization plan and key scope in the dashboard.