Stigg 2.0 - The usage runtime for AI products
by•
Stigg is the usage runtime for AI products: the real-time enforcement and governance layer between your app and your billing stack. It decides what every customer, user, team, and agent can do, the moment they try. Millisecond credit checks, zero overdraft, enterprise governance, and modular BYOC. Metering, credits, entitlements, and governance in one runtime. Enforce in the request path instead of reconciling on the invoice. Free forever for AI startups.
Replies
Stigg
Hi everyone, Dor here, co-founder and CEO of Stigg.
Four years ago, Anton and I started Stigg because building pricing and entitlements in-house was quietly eating engineering teams alive. Every pricing change was a deployment. Every enterprise deal became a custom integration.
We were right about the problem. Then the AI wave made it much sharper.
The most sophisticated AI companies started building their own billing and access-control infrastructure from scratch, because nothing on the market could decide in real time whether a request should proceed.
A frontier lab's head of financial engineering put it simply: what they needed was something close to real time that could answer one question - do you have credits or not?
When a single API call costs real money and agents spawn sub-agents in milliseconds, "we'll reconcile at month-end" stops being a strategy.
Stigg 2.0 is our answer: the usage runtime for AI products. It decides what every customer, user, team, and agent is allowed to do, the moment they try. Credits, metering, entitlements, and governance in one system that sits alongside the billing stack you already have.
It's free forever for AI startups, because we want you building your product, not rebuilding ours. When you land the enterprise deal that breaks your homegrown system, we'll already be there.
We're launching at the AI World Fair. We'd love your honest take, try it, push on it, and tell us what's missing.
Stigg
Hey PH, Anton here, Stigg's CTO with the under the hood bites behind Stigg 2.0!
When OpenAI published “Beyond Rate Limits” in February, they described a decision waterfall. Every request flows through a single evaluation path that synchronously checks rate limits, verifies credits, and returns one definitive decision, while debits settle asynchronously. Reading it, we recognized our own architecture. The hard part was never the idea. The hard part was making that decision correctly in single-digit milliseconds while an AI agent fans out into 50 parallel calls against a shared credit pool.
A few pieces I'm proud of:
Credits run on a financial-grade ledger: balances update before the API response returns, overdrafts are enforced at the wallet level, and burn-down follows configurable priority rules: promotional first, expiring before non-expiring, paid last. An ASC 606-compliant ledger with full provenance.
Usage Governance enforces limits and user-level spend caps in under 5ms P99 on every request. This is the piece I think matters most. A power user burning through an enterprise’s entire allocation in a day isn’t something you fix on the invoice. You fix it at the point of consumption, or you don’t fix it at all.
Deploy a complete metering stack in your own cloud: Kafka, Flink, and ClickHouse. Sustain 1M+ events per second with exactly-once guarantees where they actually matter.
Modular BYOC - Deploy every module independently into your own VPC. Metering, Usage Governance, and the Credits Engine run in your cloud, while configuration and management stay in ours. Clean trust boundaries, your topology.
Come break the demos, read the docs at docs.stigg.io, and tell me where it falls over.
That’s exactly the kind of feedback we’re looking for.
The sync-check, async-settle split is the right shape. The part I'd poke at is concurrent agent bursts: if an agent fans out 50 calls in one tick, they can all clear the credit check before the first debit settles, so how does zero-overdraft actually hold, do you place a hold or reservation at check time, or reconcile optimistically? We've had agent loops blow past a budget in exactly that window.
Grass
@dipankar_sarkar I second this
Stigg
@dipankar_sarkar You're describing the classic check-then-act race, and you're right that naive implementations break here. We support both modes, and the right choice depends on the use case: For strict budget enforcement, you can place a hold at check time. The estimated cost of the request is reserved against the balance atomically, so the 50 concurrent calls each see a decremented balance. When the actual usage comes in, the reservation is adjusted to the real cost. For latency-sensitive workloads where a small overshoot is acceptable, you can skip the reservation and reconcile async. You set an overdraft threshold (X% over the budget), and the actions are blocked once the settled balance crosses that threshold. This is what most AI-native teams prefer because they prioritize user experience over blocking users mid-action.
Permit.io
Congrats on the launch, Stigg team! It’s always great to see your innovation. I just took your “Install with AI” feature for a quick ride, and it’s exactly how software should be built today.
In 5 minutes, I had a fully decentralized ledger installed across 2 agents. Well done!
Unboxable
Rolling our own metering and entitlements turned into a second product we didn't want to maintain. Love it when you guys make it one runtime that enforces in the request path, not on the invoice. So congrats on the launch!
Embedding usage enforcement at the runtime layer rather than purely at the API gateway is the right call. Usage metering for AI products is uniquely hard because costs are nondeterministic and you need real-time enforcement without adding latency. How does Stigg handle the gap between estimated and actual token usage for streaming responses? That's where most quota systems get messy.
Stigg
@anand_thakkar1 Before a request starts, Stigg runs a lightweight entitlement check against a cached credit balance to decide whether to allow or block it. For streaming workloads, you can estimate the cost upfront based on input tokens plus a rough, model-specific estimate of output tokens - and since there isn't a deterministic way to predict output token usage, it's common to include a safety buffer in the estimate. Then you can deduct that amount from the balance before sending the request, and then reconcile it against the actual usage once the stream completes. The reconciliation happens through our event ingestion pipeline, which processes the final token count and adjusts the balance accordingly. If the actual usage exceeds the estimate, the difference is settled by deducting the remaining amount from the customer's balance.
Voquill
Congrats on the launch! Looks solid. How does this handle outages? Is there a fail open or fail closed mode if Stigg isn't available?
The configurable burn-down — promo first, expiring before non-expiring, paid last — is great on paper. I'm curious how it survives concurrency.
When 50 parallel debits hit the same wallet in one tick, keeping that priority order deterministic usually means serializing the debits… which fights your sub-ms goal.
Are you ordering these strictly, or is it eventually-consistent priority where a few paid credits might get burned before some promo ones under load?
Tested it on a side project and the credit checks really do come back instantly, no extra round trip in front of my API. The entitlements view made it easy to flip a feature on for a test user without touching billing code.
How does the sub-millisecond credit check actually hold up under heavy concurrent load, and do you handle rate limiting on the enforcement layer itself or assume that part is already covered upstream?