{"slug": "we-open-sourced-tanso-a-monetization-engine-for-ai", "title": "We open-sourced Tanso, a monetization engine for AI", "summary": "Tanso has open-sourced Tanso Core, a self-hosted monetization engine for B2B AI products that unifies usage metering, cost tracking, and billing in one Spring Boot service. The engine records both what customers are billed and what it costs to serve them, enabling margin-per-customer queries, and enforces entitlements and credit limits at ingestion time. It also includes an optional MCP server for AI agents to manage billing operations with explicit confirmation.", "body_md": "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.\n\nRepo: [https://github.com/tansohq/tanso-oss](https://github.com/tansohq/tanso-oss)\n\nIf you sell an AI product today, your monetization stack is split across two categories of tools that don't talk to each other.\n\nBilling 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.\n\nLLM 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.\n\nSo 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.\n\nTanso 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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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`\n\nbefore 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.\n\nAgainst 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.\n\nAgainst 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.\n\nAgainst 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.\n\nOne 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.\n\nDocker is the only prerequisite:\n\n```\ngit clone https://github.com/tansohq/tanso-oss.git\ncd tanso-oss/deploy\ncp .env.example .env     # set JWT_SECRET\ndocker compose up -d --build\n./setup.sh               # seeds a test account and prints credentials\n```\n\nAPI on `localhost:8080`\n\n, docs at `/swagger-ui.html`\n\n.\n\nBecause 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.\n\nIf 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](https://github.com/tansohq/tanso-oss)\n\nAnd 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](https://tansohq.com).", "url": "https://wpnews.pro/news/we-open-sourced-tanso-a-monetization-engine-for-ai", "canonical_source": "https://dev.to/tanso/we-open-sourced-tanso-a-monetization-engine-for-ai-22gj", "published_at": "2026-07-16 03:48:54+00:00", "updated_at": "2026-07-16 04:05:04.726407+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools", "ai-products"], "entities": ["Tanso", "Stripe", "Spring Boot", "PostgreSQL", "AGPL-3.0"], "alternates": {"html": "https://wpnews.pro/news/we-open-sourced-tanso-a-monetization-engine-for-ai", "markdown": "https://wpnews.pro/news/we-open-sourced-tanso-a-monetization-engine-for-ai.md", "text": "https://wpnews.pro/news/we-open-sourced-tanso-a-monetization-engine-for-ai.txt", "jsonld": "https://wpnews.pro/news/we-open-sourced-tanso-a-monetization-engine-for-ai.jsonld"}}