# getlago/lago: Metering and Usage-Based Billing for AI Products > Lago is an open source, API-first metering and billing engine that turns usage events into invoices. It is a strong fit for teams whose pricing changes faster than their billing stack, and a poor fit for anyone expecting a finished, hosted billing product. **getlago/lago** — Open Source Metering and Usage Based Billing API Consumption tracking, Subscription management, Pricing iterations, Payment orchestration & Revenue analytics. - Repository: https://github.com/getlago/lago - Website: https://www.getlago.com - Stars: 10,637 · Forks: 761 - Language: Go - License: AGPL-3.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/getlago-lago ## The problem Lago solves: pricing that changes faster than the billing stack Most billing systems assume a small number of plans with fixed prices. AI products break that assumption. A single request can be billed on input tokens, output tokens, cached tokens, reasoning tokens and tool calls, each with a different rate, and those rates change when a model provider changes its own pricing. Rebuilding that logic inside an application means the pricing model lives in product code and every change becomes an engineering project. Lago puts that logic in a separate service. The README describes it as "the programmable system between product usage and revenue" and gives the pipeline as usage events, metering, pricing and credits, entitlements, invoices, payments, revenue. The audience is therefore specific: teams that emit measurable usage and want to change how it is priced without shipping new application code. That includes API products, compute platforms, and any business selling seats or transactions rather than a flat subscription. The project is written in Go and licensed AGPL-3.0. It is headless and API-first, so the REST API, SDKs and webhooks are the primary interface, with the Lago UI as an optional human surface. Two operating models are documented: Lago Direct, where you monetize your own product, and Lago Embedded, where your customers monetize through your platform under your brand. ## How the metering pipeline actually works The flow starts with events. Your application sends a usage event, and Lago aggregates it into a billable metric rather than storing raw rows as the billing unit. The README lists what those metrics can represent: tokens by model, input, output, cache, reasoning or tool call; GPU, CPU and storage consumption; API calls, transactions, seats, active users or custom events. From metrics, pricing and credits are applied, then entitlements, then invoices, then payments. The important architectural claim is that metering and pricing stay independent from payment processing. You connect Stripe, Adyen, GoCardless or another provider, and that provider's product catalog does not become the source of truth for your pricing. This is the opposite of the common pattern where the payment provider's plan objects define what a customer is buying. Here the pricing model lives in Lago and the provider only moves money. The repository layout reflects that separation. There is an api directory, a separate events-processor, a front directory for the UI, a connectors directory, and a deploy directory. The docker-compose.yml pins the runtime to getlago/api:v1.53.0 and getlago/front:v1.53.0, with getlago/postgres-partman:15.0-alpine as the database. That Postgres image is a fork with partitioning support, which suggests event volume is expected to be large enough that a partitioned table matters. One design detail worth noting: the API and frontend images are versioned together in the Compose file, while the repository's own releases are tagged separately. If you pull the published images, you are running the version named in that file, not necessarily the version of the source you cloned. ## Installing Lago and running the local AI billing demo The README does not walk through a production install. It points at the maintained demo in examples/agentic-ai-demo, which is the fastest way to see the metering pipeline end to end. The stated requirements are Docker, curl and jq. Run the demo script from the repository root: ```bash ./examples/agentic-ai-demo/run.sh ``` According to the README, this starts the Lago version matching your checkout, creates a disposable local organization, and prices three illustrative AI requests. Each request sends one input-token event and one output-token event. The output shown in the README is: ```text 3 AI requests 5,000 input tokens x $0.000002 = $0.01 1,250 output tokens x $0.000008 = $0.01 Lago usage total = $0.02 ``` Docker Compose starts an isolated Lago service, then a script seeds and verifies the example through the API. The script retrieves current usage, reconciles the result independently, and retries one transaction to confirm usage does not increase. Everything stays local; the demo does not touch Lago Cloud, and the bundled credentials are disposable. To inspect the result, log into the UI with the credentials the README gives: ```text http://localhost:8080 agentic-ai-demo@example.local / agentic-ai-demo-local-password ``` Then open Customers, Agentic AI Demo Customer, Agentic AI Demo subscription, Usage. If ports 8080 or 3001 are taken, set LAGO_DEMO_UI_PORT and LAGO_DEMO_API_PORT before running. When you are finished, remove the isolated Compose project and its data volume: ```bash ./examples/agentic-ai-demo/run.sh --cleanup ``` For a real deployment, the root docker-compose.yml is the starting point. It expects environment variables including DATABASE_URL, REDIS_URL, SECRET_KEY_BASE, LAGO_RSA_PRIVATE_KEY, LAGO_ENCRYPTION_PRIMARY_KEY, LAGO_ENCRYPTION_DETERMINISTIC_KEY and LAGO_ENCRYPTION_KEY_DERIVATION_SALT. Several of these have development placeholders as defaults, so they must be replaced rather than left as-is. ## Where Lago is the wrong tool The clearest limitation is operational. Lago is a service you run, with Postgres, Redis, an API, an events processor, a frontend and object storage settings in the Compose file. That is a real deployment surface. A team with no one to own it should not start here, and the README does not pretend otherwise: it points to Lago Cloud for teams that want the hosted path. The second limitation is the licence. AGPL-3.0 is a strong copyleft licence. For most companies running Lago as an internal billing service, that is not a practical problem. For a company that wants to embed billing inside a distributed product and keep its own modifications closed, the licence is the thing to examine before writing code, and the README does not discuss the implications. Third, the README does not document rollback, migration or upgrade procedures between the tagged releases, and it does not document how to rotate the encryption keys that the Compose file requires. Those keys protect stored credentials, so a rotation story matters, and its absence from the README is a gap rather than a feature. Finally, if your pricing is a flat monthly plan and a couple of add-ons, Lago is more machinery than the problem needs. The value here comes from metering at volume and changing pricing often. Without that, you are running a partitioned Postgres and an events processor to generate invoices a payment provider could generate itself. ## Lago compared with Stripe Billing The honest comparison is Stripe Billing, because most teams considering Lago already have Stripe in the stack and Lago explicitly integrates with it. The difference in approach is where the pricing model lives. With Stripe Billing, the product catalog in Stripe is the source of truth. You create products, prices and meters in Stripe, and your application references them. That is convenient when pricing is simple and changes rarely, and it means no infrastructure to run. The cost is that complex, frequently changing pricing eventually runs into the shape of the provider's model, and your pricing logic is split between your code and a vendor's dashboard. Lago inverts that. Pricing lives in Lago, metering lives in Lago, and the payment provider is reduced to moving money. The README states this directly: connect a provider "without making its product catalog your source of truth." That is the trade. You gain control over pricing and the ability to change it without touching application code. You take on running the service, and you accept that invoices and payments are two systems that must stay in sync. For a team already comfortable operating Postgres and Redis, the trade is reasonable. For a small team without that experience, it is a large amount of new operational responsibility for a problem that may not exist yet. ## Agent interfaces, licence and what to verify before adopting Lago's agentic tooling is split across separate repositories with separate licences. The REST API and OpenAPI schema live in getlago/lago-openapi. The MCP server is in getlago/lago-agent-toolkit under MIT. There are Agent SDKs for Python and for JavaScript and TypeScript, also MIT, which wrap LLM clients and send token or model-cost events. The README claims the JavaScript SDK instruments OpenAI, Anthropic, Mistral, Gemini and AWS Bedrock clients with under 5 ms p99 wrapper overhead; that figure comes from the README and is not independently verified here. The licence split matters. The core engine is AGPL-3.0, while the MCP server and SDKs are MIT. If you are evaluating Lago for a product where copyleft is a concern, the permissive pieces are the client-side ones, and the AGPL applies to the engine you would be running or modifying. On maintenance: the repository is not archived, and the last push was on 2026-08-27. Release tags v1.52.0 and v1.52.1 both landed on 2026-08-26 and 2026-08-27, with v1.51.0 on 2026-07-27. Note that docker-compose.yml in the repository references getlago/api:v1.53.0, a version ahead of the latest listed release, so the Compose file and the release list are not describing the same point in time. What to verify first: run the demo, then read docker-compose.yml and decide what SECRET_KEY_BASE, LAGO_RSA_PRIVATE_KEY and the three LAGO_ENCRYPTION_* values will be in your environment. The README does not document how to rotate them. ## Conclusion Adopt Lago if your product emits usage events and your pricing changes often enough that rebuilding billing is a recurring cost: tokens by model, compute, seats, API calls. Do not adopt it if you want a hosted billing product with no operational surface, or if your pricing is a handful of flat plans that Stripe handles directly. Before committing, run ./examples/agentic-ai-demo/run.sh, then read docker-compose.yml and confirm what SECRET_KEY_BASE, LAGO_RSA_PRIVATE_KEY and the three LAGO_ENCRYPTION_* keys must be in your environment, because the file ships development placeholders and the README does not document key rotation. ## FAQ ### What does Lago do? Lago is an open source metering and usage-based billing engine. It takes usage events from your application, turns them into billable metrics, applies pricing and credits, and produces entitlements, invoices and payments. ### Is Lago a good open-source billing software choice? It is a strong fit when your pricing depends on measured usage and changes often, since pricing lives in Lago rather than in your application code. It is a weaker fit if you do not want to operate Postgres, Redis and an events processor yourself. ### What is a billing platform, and is Lago one? A billing platform sits between product usage and revenue, handling metering, pricing, invoicing and payment collection. Lago fits that description: the README describes it as the programmable system between product usage and revenue. ### Is Lago an open-source subscription management system? Yes. The README lists subscription management among its capabilities, including subscriptions with allowances, minimum commitments and overages, alongside self-serve plans and negotiated enterprise contracts in the same system. ## Sources - [Official documentation](https://www.getlago.com) - [Official README](https://github.com/getlago/lago#readme) - [Project repository](https://github.com/getlago/lago) - [Release notes](https://github.com/getlago/lago/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/getlago-lago