Skip to main content
Stigg is a hot-path usage runtime. Entitlement, credit, and limit checks run inline in your request path and return an allow or block decision in real time from a local cache, with p95 latency under 10ms when using the Sidecar. Billing systems ingest events and reconcile what happened after the fact; Stigg decides what’s allowed before a request runs. It works alongside your existing billing provider (Stripe, Zuora, Airwallex, and others) rather than replacing it. The runtime is built on five pillars: metering, real-time enforcement, entitlements, credits, and governance. It’s split into two planes:
  • Data plane: the metering pipeline, credit engine, and entitlement and governance enforcement. It ingests usage at high volume and answers every check in under 10ms.
  • Control plane: the product catalog and provisioning, workflows, and integrations. Your pricing model lives here, so plans, add-ons, credits, and promotional grants reach the data plane without code changes when pricing evolves.
Stigg runs as one logical system across three deployment models: Cloud API (fully managed by Stigg), BYOC (the data plane runs inside your own cloud), and BYODB (your own database and event queue). Each gives you the same catalog, entitlements, and credits engine, with the same decision latency.
Your cloud
Your application
SDK / Sidecarlocal cache
Persistent cacheoptional
Events bucketoptional
Stigg’s cloud
Data plane
Edge CDN
Metering pipeline
Credit engine
Entitlements and governance
Control plane
Catalog, workflows, integrations

High throughput metering

Stigg’s metering pipeline is built for high-volume, real-time usage:
  • Batching and parallel reporting. Report up to 1,000 events per batch, from as many distributed reporters as you need, with no coordination between them.
  • Built-in idempotency. Every usage report and credit deduction accepts an idempotency key, so retries are safe and duplicates are counted once.
  • Two reporting paths. Synchronous calls return the updated usage and credit consumption immediately for strict enforcement. Asynchronous events are aggregated by the pipeline for high-volume streams.
  • Flexible aggregation. Meters turn raw events into the values your pricing uses (count, count unique, sum, and more), filtered and broken down by dimensions.
  • Durability. Raw events are stored in their original format with 99.999999999% durability, so usage can be audited and rebuilt at any point.
  • Scale beyond the cloud limits. BYOC deploys the metering service in your own cloud for up to 1,000,000 events per second.

Low latency entitlement checks

Entitlement checks are designed to sit in the hot path without slowing it down, on a high availability architecture:
  • Pre-calculated entitlements. Stigg computes each customer’s effective entitlements whenever their subscription or the catalog changes, so a check is a read, not a calculation.
  • Edge-replicated cache. Entitlement, usage, and catalog data are served from a distributed cache replicated across regions and accessible from anywhere.
  • Local caching in the SDKs. Backend SDKs keep entitlements in an in-memory cache that’s kept up to date by polling or real-time streaming updates, so most checks are answered locally with sub-millisecond latency and no network call.
  • Persistent caching and the Sidecar. Share a cache across instances with persistent caching, or run the Sidecar next to your services.
  • Hard and soft limits. With a hard limit (the default), checks deny access once a metered feature reaches its limit. With a soft limit, access continues past the limit, for example to charge for overages or start an upsell conversation.
  • Fallback strategy. If Stigg is unreachable, checks fall back to values you configure instead of failing your request.
  • Checks inside your own cloud. With BYOC, the data plane that answers entitlement checks runs inside your VPC, so checks never leave your network.

Financial-grade credits

Stigg’s credit engine keeps balances correct under high-volume, concurrent consumption:
  • Credit pools and grants. Each customer has a credit pool per currency, or per resource, made up of individual grants such as recurring, prepaid, and promotional credits.
  • Deterministic consumption order. Grants are consumed by priority, then by expiration date, then by category, so expiring and promotional credits are used first.
  • Real-time balance. Each deduction is reflected in the balance immediately, so the next check already accounts for it, even when many requests consume credits at once.
  • Hard and soft limits. With a hard limit (the default), checks deny access once the balance can’t cover the request. With a soft limit, consumption continues and the deficit is tracked as an overdraft that’s settled automatically from the next grant.
  • Auditability. Every grant, deduction, expiration, and revocation is recorded in an append-only ledger.

Governance

Governance extends the same real-time checks from the customer account down to the people and agents inside it:
  • Entity hierarchies. Model your customers’ org structure, such as organization, department, team, user, and AI agent, as entity types and hierarchies.
  • Budgets and limits at any level. Distribute credits or restrict usage of metered features for any entity in the hierarchy.
  • Real-time enforcement. Operations are blocked the moment a limit is reached, at call time rather than on the next invoice.
  • Automatic cost attribution. A single usage event updates balances at every level of the hierarchy, so you report usage once.
  • Hard and soft limits. Hard limits block on breach; soft limits allow overage and trigger alerts.
  • Self-service management. Build your own admin experience on Stigg’s governance APIs and SDK, so your customers’ admins can allocate budgets and set limits themselves.

Usage retrieval and history

Outside the hot path, Stigg keeps usage and credit data queryable for reporting, auditing, and analysis:
  • Consumption over time. Query usage of metered features or credits as a time series over any date range, broken down by dimensions such as user, model, or workspace.
  • Credit ledger. Every grant, deduction, expiration, and revocation is recorded in an append-only ledger, in chronological order, ready for revenue recognition.
  • Governance query. A paginated, sortable view of each entity’s budget and current usage, to power dashboards and admin UIs.
  • Billing sync. Usage of metered features is synced to your billing provider, such as Stripe, Zuora, or Airwallex, for invoicing.
  • Data export. Export usage, credits, and the rest of your Stigg data to your data warehouse, database, or cloud storage.

Check, act, track

See the runtime pattern behind every check.

Core concepts

Learn the entities behind Stigg’s pricing model.