What problem Stigg solves

Every product that charges for usage, or limits what customers, users, and AI agents can do based on what they pay for, ends up building the same infrastructure:

Usage metering that ingests and aggregates high volumes of usage data, accurately.
Real-time access enforcement: entitlement and credit checks on every request, in the hot path.
Governance: budgets and limits across users, teams, and agents.
Usage retrieval: history and breakdowns for dashboards, invoices, and audits.

Each looks simple at first and becomes hard at scale. Stigg exists so you don’t have to build and operate them yourself.

High throughput usage metering

AI multiplies usage volume. A single user prompt can fan out into dozens of model calls, tool calls, and agent steps, and autonomous agents run around the clock, in parallel, with no human in the loop. Every token, inference call, and agent action is a usage event, on top of the API calls, messages, compute minutes, and storage that usage-based products already track. To bill and enforce limits accurately, that data has to be:

Ingested at high volume, often from many agents and distributed services reporting in parallel.
Deduplicated, so retries and network failures never double-count usage.
Aggregated into the values your pricing actually cares about (for example, the sum of tokens per customer per month).
Durable, so usage can be audited, reconciled with invoices, and recalculated when something goes wrong.

Building this in-house means owning a streaming pipeline, an aggregation layer, idempotency, and storage, and keeping all of it in sync with your pricing model as it changes.

Low latency access enforcement & entitlements in the hot path

Knowing how much a customer, user, or agent has used is only half of the problem. Your application also needs to decide, on every request, whether they’re allowed to perform an action: run another AI generation, invite another team member, call an API one more time. These checks sit in the hot path of your product, and agents make them much harder. An agent can trigger hundreds of actions in a single task, each needing its own check, often in parallel. Latency that goes unnoticed on one request compounds across every step: the agent runs slower, and the user waits longer for a result. Under that load, checks also have to stay correct when many concurrent actions draw on the same credit balance or budget. They have to be:

Fast, so they don’t add noticeable latency to user-facing or agentic flows.
Consistent under concurrency, so parallel actions can’t overspend the same balance or budget.
Accurate, reflecting the customer’s current plan, add-ons, promotional grants, credit balance, and usage, plus any team, user, or agent budgets.
Highly available, with a sensible fallback when the network or a dependency is unavailable.

Hard-coding plan logic (if plan == "pro") makes these checks fast but brittle: every pricing change becomes an engineering project. Querying a billing system on every request keeps them accurate but slow and fragile.

Common patterns for solving it: check → act → track

Products that solve this problem converge on the same runtime pattern. Integrating Stigg into your application follows it too:

Check: before running a feature-specific operation, check whether the requester (a customer, team, user, or agent) is allowed to perform it. The check reflects the customer’s plan, add-ons, promotional entitlements, credit balance, and current usage, plus any budgets and limits set for that team, user, or agent.
Act: if access is granted, perform the operation. If it’s denied, block it and, for example, show an upsell experience.
Track: after the operation completes, report the consumption to Stigg so that the next check reflects it.

In code, the pattern is three steps around every operation:

// Check: is this customer, team, user, or agent allowed to run the operation?
const entitlement = await stiggClient.getEntitlement({
  customerId,
  featureId,
  options: { requestedUsage },
});

if (!entitlement.hasAccess) {
  // Act (denied): block the operation and show an upsell experience
  return showUpsell(entitlement.accessDeniedReason);
}

// Act (granted): perform the operation
const result = await runOperation();

// Track: report what was consumed, so the next check reflects it
await stiggClient.reportUsage({
  customerId,
  featureId,
  value: result.usage,
  idempotencyKey: result.id,
});

The same pattern covers metered features, credits, and budgets. For step-by-step walkthroughs, see Enforce metered feature limits, Deduct credits directly, and Charge credits for metered usage.

Governance across users, teams, and agents

As AI features spread through your customers’ organizations, a single account-level limit is no longer enough. Your enterprise customers need to control who consumes what inside their own organization:

Budgets per entity, so one user or agent can’t exhaust a shared credit pool.
Hierarchical limits that follow the customer’s structure, from organization to department, team, user, and AI agent.
Real-time enforcement at every level, applied at the moment of consumption rather than discovered on the next invoice.
Self-service controls, so your customers’ admins can allocate budgets and set limits without involving your team.

Building this yourself means modeling arbitrary org hierarchies, attributing every usage event to each level, and enforcing all of them in the hot path. Learn more in Governance.

Usage retrieval and history in the cold path

Outside the request path, other parts of your business need the same data at a different cadence:

Customers want to see their current usage, remaining credits, and consumption over time in your app.
Your customers’ admins need visibility into spend per team, user, and AI agent, to manage the budgets they set.
Finance needs usage synced to your billing provider for invoicing, plus totals for revenue recognition and reconciliation.
Audit and compliance need a complete history of every credit grant, deduction, and expiration.
Product and growth teams want to understand how customers consume features to inform pricing decisions.

These reads are less latency-sensitive but need to be complete and historically accurate, typically as time series broken down by dimensions such as user, model, or workspace. Building this yourself means keeping a second, query-optimized copy of every usage event and credit movement, in sync with the hot path, and exposing it to each of these audiences in the shape they need.

How and why Stigg's approach works

Learn how Stigg handles metering, real-time enforcement, credits, governance, and usage retrieval.

Introduction

Get started

Usage metering

Credits

Entitlements and access enforcement

Governance

Architecture and deployment

Pricing and packaging

Customers, subscriptions and contracts

Workflows

Widgets

Developer tools

Account management

Security & compliance

High throughput usage metering

Low latency access enforcement & entitlements in the hot path

Common patterns for solving it: check → act → track

Governance across users, teams, and agents

Usage retrieval and history in the cold path

How and why Stigg's approach works

​High throughput usage metering

​Low latency access enforcement & entitlements in the hot path

​Common patterns for solving it: check → act → track

​Governance across users, teams, and agents

​Usage retrieval and history in the cold path

How and why Stigg's approach works

High throughput usage metering

Low latency access enforcement & entitlements in the hot path

Common patterns for solving it: check → act → track

Governance across users, teams, and agents

Usage retrieval and history in the cold path