How to choose

How to judge whether an
AI API relay is worth using

Four checks you can run yourself: read the multiplier correctly, measure cache hits, inspect the echoed model, reconcile usage against the bill. Send the same fixed input at least three times and drop the first — only then is the reading steady-state.

#Reading multipliers#Cache hits#Echoed model#Bill reconciliation

The four cheapest checks

≥3 calls

Cache needs repeats

A single call tells you nothing about cache hit rate; send the same input at least three times for a steady reading.

Drop call 1

Cold start is not steady state

The first call is almost always a cold start; averaging it in skews the hit rate in either direction.

2 fields

The cheapest probes

The echoed model and the usage block are two free signals for "did I get what I asked for".

1 small top-up

Try before you scale

Top up the minimum, run the whole flow, confirm the billing basis and the refund or transfer terms, and only then add volume.

Why "cheap" is the least reliable metric

The same phrase "0.1x" can mean 0.1 of the vendor list price or 0.1 of some internal accounting unit; "CNY 1 = $1 of quota" sounds like parity but it is a unit of account, not a discount. Only one number is comparable across providers: what you pay divided by the quota you receive, valued at vendor list price. Work that out first and a lot of price lists become less attractive.

Start by computing your cost per $1 of quota

Take any price list and compute: total actually paid ÷ quota received at vendor list price. Amortise one-time fees, processing fees and any expiry on bonus credit. Bonus credit with a deadline or a withdrawal restriction cannot be counted at face value. What you end up with is a single figure — currency per $1 of quota — that can be compared across providers.

How to sequence a trial

Step 1

Top up a small amount and run the whole path: sign-up, payment, key issuance, first request. What matters here is not speed but whether anything gets stuck and whether support is reachable.

Step 2

Send one fixed input at least three times, drop the first, and read the usage block on the rest. Add a unique random string per test so your own cache does not contaminate the reading.

Step 3

Sum the usage across those calls and reconcile it line by line against the bill. If it does not match, ask. If the answer is not coherent, do not scale up.

What you can measure vs what you cannot

You can measure this

① Your real cost per $1 of quota (arithmetic). ② Steady-state cache hit rate (fixed input, repeated). ③ Whether the echoed model matches the request. ④ Whether usage reconciles with the bill. ⑤ Whether there are daily caps, concurrency limits or per-transaction top-up limits.

You cannot measure this

① Where the upstream accounts come from and their standing. ② The provider's cash position and how long it will last. ③ Whether your request bodies are retained or reused. ④ Real capacity at peak. These can only be judged from terms, reputation and time — which is why "small first, scale later" beats any single test.

Two common shapes

Pay-as-you-go against a balance

You are charged for actual token consumption. Nothing is wasted and the balance carries over; what to check is the unit-price basis, whether the balance expires, and whether it can be transferred. Suits spiky usage.

Monthly plan with a daily cap

A fixed monthly fee buys a daily or monthly allowance. Cost is predictable; the catch is that unused allowance is usually neither refunded nor carried over, so the nominal unit price should be divided by what you will actually consume, not by the cap. Suits steady usage.

Three details that get overlooked

① Per-transaction top-up caps: payment channels impose them, so large amounts often need several transactions or a bank transfer — ask before you buy. ② Whether the balance can be transferred or withdrawn: most digital goods are non-refundable, so transferability decides how much you can salvage if things go wrong. ③ Whether currencies are fungible: on some platforms the local-currency and USD balances are separate ledgers and cannot offset each other.

On QCode

We price at vendor list rate times a service multiplier, the usage block in the response is the basis for deduction, and the bill can be reconciled line by line. Everything above applies to us as well — top up the minimum and run it once before deciding. Two things to state plainly: we do not offer refunds (a provisioned digital good occupies account resources immediately), but member-to-member balance transfers are supported; and the CNY and USD balances are separate ledgers that do not mix.

FAQ

Which is cheaper, a 0.1x multiplier or "CNY 1 = $1 of quota"?

They are not directly comparable — the first is a ratio against vendor list price, the second is a unit of account. Convert both to "what you pay ÷ quota at vendor list price" and you are finally using the same ruler.

How do I confirm I got the model I asked for?

Check that the model field in the response matches your request. If the echo carries a prefix, suffix or provider name that was not in your request, a rewriting layer sits in between — not necessarily bad, but worth asking what exactly it rewrites.

How do I measure cache hit rate properly?

Fix one reasonably long input, send it at least three times, drop the first (almost certainly a cold start) and read the cache-read figures in the usage block of the rest. Give each variant its own random string so separate tests do not hit each other's cache.

The bill does not match usage — am I being overcharged?

Not necessarily. Common legitimate reasons: cache writes and reads priced separately, thinking tokens counted as output, tool calls adding extra turns, and daily totals cut on local time versus UTC. Establish the basis first, then judge whether there is an error.

How do I assess the risk of a provider disappearing?

Look at whether you can start small, whether the refund and balance-transfer terms are written down, and how quickly support answers. Then look at time — how long the same domain has run steadily carries more information than any marketing copy. Do not commit a large amount up front.

Why should an unusually fast response make me suspicious?

For a given model and input there is a floor on how fast a response can be. If one call is unusually quick, glance at the output quality and the echoed model. Fast can be good news (a cache hit) — or it can mean the call did not run on the tier you assumed.

Sources

The checks on this page rely on publicly reproducible signals: the model and usage fields in the response body (defined in every vendor's API documentation) and the cache pricing rules on their pricing pages. No specific provider is named here and no unverified rumour is repeated; your own measurements and each vendor's official terms govern. Checked 2026-09-02.

Point the method at us

Top up the minimum and run it once: reconcile one bill, glance at one echo, then decide whether to scale.

Further reading

This page offers general evaluation methods and is not an assessment or endorsement of any specific provider. Terms, limits and pricing rules are governed by each provider's own pages and may change at any time.