Four years ago, Stigg started with a simple thesis: the way software companies manage pricing and entitlements is fundamentally broken. Engineers were burning months building homegrown billing logic instead of shipping product. Every pricing change was a deployment. Every enterprise deal was a custom integration. Today, the company has evolved that premise into something more urgent with the announcement of Stigg 2.0 โ€” what it's calling "the usage runtime for AI products."

The Build-It-Yourself Trap

There's a trend happening right now that almost nobody is talking about publicly. The most technically sophisticated companies in the world โ€” OpenAI, Anthropic, and the frontier labs defining what AI products look like โ€” are building their own billing and access control infrastructure from scratch. A Head of Financial Engineering from one of the largest AI frontier labs told Stigg directly: "What we really needed was something that was close to real time, if not real time, that could tell us โ€” do you have credits or not?" She said they evaluated every third-party metering and billing platform on the market. None of them could make synchronous access decisions. Most were built for a different era โ€” aggregate usage over the month, send an invoice at the end.

OpenAI's Blueprint

In February 2026, OpenAI published "Beyond Rate Limits" โ€” the most architecturally revealing piece of writing any AI company has released about its billing internals. The key concept is a "decision waterfall": instead of asking "is this request allowed?", their system asks "how much is allowed, and from where?" Every request passes through a single evaluation path that synchronously checks rate limits, verifies credits, and returns one definitive outcome. Credit debits settle asynchronously. Rate limits, free tiers, credits, promotions, and enterprise entitlements are all layers in the same decision stack. Stigg claims it recognized its own architecture in OpenAI's post โ€” but argues that most companies can't afford to build this internally.

Why Traditional Billing Fails AI

The "we can build a credit counter in a weekend" pitch is one of the most dangerous lies in software, according to Stigg. Yes, you can build a counter in a weekend. Two months later, you'll have a system that handles 30% of the edge cases โ€” and the other 70% will show up as billing disputes, revenue leakage, angry enterprise customers, and 3am pages. Traditional billing platforms were designed for subscriptions that renew monthly, where usage gets aggregated into line items and the invoice is the moment of truth. In AI, the moment of truth is the API call โ€” the request, the inference, the agent action.

Stigg 2.0 Feature Highlights

Stigg rebuilt its Credits Engine from the ground up as a financial transactions database designed for AI consumption patterns: real-time balances (not eventually consistent), zero overdraft enforcement at the wallet level, priority-based credit consumption rules, ASC 606-compliant ledgers, and standalone grants without requiring subscriptions. The Governance layer enables enterprise customers to set budgets, limits, and alerts across any dimension โ€” users, teams, departments, agents running in parallel โ€” with sub-5-millisecond decisioning on every request. Metering now handles over one million events per second with exactly-once semantics. Perhaps most significantly, Stigg 2.0 ships a modular BYOC (Bring Your Own Cloud) architecture where each component deploys independently into your VPC: Metering, Credits Engine, Governance, and Entitlements can all run inside your own infrastructure without forcing you to deploy everything.

The Agentic Future

Stigg killed its old UI-first philosophy. "If a capability doesn't ship as an API endpoint and CLI command first, it doesn't ship," the company stated. Stigg Skills with MCP server integration lets engineers configure credit systems, manage product catalogs, and deploy to production through natural language from their terminal. AI agents can also interact directly with billing infrastructure โ€” querying customers, checking balances and subscriptions, turning billing data into actionable insights. The company acquired Received.ai to integrate invoicing and contract management directly, eliminating another vendor for startups that want the full stack.

New Pricing Model

Stigg is retiring seats and subscriptions as its billing model in favor of two dimensions: managed entities (customers, users, agents, teams enforced) and usage events ingested for metering. No per-seat fees, no subscription surcharges. BYOC pricing breaks from industry norms entirely โ€” instead of charging per event over the cloud with data leaving your network, Stigg charges a flat deployment fee plus committed entity pricing. "The more usage events you process, the more value you extract from Stigg, and your bill doesn't change," the company claims. Pricing starts at free (Build tier), scales through self-serve (Pro at $399/month), with Scale and full BYOC tiers available under contract.

Key Takeaways

  • AI frontier labs are building billing infrastructure internally because existing solutions can't make synchronous access decisions โ€” this is a real architectural problem, not vendor FUD
  • The "decision waterfall" pattern OpenAI published in February 2026 represents the emerging standard for how AI companies should think about entitlements enforcement
  • Millisecond-latency isn't a performance flex โ€” it's table stakes when agents spawn sub-agents that make 50 API calls in parallel from shared credit pools
  • BYOC with modular deployment means Stigg can now serve enterprises that couldn't previously accept a multi-tenant cloud solution for billing data

The Bottom Line

The entitlements layer is no longer a feature of your billing system โ€” it's becoming the most critical infrastructure abstraction in AI. Stigg 2.0 makes a compelling case that building this internally is a trap, and their BYOC architecture finally addresses the compliance concerns that kept many enterprises from adopting third-party solutions. Whether you're Anthropic or a 10-person startup, if you can't decide in real time whether a request should proceed, you've already lost.