Show HN: Hardcount – Self-hosted usage billing for AI products

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: one invoice line per model and token type, $5.73 due. Your margin on it is 51.9% (Sonnet 67.1%, Haiku 20.0%), shown only to you. ▶ Watch the 65-second walkthrough, narrated, with captions.

Quick start

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.

git clone --branch v0.9.2 https://github.com/gethardcount/hardcount.git cd hardcount/deploy/compose ./quickstart.sh

You 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, and it is empty.

./quickstart.sh demo

The 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

./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

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"]

Loading

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

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).

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 keeps a bill right

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. 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 Hardcount does.

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:

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.

License

MIT