Frugon shows developers exactly which LLM calls are burning cash

The AI industry has spent two years building faster, cheaper models. The bottleneck is no longer capability. It is the gap between what developers pay and what they could pay, if only they knew which calls were wasteful.

A new open-source tool called Frugon tries to close that gap with a local CLI that reads your OpenAI-format call logs, prices every request against a dozen models, and tells you exactly which calls to move to a cheaper model. The creator, who goes by Rodiun, built it after his own weekly token quota ran out days into the week. He describes the tool as “deliberately small” — six commands doing three jobs: cost analysis, quality visibility, and routing recommendation. It is MIT licensed and runs entirely on your machine.

Frugon’s demo is the most concrete part of the pitch. It bundles a synthetic log of 56,100 calls representing a month of usage. The baseline model is a hypothetical “gpt-5.5” at $549.46 per month. Frugon recommends routing 36,100 of those calls (64.4 percent) to DeepSeek-V4-Flash, keeping 10,000 hard calls on the baseline, and leaving 10,000 already on the cheaper model untouched. The new monthly spend: $343.91. A saving of $205.55 per month, or 37.4 percent.

Those numbers are synthetic. But the mechanism behind them is real and worth examining.

How the recommendation works

Frugon does not guess. It uses two data sources synced locally: pricing from the LiteLLM registry and quality tiers from the LMSYS Chatbot Arena leaderboard. The “within tolerance” classification that decides which calls are easy enough to route away is derived from research published by RouteLLM, an open routing framework from the LMSYS team at UC Berkeley.

The tool’s architecture is straightforward. frugon analyze reads a JSONL file containing request and response objects in OpenAI’s format. It counts tokens, applies per-model pricing, and computes a routing recommendation based on the quality tier of each candidate model relative to the baseline. No network calls. No data leaves the machine.

For teams that want to verify the recommendation, Frugon offers two optional commands. --measure samples real prompts from the logs and sends them to candidate models using the user’s own API keys. --judge uses a chosen model to compare the responses side by side and score them as better, worse, or a tie. The creator is explicit that these calls go directly to the provider, never through a Rodiun endpoint.

The tool also includes frugon capture, a local HTTP proxy that sits between an application and its LLM provider, recording every call to a JSONL file with zero added latency. This is the recommended path for teams that do not already log their requests.

The economics are the story

The 37.4 percent saving in the demo is plausible for a general mixed workload. The RouteLLM research that Frugon cites found that for easy or repetitive tasks, savings can reach 85 percent. For hard reasoning tasks, the saving is closer to 30 percent. Frugon’s own savings bands, displayed in its README, cluster in that 30 to 50 percent range for most workloads.

What makes this relevant is the shape of the market. Frontier model pricing has fallen sharply over the past 18 months. GPT-4o, Claude 3.5 Sonnet, and Gemini 2.0 Flash all cost a fraction of what GPT-4 and Claude 3 Opus cost at launch. Yet many developer teams still route all their traffic to a single capable model, paying premium rates for tasks like data extraction, summarization, and simple classification that a smaller model could handle without meaningful quality loss.

This is not a secret. Every major inference provider offers a tiered model lineup. The friction is operational: teams do not know which calls are cheap and which are expensive because they do not measure per-task cost. Frugon’s contribution is to make that measurement trivial and local, removing the excuse that setting up cost observability is too much work.

What Frugon gets right

The tool respects a principle that most commercial AI observability platforms violate: data locality. No logs are uploaded. No API keys pass through a third party. The --capture proxy explicitly ignores ambient HTTP_PROXY and HTTPS_PROXY environment variables to prevent key leakage. For teams in regulated industries or those with strict data governance requirements, this is the difference between a tool they can use and a tool they cannot.

The quality caveat is also handled honestly. The README states in bold: “Quality is not verified — ‘within tolerance’ is an offline estimate; run --measure to confirm it on your real outputs before you switch.” That is the right warning. RouteLLM’s quality tiers are based on aggregate leaderboard scores, not on a specific application’s tolerance for error. A 64 percent routing rate that works for a summarization pipeline might break a classification system with narrow accuracy requirements.

Where it falls short

Frugon is a snapshot tool, not a routing proxy. It tells you what to do but does not do it for you. The creator explicitly gates that feature behind a hosted service at frugon.rodiun.io, which is not open source. Teams that want automatic live routing must either build it themselves or pay for a hosted gateway.

The candidate model list is also curated, not exhaustive. It draws from OpenRouter usage rankings and includes models like Claude Sonnet 4.5, GPT-4.1, Claude Haiku 4.5, Gemini 2.5 Flash, and DeepSeek-V4-Flash. That is a reasonable set for mid-2026, but it misses long-tail models and specialized fine-tunes that might offer better cost-quality tradeoffs for specific domains.

The tool also assumes OpenAI-format logs. Teams using Anthropic’s API directly, or those routing through a custom SDK that does not emit JSONL in the expected shape, will need to write a conversion layer. The README provides the expected schema, so this is a one-time cost, but it is a cost nonetheless.

What this means for AI builders

The most important number in Frugon’s demo is not the 37.4 percent saving. It is the 64.4 percent routing rate. That number says that nearly two-thirds of the calls in a typical workload can be handled by a cheaper model without degrading quality. If that holds for real logs, it implies that a large fraction of current LLM spend is waste.

The tool’s existence also signals a shift in the developer tooling landscape. A year ago, the conversation was about which model to use. Now it is about which model to use for each call. The routing problem is becoming infrastructure, not strategy. Tools like Frugon, RouteLLM, and the hosted gateways from OpenRouter and LiteLLM are making tiered routing a commodity.

Frugon is not the final answer. It is a local diagnostic that tells you whether you have a cost problem and how big it is. For a solo developer or a small team burning through API credits faster than expected, that diagnostic is likely worth the 10 minutes it takes to install and run. For larger teams, it is a proof of concept that the savings are real and that the routing logic works.

The tool is on GitHub under MIT license. The demo runs with a single uvx command. The question it poses to every developer building on LLMs is simple: do you know which of your calls are wasting money, and are you willing to find out?