Open Source Orb Alternatives

Lago is the programmable system between product usage and revenue. Events arrive from the application, become billable metrics, pass through pricing and entitlements, and come out as invoices, payments, and revenue, which means pricing can change without billing being rebuilt.

The engine is headless and API-first. Applications, internal tools, and agents reach the same primitives through the REST API, SDKs, webhooks, and an MCP server, while product and finance teams use the interface when a human view is faster. Metering stays independent of payment processing, so Stripe, Adyen, or GoCardless can be connected without a provider's catalog becoming the source of truth.

Pricing can be assembled from whatever usage a product actually generates.

• Token metering: charges by model and by input, output, cache, reasoning, or tool call.
• Compute usage: GPU, CPU, storage, and other consumption billed from events.
• Prepaid credits: balances with automatic top-ups.
• Subscriptions: allowances, minimum commitments, and overages on top of recurring plans.
• Two operating models: Lago Direct bills your own customers, while Lago Embedded gives platforms metering and billing to offer to theirs.

The repository ships a maintained demo that prices three AI requests locally using Docker, curl, and jq. It seeds a disposable organization, reconciles the usage total independently, and retries one transaction to prove that usage does not increase. Nothing leaves the machine, and a cleanup flag removes the isolated Compose project and its data volume afterward.

Flexprice is monetization infrastructure for teams whose pricing does not fit a standard subscription tool. Applications, agents or workflows send usage events, and the platform takes over the metering, credit application, entitlement checks and invoicing that otherwise turns into custom billing code nobody wants to maintain.

Processing happens in real time. Events arrive from your backend through Go, Python and JavaScript SDKs, or stream in from a data warehouse or analytics pipeline. Once billing is computed the results flow outward, syncing invoices to a payment processor, customer data to a CRM and revenue figures to accounting.

The core splits into a handful of pieces you can adopt separately.

• Usage metering: define granular events such as API calls, compute time or database queries and aggregate them as they land.
• Credit grants: prepaid and promotional credits, automatic top-ups at thresholds, and expiry for what goes unused.
• Pricing plans: seat-based, pay-as-you-go, volume-tiered and hybrid models, with per-customer overrides and plan versioning.
• Feature management: toggles, metered limits and configuration values enforced per plan or per customer.
• Subscriptions and invoicing: proration, overages and credits produce invoice lines tied back to tracked usage.

Written in Go and self-hostable, Flexprice suits teams that dislike percentage-of-revenue fees or opaque billing logic and want to read the code that charges their customers. Local development runs on Docker Compose, and it can layer over an existing provider such as Stripe or Chargebee instead of replacing it.

Autumn sits between Stripe and your application so pricing stops leaking into your codebase. Products and plans are defined on a dashboard, your app makes a few calls, and upgrades, downgrades, cancellations, failed payments and webhooks stop being yours to maintain.

The argument behind it is that billing infrastructure gets complicated faster than teams expect. Payments are the easy half; the rest is permission management, metering, usage limits driven by cron jobs, and the race conditions that appear when all of that meets a plan change. Kept outside the application, a pricing experiment no longer starts with a database migration.

Three calls carry the integration. attach handles every purchase flow, returning a Stripe Checkout URL or processing an upgrade or downgrade. check asks whether a customer has access to a feature or has usage remaining. track records a usage event when a metered feature is consumed.

Any pricing model can be assembled from those pieces, including the common ones.

• Usage and overage: real-time limits reset on a schedule you choose, and customers are charged for going over.
• Credits: monetary or arbitrary credits that many features can draw from.
• Seat-based: customers are billed for their own users, each seat carrying its own limits.
• Pay upfront: a fixed quantity of a feature is bought in advance and used over time.
• Custom plans: large accounts are handled without altering application code.

Self-hosting needs bun, one install and one command, plus your own Postgres connection string if you want it. A hosted cloud version is available.

OpenMeter turns a stream of usage events into something a company can charge for. It meters what customers consume, works out what they are still entitled to, and carries that through pricing, subscriptions, credits and invoices, which is the machinery teams end up writing themselves once a product stops being a flat monthly fee.

Events arrive as CloudEvents, are attributed to a customer, aggregated in real time and queried by time window or dimension. The runtime is the OpenMeter API and worker processes over Kafka, ClickHouse and PostgreSQL, with Redis optional for distributed deduplication and Svix for webhook delivery. API first and composable, it can own the whole path from raw usage to invoice or only the parts your stack is missing, working with the payment and tax providers you already use.

The capabilities divide along that same path.

• Metering: ingest, attribute and aggregate usage, then query it by window or dimension.
• Product catalog: versioned plans, features, add-ons and flat, recurring, per-unit, tiered, package or dynamic prices.
• Entitlements: calculate feature access and usage-limit balances for your application to enforce.
• Billing: rate charges, manage credit balances and subscription changes, and run the invoice lifecycle.
• Integration: a REST API with JavaScript, Python and Go SDKs, webhooks and external invoicing providers.

A Docker Compose quickstart brings up a local evaluation stack, which the project is careful to label as not a production topology, and the Helm chart is likewise for development deployments. Releases are beta and can break, though the metering engine has run in production for years.

Meteroid closes the gap between what a customer used and what their invoice says. That gap is where homegrown billing goes wrong, and it widens as soon as a company moves from flat subscriptions toward usage-based or product-led pricing.

It connects to your systems through an API that collects usage and interaction data, then feeds a billing engine that applies your pricing model and generates the invoice. Ingestion is written in Rust for high-throughput events, and the project describes itself as experimental.

One platform is meant to carry monetization end to end, whether the motion is product-led, sales-led or both.

• Usage metering: API requests, tokens, transactions, storage and other raw events become billable metrics in real time, with no pre-aggregation step.
• Pricing models: flat rate, usage-based, tiered or hybrid plans, versioned so a price change never touches existing customers unless you decide it should.
• Subscription lifecycle: upgrades, downgrades, mid-cycle changes and cancellations with full control.
• Quotes: send a quote to close a custom deal, and a signed one creates the subscription and starts billing with no manual handover.
• Invoicing and credit notes: detailed invoices from simple charges through to hybrid usage billing, with corrections issued as credit notes.
• Entitlements and growth tools: feature access and metered limits, plus trials, coupons, add-ons and a self-serve customer portal.

Self-hosting instructions live in the contributing guide, and a free cloud workspace is available for anyone who wants to try the platform before running it.