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.

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. Show more