DEV Community: Tanso

We open-sourced Tanso, a monetization engine for AI

Kat Laszlo — Thu, 16 Jul 2026 03:48:54 +0000

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

The gap

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.

What it allows

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. Tools that spend money or make hard-to-reverse changes (Stripe resources, billing operations, credit grants and deductions, subscription changes) require an explicit confirmAction: true before they execute. Off by default, one YAML snippet 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.

How it's different from the alternatives

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 carries cost on every event, supplied by you or derived from plan rules, not bolted on through 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.

Try it

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.

Why open source

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.

Track Your AI Costs Per Customer in One API Call

Kat Laszlo — Wed, 25 Mar 2026 18:27:44 +0000

If you're building on top of AI APIs, you're probably calling OpenAI, Anthropic, Cohere, and a few others depending on the task. Each one bills differently. Costs shift when model prices change. And at some point, someone asks: "Are we making money on this customer?"

Without instrumentation, that question takes a day to answer. With it, it takes a query.

The problem

You ship a feature. It works. Customers use it. Then pricing changes, or a customer's usage spikes, or you realize token costs for one feature are eating your margin on that plan tier.

The issue isn't that you don't have cost data. Your AI provider invoices you every month. The issue is that data isn't broken down by your customers or your features. You see what you spent. You don't see what each customer cost you.

To know your margin per customer, you need to capture cost at the moment the AI call happens, with context attached.

One event call

After each AI API response, send one event to Tanso:

await fetch('http://localhost:8080/api/v1/client/events', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer sk_test_67d9fb04f0344036ba92ecc973f1445a'
  },
  body: JSON.stringify({
    eventIdempotencyKey: crypto.randomUUID(),
    eventName: 'chat_completion',
    customerReferenceId: 'cus_123',
    featureKey: 'ai_summarization',
    costInput: {
      model: 'gpt-4o',
      modelProvider: 'openai',
    },
    usageUnits: response.usage.total_tokens,
    costAmount: 0.05,
  })
})

A few things worth noting:

eventIdempotencyKey required. If the same event is sent twice (network retry, duplicate webhook), Tanso deduplicates silently. Use crypto.randomUUID() per call, or derive it from your own request ID if you need stable deduplication.

customerReferenceId your customer's ID, whatever you already use. Tanso maps this to their account.

featureKey ties the event to a specific feature on the customer's plan. This is how Tanso separates cost for ai_summarization from document_export from chat_completion.

costAmount dollars, not cents. Pass 0.05, not 5 for 5 cents.

costInput model and provider metadata. Used for cost attribution when you want Tanso to calculate costs from usage rather than passing them explicitly.

That's it. No batch jobs. No ETL. No scraping provider invoices.

What you get

Once events are flowing, Tanso aggregates them in real time by customer and feature.

Margin by customer. You know what cus_123 costs you this billing period, broken down by feature. Compare that to what they're paying. That's your margin.

Margin by feature. If ai_summarization on your Starter plan is consistently underwater, you see it before it shows up as a bad quarter.

Usage against plan limits. Tanso tracks usageUnits against the feature's limit on the customer's plan. The entitlement check API (POST /api/v1/client/entitlements/check) returns current usage and limit in real time, so you can gate access before a customer blows past their quota.

Automatic Stripe sync. Events flow through to Stripe Billing Meters and land on the customer's next invoice. You don't manage the billing side separately.

Works from anywhere

You don't need a dedicated service to send events. Tanso's event API is an HTTP POST. That means it works from:

Your backend add the call after any AI API response
Your terminal curl for one-off testing or backfilling
An AI agent Tanso exposes an MCP server, so Claude Code and other agents can instrument their own AI calls natively, or query cost data while they work

curl -X POST http://localhost:8080/api/v1/client/events \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk_test_67d9fb04f0344036ba92ecc973f1445a" \
  -d '{
    "eventIdempotencyKey": "550e8400-e29b-41d4-a716-446655440000",
    "eventName": "chat_completion",
    "customerReferenceId": "cus_123",
    "featureKey": "ai_summarization",
    "costInput": {
      "model": "gpt-4o",
      "modelProvider": "openai"
    },
    "usageUnits": 1847,
    "costAmount": 0.05
  }'

Get started

Get an API key from the Tanso dashboard
Configure a feature on your plan (e.g., ai_summarization) with the expected pricing model
Add the event call after each AI API response in your code
Check the dashboard, cost and usage data appears immediately

If you want to verify an event landed correctly, the dashboard shows raw event history per customer. You can also check a customer's current entitlement state at any time via the entitlement API.

Tanso is built for teams shipping on top of multiple AI APIs who need to know their economics at the customer level, not just at the invoice level. The event API is the foundation. Everything else, entitlement checks, metered billing, plan enforcement, runs on the same data.

Would love to hear if this is helpful or not. Happy to chat!

The Docs:

tanso-core.readme.io

We built an MCP server so AI coding tools can set up your entire billing system

Kat Laszlo — Wed, 18 Mar 2026 21:55:09 +0000

We built an MCP server so AI coding tools can set up your entire billing system

Every AI and API company we've talked to ends up building the same internal system. Redis counters tracking credits. Cron jobs reconciling usage. If-statements scattered across the codebase gating feature access. It starts as a quick hack when you launch your first pricing tier and becomes a permanent headache every time pricing changes.

Billing platforms like Stripe handle what happens after usage. They meter events, generate invoices, process payments. But nothing in that stack answers the question that matters at runtime: should this request be allowed to run?

Does this customer have enough credits? Are they within their plan limits? Is this feature included in their subscription? That logic is still on your engineering team.

That's what we built Tanso for.

One API call before the request runs. Subscription state, usage limits, and credit balance checked simultaneously. Allow or deny. If denied, no compute runs. No cost incurred. No surprise invoice.

// Check before running compute
const { isAllowed } = await tanso.entitlements.evaluate({
  customerReferenceId: "cust_482",
  featureKey: "ai-analysis",
  usage: { usageUnits: 1 }
});

// Denied? No compute runs. No cost incurred.
if (!isAllowed) return res.status(403);

// Safe to run. This request is billable.
const result = await openai.chat.completions.create({ ... });

The MCP server

We shipped an MCP server with 34 tools so AI coding tools can configure the whole thing. Claude Code, Cursor, VS Code, Windsurf, and ChatGPT can:

Create plans with graduated pricing tiers
Link features with usage limits and cost models
Onboard customers and create subscriptions
Check entitlements and ingest usage events
Set up model-aware cost tracking for LLM spend

No dashboard clicking required. Point your coding agent at the MCP and describe what you want.

MCP config:

{
  "mcpServers": {
    "tanso": {
      "url": "https://api.tansohq.com/mcp",
      "headers": {
        "X-API-Key": "sk_live_your_api_key_here"
      }
    }
  }
}

We also have AI-native docs so coding agents can read the full API in context: https://tansohq.com/llms-mcp.txt

How it fits with Stripe

Tanso plugs into your existing Stripe setup. You define plans and features in Tanso. Invoices push to Stripe. Payment status flows back automatically. Your payment processor still handles transactions. Tanso controls the pricing logic in your product.

What we're seeing

Every team we talk to has some version of this held together with internal tools. The pattern is always the same:

Ship a simple pricing tier
Hardcode some limits
Pricing changes, nothing updates
Customers exceed limits, nobody notices until the invoice
Spend weeks rebuilding

If that sounds familiar, we'd love to hear what you ended up building. What broke first?

Self-serve is live with a free tier at tansohq.com.