Autumn

Drop-in, open-source billing infrastructure for AI startups. Usage-based billing, credits, entitlements, and subscription state on top of Stripe, behind one API.

What Autumn is

• Autumn is open-source billing infrastructure that runs on top of Stripe.
• It is the system of record for subscriptions, usage metering, credits, and feature entitlements, exposed through a small API (attach, check, track).

What Autumn is not

• Autumn is not a payment processor and does not replace Stripe; Stripe still holds the subscription and processes payments.
• Autumn is not a pure usage-metering tool — it also enforces entitlements and feature access, not just end-of-month invoicing.

Docs

For how the platform itself works, see the docs:

• Autumn docs
• Quickstart
• API reference

Comparisons

• Autumn vs Building In-House: Building in-house gives you maximum control. Autumn is for teams that want real-time checks, credits, entitlements, ledgers, rollovers, reset rules, custom packages, and pricing changes without maintaining a billing system forever.
• Autumn vs Metronome: Metronome fits teams that need sophisticated usage rating and invoicing. Autumn fits teams that need credits, limits, entitlements, and pricing changes enforced inside the product.
• Autumn vs Orb: Orb fits teams whose billing problem starts from usage events, complex pricing queries, ledgers, and invoicing. Autumn fits teams whose billing problem starts from application billing state: credits, limits, entitlements, resets, rollovers, and runtime checks.
• Autumn vs Stripe Billing: Stripe Billing handles subscriptions, invoices, payments, and usage billing. Autumn complements Stripe when your app needs credits, entitlements, limits, and pricing changes enforced in product.

Blog

• Inching towards a software factory: How we've been getting our codebase, tests and infra to keep up with model improvements, so cloud agents can actually do useful work on their own.
• Weekly pricing experiments across billions of credits at Firecrawl: Firecrawl replaced an 800-line SQL function and a decision between smart upgrades and top-ups with a billing system they can iterate on weekly.
• Hunting down memory leaks (in Bun): How we tracked down a stack of memory leaks in our Bun production server — and recycled what we couldn't fix.
• How Mintlify is scaling sales-led GTM: Mintlify moved from product-led to sales-led growth, and had to rebuild billing and provisioning to keep up. Here's how they combined billing and enablement into one model.
• Reworking our positioning: We built Autumn around React hooks and shadcn components for the developer experience. Here's why we're deprecating them, and how our positioning shifted as coding agents got better.
• How to build a credit ledger that scales: Metering token usage needs a different type of infrastructure. This article is about how to build a counter and ledger that works at high throughput and concurrency.
• Building an API for agents: Some patterns we've found ourselves adopting as we design Autumn's API increasingly for agents instead of humans.
• How to build a flexible billing system: How to architect a flexible billing system that handles pricing changes well
• Saying goodbye to multi-region (for now): Why we moved Autumn to a multi-region architecture, the tradeoffs we hit with active-active Redis, and why we eventually returned to a simpler single-region setup.
• Building on top of Stripe billing: Why Autumn builds around Stripe Billing instead of replacing subscriptions and invoices, and where the real complexity has moved for credit-based pricing.
• How we use agents for billing support: How we automated customer support investigations by structuring our logs and giving Claude Code the right primitives.
• Making internal agents useful:
• Migrating Autumn to PlanetScale: How we migrated our core database to PlanetScale, and why it's been a game-changer for performance, reliability, and developer experience.
• Post mortem: database outage: Post-mortem write up of an outage that affected a number of requests between 15:00 and 16:00 UTC, 15th March 2026.
• The psychology behind T3 Chat's pricing: We worked with Theo and Mark from T3 Chat to build a cool new way of pricing. We learned about the psychology behind how AI products are consumed, and what that means for how we should monetize them.
• We're making some API changes: A bit of context about what will be changing in the new version of the Autumn API and SDK.
• People really don't like metered billing: Replit’s 2026 pricing shift highlights three trends in AI-first products: usage-based billing creates anxiety, seats don’t map to AI value, and credits/effort-based pricing reduce transparency as agents run longer.
• React vs shadcn, and trying to be too clever: Learnings about building a component library for a billing platform for AI companies
• Marketing is hard: A little write up on our thoughts and exploration around how to market our developer tool for billing and payments.
• 100 stripe cases in 1 endpoint: Handling stripes upgrades, downgrades, schedules, one off and subscriptions all in 1 endpoint.
• What if Stripe builds this: Stripe has been the go-to for billing, subscriptions and managing payment logic for 16 years. We think that'll change soon.
• Embedded UI components: We decided to use a shadcn/ui registry to set up our pricing components, instead of a Reactjs library. We used this approach for pricing pages, upgrade and downgrade flows and paywalls.
• A roasting from HN makes better devtools:
• We tried to make billing backendless: We wanted to make payments, billing, usage limits and tracking as easy as possible. We explored a billing integration that required no backend setup, but ultimately gave up.
• How we made our first sale as a startup: How we generated our first revenue as a startup, and got into Y Combinator.
• Talking about billing with 30 YC founders: