We open-sourced Tanso Core: a self-hosted monetization engine for B2B AI products. Usage metering, prepaid credits, entitlements, and Stripe billing in one Spring Boot service, with one property the rest of the stack doesn't have. Every metered event carries its cost.
Repo: https://github.com/tansohq/tanso-oss
If you sell an AI product today, your monetization stack is split across two categories of tools that don't talk to each other.
Billing platforms meter usage and generate invoices, but they have no idea what your inference costs. They can tell you a customer consumed 40,000 events. They cannot tell you whether you made money on them.
LLM observability tools know your costs down to the token, but they don't bill anyone. They can tell you a feature costs $0.038 per run. They cannot connect that to what the customer paid for it.
So margin per customer, the number that decides whether your pricing works, lives in neither system. Most teams reconstruct it in a spreadsheet, quarterly, if at all.
Tanso keeps both sides in one ledger. Every event you ingest records what you billed and what it cost you: input and output tokens, model, provider. Margin per customer, per feature, per model is a query, not a project.
Enforcement at ingestion, not at invoice time. Entitlement checks, usage caps, and credit limits are applied when the event comes in. If a customer is out of credits, the check fails now, not on a reconciliation job three weeks later. For AI products, where a runaway integration can burn real money in an afternoon, this is the difference between a limit and a suggestion.
Credits as a first-class primitive. Prepaid credit pools per customer, with grants, deductions, expirations, and full transaction history. Most AI products end up selling some form of prepaid usage. Bolting that onto a subscription-shaped billing system is painful; here it's the core model.
Stripe as a payment adapter, not the source of truth. Billing state lives in Tanso. Stripe handles payments and invoicing. That inversion matters: your catalog, subscriptions, proration, and cycle rollover are in your database, inspectable and portable, not spread across webhook handlers trying to mirror someone else's state machine.
The usual platform pieces, so you don't assemble them from scratch: multi-tenant accounts with role-based access, a product catalog with flat, usage-based, and graduated pricing, full subscription lifecycle with proration, idempotent high-throughput event ingestion.
An MCP server, so agents can operate it. This is the part I haven't seen anywhere else. Tanso ships an optional MCP server: agents can check credit balances, inspect entitlements, manage subscriptions, and pull billing insights through the same authenticated, account-scoped access as any other client. Anything that spends money or is hard to reverse requires an explicit confirmAction: true
before it executes. Off by default, one config block to enable. If you believe agents are becoming a real share of software's users, your billing system needs a native, consented path for them, not a scraped one.
Against hosted usage-based billing platforms: those are metering and invoicing businesses. They don't carry your cost side, so they can't answer margin questions, and your billing state lives in their cloud. Tanso is self-hosted, AGPL-3.0, and treats cost as a first class field on the event, not an integration.
Against LLM observability tools: those tell you what you spent. They stop before the question that follows, which is what you charged, and whether the two are in the right order. Observability is input to pricing decisions; Tanso is the system that also enforces them.
Against building it in-house: this is the version of in-house you were going to build anyway. Java 21, Spring Boot 3.5, PostgreSQL, Liquibase migrations, standard REST with OpenAPI docs. Boring on purpose. It runs anywhere you can run a container.
One thing worth being explicit about: Tanso Core is a building block, not a platform you conform to. It's a standard Spring Boot codebase you fork and shape. Swap the payment provider, add your own meters, cut the modules you don't need. The value is starting from a working ledger with the hard parts done (idempotent ingestion, proration, credit accounting) instead of from an empty repo.
Docker is the only prerequisite:
git clone https://github.com/tansohq/tanso-oss.git
cd tanso-oss/deploy
cp .env.example .env # set JWT_SECRET
docker compose up -d --build
./setup.sh # seeds a test account and prints credentials
API on localhost:8080
, docs at /swagger-ui.html
.
Because a billing system is the one dependency you should be able to read. It holds your revenue, your customer balances, and the enforcement logic between your users and your margin. That code being inspectable and self-hostable isn't a distribution strategy, it's what I'd demand as a buyer. AGPL keeps it that way.
If you're building an AI product and pricing it in credits or usage, I'd genuinely like to hear what breaks. Issues and PRs welcome: https://github.com/tansohq/tanso-oss
And if you want help standing it up or customizing it for your own product, credit models, meters, billing rules, we do that. Reach out through the repo or find me at https://tansohq.com.