Show HN: Flexprice: Open-Source Usage-Based Billing Toolkit
Flexprice is an open source monetization platform for AI & Agentic companies. You can build usage-based, credit-based, or hybrid pricing models with full control.
Usage-based billing works on paper, but breaks fast in production:
(1) High-volume data (e.g., 10k API calls/sec from AI inferences) breaks naive pipelines, dropping events and causing underbilling or customer complaints.
(2) Backfilling missing events or retroactive discounts screws up invoices, forcing 3 AM log stitching to avoid revenue leaks.
(3) Prepaid credits and trials are a mess because it requires you to handle expirations, partial deductions, and priority rules.
(4) Product teams want real-time, per-customer usage reports (e.g., “How many tokens did user X consume?”), but querying raw events requires slow, custom SQL hacks.
(5) Webhook integrations for invoicing or CRMs fail on duplicates, out-of-order events, or time zone bugs, risking customer disputes.
(6) What works for 100 users fails at 10,000 because rate limits, and idempotency leads to urgent rewrites.
This week, we’re doing a 5-day launch week, where we’re shipping a new set of billing features every day. Today’s launch includes:
(1) Fire-and-forget event ingestion with SDKs (Python, JS, Go) and auto retry handling
(2) Real-time event debugger for tracking ingestion status, filtering payloads, and inspecting failures
(3) Usage analytics API providing billing-grade summaries with filters, groupings, and time-bucketed results
(4) Prepaid credit system supporting trial credits, expirations, and configurable priority on deduction
(5) Webhook system to automate billing workflows like invoicing or subscription changes
We’re shipping new features daily. It’s early, actively evolving, and contributions are welcome. If you’ve dealt with usage-based billing, broken credit logic, or event ingestion at scale, your feedback would help.
You can read the details of the launch at https://flexprice.io/blog/the-developer-toolkit. You can clone the project and explore the repo at https://github.com/flexprice, and demo at https://www.youtube.com/watch?v=SFARthC7JXc
Would love to hear your technical critiques, edge case concerns, or how you’ve handled billing infrastructure in your own stack.
To add some context to our journey: before coming to HN, we launched on Product Hunt and spoke with over 100 companies to understand how they approach billing for AI and API-driven products. We’ve seen two main approaches:
1. *Homegrown billing stacks:* Many teams build their own systems in-house, but these quickly become a headache—especially as more products move to pure usage-based pricing or hybrid models with fixed fees. These systems are complex, require significant engineering resources to maintain, and ensuring accuracy is a constant challenge.
2. *Building on top of Stripe/Chargebee:* While these platforms are evolving to support usage-based billing alongside subscriptions, they still lack robust workflows for credits—which are becoming the new currency in usage-based models.
With Flexprice, our goal is to make it easy for developers to get started, integrate quickly, and address the less obvious pain points of usage metering and credits management. We’re focused on supporting all the pricing combinations we see emerging among AI-first companies, and on building an eventually consistent engine that can handle the realities of real-world usage data.
AI pricing models are evolving fast, and we’re eager to hear feedback from the HN community on where the pain points really are, so we can target them directly.
I was exploring how best to build a flexible credit billing system when I came across Flexprice — and I have to say, it's a great product.
Good to see you here on HN. Wishing you all the success!
Cheers.
We’re building Flexprice specifically to avoid that constant rewrite cycle, good to know it resonates. Happy to chat if you run into edge cases while scaling those new plans.
Good luck with your GenAI launch!
If you're running usage-based billing for AI, infra, or API-heavy platforms— How do you deal with high-throughput event ingestion (say, 10k+ events/sec) without dropping events or messing up customer metering?
We’ve seen setups struggle hard with:
Event ordering guarantees
Idempotency at scale
Handling retries without double-counting
Would love to hear what infra patterns, queues, or storage choices worked (or failed) for you—especially?
Our approach focuses on: - Fire-and-forget ingestion with in-memory queues so events don’t block product requests - Strict idempotency tokens tied to every event, enforced at the API layer - Lightweight retry logic that prevents double-counting but guarantees delivery under transient failures
Storage-wise, we’ve leaned on a mix of time-series DBs for raw events and pre-aggregated summaries for billing views.
Would love to swap notes on failure patterns or queue setups if you’ve dealt with similar scale.
so many of the eventually consistent stores reflect so late that its a pain to work with their SDKs
out of curiosity, what kind of metrics or observability do we get for events that got dropped due to some issue
I’ll DM you, we can run a quick POC and see if it fits your setup. Appreciate the interest.
For internal retries, we batch in-memory and attach unique IDs before dispatch to avoid double-counting.
Retroactive adjustments are handled by versioning usage records, so instead of overwriting historical events, we apply corrections as delta events. Invoices pull from the latest state, but we preserve full audit logs underneath to avoid integrity gaps.
No comments yet