Show HN: Flexprice: Open-Source Usage-Based Billing Toolkit

[Koshima]

Hey HN, I’am Koshima, co-founder of Flexprice (https://flexprice.io/).

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.

[nk_mishra]

Hi HN, Nikhil here, CTO at Flexprice.

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.

[ChrisDan121]

Curious to hear how others have handled scale challenges in billing infrastructure:

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?

[Koshima]

Great question!

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.

[techdp]

We've been building a GenAI application with fairly simple credit-based workflows to begin with. But just a month into launch, the workflows have started getting more complex, and we’re now rolling out 4 different pricing plans with volume-based tiers.

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.

[Koshima]

Appreciate that, and glad Flexprice showed up at the right time. We’ve seen the same pattern: credit systems always look simple with one plan, but as soon as you introduce volume tiers, expirations, or promo logic, it turns into fragile code fast.

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!

[prathamxd]

Impressive, Koshima! Billing at scale ,especially with high-frequency event ingestion and credits—is notoriously tricky, so it's great to see an open-source approach to solving these pain points. The real-time debugger and usage analytics API sound particularly useful. Curious how you handle deduplication and idempotency under heavy concurrency. Looking forward to trying this out!

[Koshima]

Appreciate it. We enforce idempotency at the event level using client-provided deduplication keys, so even with high concurrency or retries, the billing pipeline stays consistent.

For internal retries, we batch in-memory and attach unique IDs before dispatch to avoid double-counting.

[hitesh_55]

Great work! The time-bucketed usage summaries and support for hybrid pricing models are super compelling. How are you handling billing-grade precision for things like token-based metering—especially when upstream services (like OpenAI) may have delays or partial responses? Also curious how you model retroactive adjustments without compromising invoice integrity.

[Koshima]

Appreciate it. For token-based metering, we lean on event-level tracking with strict timestamps and unique identifiers to maintain billing precision, even when upstream responses are delayed or partial. If OpenAI or similar services provide incomplete data, we flag those events for retry or exclusion to avoid corrupting aggregates.

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.

[zyushg]

I run my startup for fine tuning llm models for enterprises and providing them inferencing trainmyllm.ai, would love to do a POC with you guys, would solve all my billing related problems with this. Cheers

[Koshima]

Would love to set that up. We’ve seen LLM infra teams hit billing issues fast because of usage spikes, token metering, credit handling. It gets messy to build it in-house.

I’ll DM you, we can run a quick POC and see if it fits your setup. Appreciate the interest.

[eightnoteight]

being on the developer side, the realtime dashboard for admin ui is really useful for end to end testing

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

[Manish123_]

This looks similar to some of the billing tools from YC, are you guys doing anything extra?

[Koshima]

One thing we’re handling differently is entitlements. Most billing tools stop at metering and invoicing, but they don’t track what features or limits a customer can actually access based on their plan, usage, or credits. We’re building that into the system so your app doesn’t need to maintain extra state for feature flags or usage limits.