The Real Cost of a Cheap OpenAI API Gateway: 4 Things to Check Beyond the Price Sheet

When developers compare an OpenAI-compatible API gateway, the first thing they look at is the per-million-token price — whichever number is lowest wins. But your actual monthly bill rarely tracks that number closely. It's usually decided by a handful of rules that never show up on the pricing page: whether failed requests get billed, whether there's a forced minimum top-up, whether your balance quietly expires, and whether rate limiting is documented or just something you discover in production.

This isn't a review of any specific gateway. It's a checklist you can run yourself — each item comes with a concrete way to verify it, so you're not left guessing.

Why the sticker price isn't the real cost

A pricing table answers one question: how much per token. It doesn't answer these:

• If a request fails, does it still get billed?
• Can you start with a $5 top-up, or is there a forced minimum?
• If you don't touch your balance for six months, does it disappear?
• If traffic spikes and you get rate-limited, do you find out ahead of time or mid-incident?

Get any one of these wrong and your actual spend drifts from the quoted price — sometimes by more than the price difference between vendors in the first place. Here's how to check each one.

1. Are failed requests billed?

This is the easiest thing to overlook and the easiest way to overpay. Upstream model providers occasionally return 5xx errors, time out, or cut off mid-generation. If a gateway bills those calls at the estimated rate anyway, you're paying for output you never got.

How to verify

Look for a gateway that documents its billing lifecycle in three explicit stages: an estimated hold placed when the request is sent, a true settlement based on actual token usage once the upstream responds, and an automatic refund with no charge if the upstream call fails outright. Those three sentences should be findable in the docs — not something support has to explain to you.

Once you have an API key, the fastest way to confirm this yourself is to deliberately trigger a failure (pass a model id that doesn't exist) and then check the usage log for that request's status and charge:

curl {GATEWAY_BASE_URL}/chat/completions \
  -H "Authorization: Bearer $APIKO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5-mini",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

A normal call returns 200 with a real usage object. Swap in a nonexistent model id and you should get a 404 (model_not_found) — and that request should never show up as a billed line item. If the gateway publishes an error-code reference, 5xx failures (upstream outages) should say explicitly that the gateway retries across channels automatically and that a final failure means no charge and the hold is released. Whether that sentence exists in the docs is a public, checkable signal.

2. Is there a minimum top-up or minimum spend?

Some gateways require you to load at least $50, or hit a monthly minimum spend, before you can use them at all. That kind of floor inflates the cost of small trials or bursty, low-volume workloads — you end up with idle money parked in an account for usage you never generate.

How to verify

Check the pricing page for top-up flexibility: multiple small denominations ($5, $20, $100-style tiers), or only one large option. A healthy signal is one-time top-ups with no forced minimum and no subscription or monthly spend commitment — "no subscription, no minimum spend" should be a plain statement on the landing page, not something buried in terms.

If sign-up gives you a small trial balance without requiring a card on file, that's a supporting signal too — it means the gateway isn't relying on a large forced prepayment to lock you in.

3. Does the balance expire?

Whether prepaid credit has an expiry date is another cost that's easy to miss. If your balance zeroes out after six months of inactivity, you're effectively paying for usage you may never get to — and for projects with irregular traffic, expiry rules can affect total spend more than the headline price difference does.

How to verify

Look for an explicit "balance never expires" statement in the docs or FAQ. A more thorough check is the transparency of the top-up flow itself: does the account show distinct states for succeeded, pending confirmation, delayed settlement, and failed — or does the number just vanish into a vague balance field and you're left guessing? A gateway willing to expose its full top-up state machine to users is generally also more trustworthy about what it promises regarding expiry.

4. Are there hidden rate limits?

Rate limiting itself isn't the problem — every gateway needs it to protect itself and the upstream providers. The problem is whether the policy is transparent: can you know your QPS ceiling ahead of time, do you get a clear status code when you hit it, or do requests just hang or time out with no explanation?

How to verify

Check whether the error-code documentation calls out 429 specifically, along with recommended handling (usually exponential backoff). A well-documented gateway should tell you exactly what to do when you hit 429 instead of leaving you to reverse-engineer the threshold through trial and error.

It's also worth checking for per-key controls — can you cap spend or restrict the model allowlist on an individual API key, and does exceeding that limit return a clear 402/403 rather than a generic error? That kind of key-level control is part of the same transparency story as rate limiting.

The one-page checklist

Here's the whole thing collapsed into something you can run through in ten minutes:

• [ ] Docs explicitly state the billing lifecycle: hold on request → settle on real usage → refund on failure
• [ ] 5xx/timeout failures are explicitly not billed
• [ ] Top-up supports small denominations, with no forced minimum spend or subscription
• [ ] Balance non-expiry is explicitly stated (or the expiry rule is clearly documented)
• [ ] Top-up states (succeeded/pending/failed) are visible, not opaque
• [ ] Error-code docs cover 429 with clear client-side handling guidance
• [ ] Per-key spend caps or model allowlists are supported
• [ ] A public status page exists, so you can tell your bug apart from their outage

None of this requires trusting anyone's marketing copy — every item is verifiable through public docs, a real API call, or a status page.

Bottom line

The price sheet is only part of the cost. What actually determines your monthly bill is failure billing, top-up minimums, balance expiry, and rate-limit transparency. Ten minutes running this checklist beats reconciling a surprise invoice after the fact.

If you want to see an example that documents these mechanisms openly, take a look at Apiko's pricing page — beyond the live rate table, the hold-and-settle billing, failure refunds, and non-expiring balance are all publicly documented. Sign-up includes an automatically granted trial balance with no card required, which is enough to run this checklist yourself before committing to anything long-term. You can also check the docs for the full integration guide and error-code reference.