Why your API balance can disappear, and how to prevent it

“My balance was gone overnight, and I don’t know what for.” This complaint almost always ends up being one of the same four mechanisms. The good news: all of them can be prevented with the right settings, not with praying.

This article dissects those four mechanisms one by one: what happens, why it’s fast, and how to close the hole. It is also the reason Giant Router is built with per-key budget limits and per-request cost reports, not as bolt-on features but as its core structure.

1. A leaked key, used by someone else

What happens: your API key is left in a public repo, in a screenshot, in a group chat, or in a config file that gets committed. Someone else finds it and uses it. The balance goes down, and you see no request you recognize.

Why it’s fast: bots scanning public repos work in minutes. A key committed a few minutes ago can already be found.

How to close it:

• Keys never go into files, commits, screenshots, or chats; use environment variables.
• If a key did leak, revoke it and create a new one IMMEDIATELY; don’t wait.
• Set a per-key budget limit. A leaked key with a Rp10,000 limit is a small incident; a leaked key without a limit is the incident of the month.

2. Loops without brakes

What happens: your app (or its agent) enters a loop calling the API nonstop: retries without delay, two agents answering each other, or code that re-calls when a response doesn’t match expectations. Every iteration is billed, and nobody presses Ctrl+C at night.

Why it’s fast: reasoning models and agents can burn many tokens per call; multiplied by hundreds of automated iterations, the number moves fast.

How to close it:

• Set a per-key budget limit; requests stop at the limit. This is the main brake, and setting it lives in the dashboard.
• In code: cap the retry count, add delays, and define a clear stop condition.
• For chatbots or cron jobs: give them their own key, separate from other work keys, so an incident in one context doesn’t sweep the whole balance.

3. Shared accounts getting blocked (balance burned with them)

What happens: you buy a “cheap API” package that turns out to be one account used by many people. The provider detects the shared-usage pattern and blocks the account. Every buyer loses access in one moment, including the balance already paid for.

Why it’s fast: this isn’t about speed, it’s about structure. One account used by many people from many locations is the easiest pattern to detect and the one most likely to end in mass blocking.

How to close it: don’t use that structure for work that matters. With your own key through an official gateway, your usage is isolated, and at Giant Router, if a model is removed or a key is blocked by the provider for something that is not your violation, the remaining tied balance is refunded pro-rata per the Balance Guarantee. The structural explanation is in official API, not shared accounts.

4. Ballooning agentic context

What happens: you use an agent (Claude Code, Cline, and the like) for a big task in one session. Every agent iteration re-sends the conversation context as input tokens. A long session carries an ever bigger context. So each next request costs more than the last, even though the task feels “the same”.

Why it’s fast: agentic cost is dominated by INPUT tokens, and input accumulates. A six-hour task that starts with a cheap request can end with requests tens of times more expensive, with no change in the price list.

How to close it:

• Split big tasks into short sessions; start a fresh context per sub-task.
• Run small iterations on a cheap model, keep big models for heavy decisions; the comparison example is in DeepSeek vs GLM vs Claude.
• Check the per-request report after a long session: this cost-climbing pattern is clearly visible there.

Short checklist (copy into your project’s README)

• Keys live in environment variables, none in files/commits
• Every key has a budget limit, sized sensibly for its context
• One key per context (dev / production / per client)
• Retries in code have count caps and delays
• The usage report is checked after the first long session
• You know where to go if a key leaks (revoke immediately, create new)

General rule: a visible cost can’t sneak around.

Note that all the fixes above stack up into the same three habits:

1. One key per context, with a budget limit; so a bad incident is locked to its scope.
2. Keys in environment variables, never in files; so there is nothing to steal.
3. Read the per-request report; so you know what the balance is being spent on, before it’s gone.

This is not a coincidence: Giant Router is designed with those three things as its basic structure: per-key budget limits that stop by themselves, a balance that cannot go negative, and per-request cost reports you can recompute. And the last piece, our contract is written: the balance will not go negative, and pro-rata refunds for cases that are not your fault.

Set up a budget-limited key, starting at Rp10,000 →