NewAPI and Sub2API “0 Billing” Vulnerability: Content Delivered, No Charge Applied

A post on linux.do recently reopened an old wound in the API relay community: someone used a NewAPI-powered relay to have a model write a multi-thousand-word story — it took 153 seconds in total, with the first token appearing in 0.4 seconds. In other words, a full and healthy long-text call — and yet the billing panel showed a spotless 0. Out of curiosity, they tested Sub2API as well, and the results were even more intriguing: two requests (one 500 words, one 3000 words) returned full content, but the backend did not even write a usage record.

For API relay operators who earn from the price margin, this is essentially an invisible hole in their ledger.

How It Came to Light

This isn’t a new bug. A quick scroll through Sub2API’s GitHub issue list shows #1430 (“When model is set to GPT, a 0 billing issue occurs”) and #1544 (“Unconfigured model appears in system and bills as 0”) — both open for quite a while. There had been scattered reports last month, but what made it go public was a systematic reproduction test in early May comparing NewAPI and Sub2API side by side.

The general reproduction steps:

• In the client, specify a “nonstandard” or unconfigured model name (such as gpt, gpt-4, or an alias with version suffix);
• The request passes through, the relay doesn’t reject it, and the upstream responds normally;
• Check the backend billing — NewAPI logs a 0-billed request (at least visible in logs); Sub2API leaves nothing at all.

You can think of it as a cash register scanning a barcode it doesn’t recognize — instead of throwing an error or alert, it quietly processes it at zero cost.

The Two Gateways Leak Differently

From an implementation perspective, NewAPI and Sub2API are sibling branches on the same product line — multi-model aggregation gateways evolved from One API. Their core logic is simple: receive an OpenAI-compatible request → match the model name with a configured channel → forward to the real upstream → calculate billing based on token usage.

And the problem lies exactly in that “model name matching” step.

NewAPI’s issue is with an overly-permissive fallback strategy. When a requested model name isn’t explicitly configured, instead of returning 404, it runs through a default path to forward the request. Because no pricing entry exists, the billing function returns 0. The upside: a 0-cost log entry still appears, so operators monitoring logs can detect the anomaly.

Sub2API’s problem goes deeper. Based on reports, when certain unconfigured or specific model names (such as plain gpt) are requested, not only does billing fall to 0, but the entire usage write logic is skipped. This means:

• Nothing appears in the user panel;
• No trace in daily usage logs;
• You’d only notice by comparing the relay’s aggregated data to upstream billing — “downstream users sent calls, upstream billed, but you collected nothing.”

For relays managing dozens of upstream channels, daily reconciliation is practically impossible. By the time the monthly bill comes due, the hole is already gaping.

Why This Bug Survived So Long

Realistically, this kind of vulnerability isn’t rare among open-source API gateways. The root causes come down to three main factors:

1. The messy reality of model naming. Vendors like OpenAI, Anthropic, and Google frequently change model aliases, and the community adds its own — gpt, gpt-latest, claude, claude-4.5-sonnet-20260215, and so on. Gateways often implement fuzzy matching or fallback logic “for user convenience.” If that fallback is too permissive, it becomes a billing漏洞 incubator.

2. Billing and logging often run on separate code paths. In many aggregation gateways, billing hooks into the token-count callback, while usage logging follows another path. If a conditional branch returns early, both may be skipped — resulting in successful response, normal content, but no record in the system.

3. Coverage blind spots in testing. When deploying a gateway, operators only test the models they’ve configured — few bother to test “what happens if I request an unconfigured model name.” These edge cases only surface under accidental or malicious use.

Who Bears the Loss

At first glance, it’s the relay operator footing the bill, but the impact spreads farther.

If you’re a downstream user of such a buggy relay, in the short term it looks like free usage — requests succeed, content arrives, and your balance stays untouched. But once the upstream notices abnormal traffic and the relay can’t collect revenue, best case the channel gets suspended, worst case the whole relay shuts down and your prepaid funds disappear.

For the relay operator, the problem is worse. You can’t expect every user to report errors honestly — as long as the flaw exists, someone will automate exploitation. Especially with Sub2API’s “silent zero billing,” operators may not realize until their upstream bill skyrockets.

Worse still, the existence of “accidentally cheap” or “free” APIs distorts market pricing, pulling down users’ perceived value — a recurring issue across the API aggregation ecosystem.

What Relay Operators Should Do

If you’re using NewAPI or Sub2API, even privately, do the following immediately:

• Review your last 30 days of logs for 0-billing entries. NewAPI’s can be filtered easily; Sub2API requires more work — best to run a direct SELECT query in the database.
• Disable fallback for “unconfigured models.” If such a setting exists, set it to strict mode: if a model isn’t configured, reject the request outright.
• Set a fallback price per channel. Even a minimal per-token price is better than 0 — it triggers billing logic and leaves an audit trail.
• Implement an upstream/downstream reconciliation script. Run it daily to align your relay’s total usage with upstream channel consumption. Trigger alerts when discrepancies exceed thresholds.
• Monitor GitHub issues and commits. Issues #1430 and #1544 remain open with no merged fix. Subscribe for updates and apply patches promptly.

If you’re a downstream user of a relay, one reminder: “Too cheap to be true” usually means someone else is unknowingly footing your bill. Trading short-term discounts for long-term reliability is rarely worth it. For teams valuing stability, use compliant aggregators with verifiable billing — platforms like OpenAI Hub provide transparent invoices and unified keys for GPT, Claude, Gemini, DeepSeek, and other mainstream models without constantly patching open-source gateways.

A Note on the Industry

Over the past year, the API relay ecosystem has shifted from “wild growth” to “operations-intensive.” Upstream vendors are tightening API controls, combating resellers, and frequently renaming models — making mid-layer engineering exponentially more complex. Open-source projects like NewAPI and Sub2API have carried much of this burden and deserve credit, but as community efforts, they’re inherently limited in responsiveness, test coverage, and abuse handling.

Ultimately, this 0-billing bug serves as a reminder: An aggregation gateway isn’t a “set and forget” solution. Model aliases, channel fallbacks, billing/logging atomicity — loosen any one of them, and invisible holes appear in balance sheets. Building your own relay may seem cost-effective, but don’t overlook hidden operational costs, especially reconciliation — never trust the gateway’s built-in accounting alone.

As of now, neither project’s maintainers have released an official fix. Interested users can follow updates on the original issues or implement the temporary mitigations above. Once patches land, test thoroughly — billing-path changes can easily introduce new edge cases.

References

• linux.do Original Post: 0 Billing Bug Alert for NewAPI and Sub2API Users — Latest systematic reproduction comparing NewAPI and Sub2API
• Earlier linux.do Discussion — First structured community report of the vulnerability
• Sub2API Issue #1544: “Unconfigured model appearing and billing as 0” — Directly relevant open issue
• Sub2API Issue #1430: “Setting model as GPT causes 0 billing” — Earlier report of model-name-triggered zero billing