Inferock Bench - An independent receipt for every LLM API call

by•
Inferock-bench is a local proxy that sits between your app and OpenAI, Anthropic, Gemini, or OpenRouter shaped calls. It captures per-call token usage, failures, and retries, then generates an independent receipt showing what you were billed and how much you're actually overpaying for.

Add a comment

Replies

Best

Hey PH

:wave:

We built inferock-bench because we kept paying for AI answers that died mid sentence, and nobody could tell us where the money went.

Providers give you totals. They don't give you the per call receipt you'd need to prove which answer broke, which retry ran, or which token count changed. The company that charges you also decides what counts as a failure and keeps the only detailed records.

inferock-bench runs locally as a proxy in front of OpenAI, Anthropic, Gemini, OpenRouter shaped calls. Point your existing SDK at it (change two settings: apiKey and baseURL), and it captures every call as an independent, per call record. Your provider key never touches our servers, it's used locally only, attached to provider requests.

What it catches:
- Answers cut off mid stream that still got billed
- Empty replies with billed tokens attached
- Token counts that don't match visible output
- Retries that may have silently doubled a charge
- Cache discounts you may be missing on your invoice

Every run reports a receipt: spend observed, bill-bounded money loss, time loss, and a separate "invoice-check exposure" line that never gets summed into money loss, because we don't want a louder headline at the cost of a weaker claim.

Run it in about a minute: npx inferock-bench

Its open source (FSL-1.1-Apache-2.0, converts to Apache-2.0 in 2 years).

Question for this community: has anyone here actually disputed an AI provider bill and gotten a credit? What worked?

Getting billed for mid sentence drop offs and silent retries is such a massive headache for devs having local per call receipts proxying OpenAI/Anthropic/Gemini is brilliant. To answer your question: Disputing AI bills with providers usually gets ignored unless you have concrete per-request log receipts like this. This tool gives teams actual leverage!

   Appreciate you actually answering the question, that matches what we kept hearing from others too. Without per request records the conversation with a provider ends pretty fast. You walk in with evidence instead of a feeling.

Exactly data always wins over estimates when dealing with provider support! Love the angle you guys took here.

 Thank you!

:raised_hands:

Genuinely hoping it saves a few of those support conversations.

Congrats on the launch . Good find .

Question regarding accuracy, is it possible it might not be able to distinguish a genuinely billable provider failure from valid hidden token usage, such as reasoning, refusal, cache, or tool-call tokens?

 thank you! Anything that could be legit hidden usage like reasoning, cache, or tool tokens doesn't count as loss, it just gets flagged for you to check. Only what we can prove makes the loss number.

The failed-calls and retries breakdown is the part I'd use first. One case I keep hitting might not show up there: a tool call that returns 200 with a silently corrupted value. I measured this on Anthropic models, 40 calls, none flagged the value was wrong, so it bills as a clean success and the retry logic never fires. Can the receipt catch a call that looked fine but wasn't? Or is that out of scope by design?

that one's mostly out of scope. The receipt proves what you were billed and what actually came back, so truncations, empty replies, token mismatches, retries. A well-formed 200 with a wrong value inside would pass as a clean call, we simply can't tell from the outside that the value was wrong.

  Thanks, that's a clear answer and the right boundary to hold. The corrupted-200 case really does belong to a different layer. It needs a schema or an oracle on the payload and only the caller knows what the value should be. What you're proving from the outside is exactly the part I can't check myself today, so I'd keep it that sharp. Following the launch.

Love that this sits as a local proxy instead of asking me to route traffic through another cloud service. Keeps my API keys and data where they belong.

 everything stays on your machine, we never see it.

The retry tracking caught my attention. I’ve seen failed requests become surprisingly expensive, so being able to trace each call would be useful to me.

 Failed requests being the expensive ones is such a strange truth of this stuff, you pay and get nothing usable back. Hope it earns a spot in your setup!

Thanks for hunting us. Feel free to ask if anybody has any questions about Inferock Bench.

Does anyone know of any tools that can work with web-based logins (claud.ai etc)

 we don't touch that layer. inferock-bench works where there's an API key and a baseURL to point somewhere, and web app subscriptions don't expose the per call detail we'd need. If someone has cracked that curious to see it too.

auditing your own inference bill is such an obvious gap 🔍 nice one. seeing much overbilling in the wild yet?

it really is one of those gaps hiding in plain sight. And yes, we see it, and it scales with your spend, every cut off answer and retry gets billed like a success, and at production volume that's money leaking with zero visibility. What bothers us most is that without your own records you can't even know how much it's costing you.

Retries are the part I’d put in giant font. ‘$0.04/call’ means nothing if a successful job secretly takes 6 calls. I want cost per accepted outcome.

Cost per accepted outcome is a really good way to put it. Today the receipt shows all six of those calls and what each one cost, so the secret multiplier at least stops being secret. But the roll-up per outcome is a good suggestion. We’ll try to incorporate in the following revisions!

Congrats on the launch of Inferock Bench.

Love the idea of having an independent receipt for every LLM API call. Transparent usage, billing, and overpayment tracking can be a huge win for teams working with multiple LLM providers.

Thank you so much! Multi-provider teams are exactly where things get messy fastest, a different bill from everyone and no shared way to check any of them. Hope it takes some of that pain off your plate.