Usage billing for AI products, on your own servers.
Price tokens per model, sell prepaid credit, and see what each customer costs you. Hardcount makes the invoices, and Stripe charges the card. Your billing data stays in your own Postgres.
An open-source alternative to Stripe Billing and Lago: no Stripe Billing fee, no paid edition, and light enough to run yourself. Why Hardcount →
One month of AI usage for one customer, from the demo in test mode.
1. The demo invoice. One line per model and token type, priced per million tokens.
2. Your margin, per model. What you billed against what the AI provider charged you: Sonnet 67.1%, Haiku 20.0%. Only you see this.
flowchart LR
A["Your app or LiteLLM"] -->|"usage events"| B["Hardcount<br/>counts and prices"]
B -->|"month ends"| C["Invoice + PDF"]
C -->|"saved card"| D["Stripe charge"]
D -.->|"card declined"| E["Retries and emails"]
Your app tells Hardcount what each customer used. Once the customer and its prices exist, one usage event looks like this:
curl -X POST http://localhost:8080/v1/usage-events \
-H "Authorization: Bearer $HARDCOUNT_KEY" \
-H "Content-Type: application/json" \
-d '{"event_name": "tokens",
"external_customer_id": "acme",
"quantity": 1200,
"dimensions": {"model": "claude-sonnet-4.5", "token_type": "input"},
"idempotency_key": "req-42:input"}'external_customer_id is your own ID for the customer. The dimensions pick the price: here, Sonnet 4.5 input tokens. If you send the same idempotency_key again, Hardcount counts the event once. Already run a LiteLLM proxy? It sends these events for you. Your first invoice, step by step
Try Hardcount on your own computer. It runs in test mode, where no real money moves.
You need git and Docker 24 or newer with the Compose plugin. On Windows, run it inside WSL.
1. Start Hardcount
git clone https://github.com/gethardcount/hardcount.git
cd hardcount/deploy/compose
./quickstart.shYou see: "Hardcount is running.", then your dashboard address, email, password and a test API key. The password is shown only once; the script also saves all four in deploy/compose/quickstart-credentials.json.
Open http://localhost:8080 and sign in. Hardcount opens in test mode, where no real money moves, and it is empty.
2. Run the demo
./quickstart.sh demoThe demo sets up AI token prices, creates a customer and sends token usage the way a LiteLLM proxy would. Then it moves the customer's test clock (a pretend clock for test customers) to the end of the month, and Hardcount makes the invoice, its PDF and the margin report shown above.
You see: nine steps, each ending in a green ✓, then links to the invoice and the customer. Home still reads $0, because its totals leave out test-clock customers; use the links instead. Each demo step, and where to click
3. Stop or remove it
./quickstart.sh stop keeps your data. ./quickstart.sh destroy deletes it, and cannot be undone. If port 8080 is taken, start with HARDCOUNT_PORT=9000 ./quickstart.sh.
Next: send your own usage and get a first invoice · run it for real on one VM · change Hardcount itself
The gaps Hardcount is built for:
| The gap | What Hardcount does |
|---|---|
| Stripe Billing takes a cut: 0.7% of billing volume on its pay-as-you-go plan, and its basic usage billing can't price each model and token type on one meter. | No Stripe Billing fee. Stripe only charges the card. One meter prices every model and token type. |
| Key parts sit behind a paid licence, such as automatic failed-payment retries and invoice previews in Lago. | One free edition. MIT, with no paid edition. |
| Some are heavy to run, with extra services such as Kafka and ClickHouse. | Three parts: the Hardcount server, Postgres and Redis. |
| No way to fast-forward time to test a billing change. | Test clocks: move a test customer forward a month and see the invoice before any real customer gets it. |
| A customer can cost you more than they pay, because AI costs move with usage. | Margin per customer and per model, from the provider cost Hardcount records on each usage event as it arrives. OpenMeter and Flexprice report cost too. |
Stripe still charges its normal card fee, and Stripe Tax's fee if you use it. Every claim above has a source in Why Hardcount exists, and How it compares lists where the other projects are ahead.
Pre-1.0. Hardcount is young: one maintainer, Stripe and cards only, no SDKs yet, no production users yet. Until 1.0.0, a minor release can break the API, and a patch release can change something you rely on (versioning before 1.0).
A good fit if:
- You charge by usage, most of all an AI product that prices per token, by model and token type.
- You want billing on your own servers. Usage and invoice records stay in your own Postgres. Stripe sees each charge, and the invoice lines too if you use Stripe Tax.
- You are a small or mid-size team. One engineer can run it, on one server or several.
- Your volume is up to about a million usage events a day, roughly 400,000 AI requests, however many tokens each one uses. In a 20-minute test on v0.8.0, a server listed at €6.49 a month before VAT (2 shared CPUs, 4 GB memory) took 12 events a second with no errors, about 1 million a day at that rate. Hardcount keeps every raw event, so plan 15 to 18 GB of database disk per month at that volume. How we measured
Not a fit if you need:
- Simple per-seat pricing paid by card. Stripe Billing already does that well.
- Automatic charging through a processor other than Stripe. Stripe is the only one built in today. Tell us which one you need.
- A marketplace that splits payouts between sellers (Stripe Connect). Hardcount bills your own customers.
- Revenue recognition or accounting reports. Export the data to your own warehouse.
- Quotes or multi-phase contracts for sales-led deals.
- Pricing: per-unit, graduated and package prices; rates per model and token type on one meter; a base fee plus usage on one invoice; prepaid credit that later usage draws down. AI pricing
- Billing you can trust: Hardcount never bills the same period twice, because the database refuses a second invoice for it. Every usage line on an invoice links to the events behind it. How Hardcount is engineered
- Getting paid: cards through Stripe, with automatic retries and emails when a payment fails. Customers can also pay another way, such as a bank transfer, and you mark the invoice paid. Card payment failure handling
- Running it: one Go program with its background jobs inside, Postgres and Redis. No telemetry and no licence check. Self-host
Every feature: What's in the box.
docs/README.md lists every doc by what you want to do: decide if Hardcount fits, try it, connect your product, run it in production, or contribute. Good places to start:
- How Hardcount works: from a usage event to a paid invoice, step by step
- How it compares with Lago, OpenMeter, Flexprice and Kill Bill
- Roadmap · Changelog
- Questions, or evaluating a deployment: GitHub Discussions
- Bugs: Issues. Money-path bugs are triaged first.
- Security:
SECURITY.md. Report privately, not in a public issue. - Contributing:
CONTRIBUTING.md.