A relay selection decision tree: working back from your scenario to a site

Why "which is best" is the wrong question

There is no "best relay site", because the constraints of different scenarios conflict:

• Production demands stability, which conflicts with rock-bottom pricing.
• Batch work demands low cost, which conflicts with low latency.
• Agent work demands reliable tool calling, which conflicts with cheap.

So the first step is not comparing sites, it is being clear about your own constraints.

Layer one: establish the purpose and the key constraints

Answer four questions first.

1. What is this for?

2. What are the hard constraints?

• Must a particular capability be supported — caching, Batch, structured output, multimodal, tool calling?
• May the data leave the jurisdiction?
• Do you need invoicing or bank transfer?
• What are the latency requirements, interactive or offline?

These are must-haves, not nice-to-haves. Anything that fails them is eliminated, and you do not compromise because it is cheap.

3. Roughly what monthly volume?

Volume determines three things: the price you can get, whether to self-host, and whether to do budget control.

4. How much loss can you absorb if something breaks?

• Cannot be interrupted → you need two suppliers plus a gradual migration plan.
• A few hours of interruption is tolerable → one supplier plus a backup configuration.
• Does not matter → one supplier.

Layer two: turn constraints into checkpoints

Convert the answers from layer one into a checklist. Take "production plus tool calling plus cannot be interrupted" as the example:

Must pass:
[ ] All four tool-calling cases pass (see the tool use compatibility article)
[ ] All six streaming checks pass (see the streaming failure article)
[ ] Availability over the last 30 days at or above 99% (our monitoring page)
[ ] Call logs provided, filterable by key
[ ] Multiple keys plus spending caps
[ ] A clear invoicing and refund path

Nice to have:
[ ] Cache billing supported
[ ] IP allowlist supported
[ ] A status page
[ ] A usage query API

The key point: apply the must-pass filter first, and look at nice-to-haves second. Reverse the order and price will lead you around.

Layer three: verification, which cannot be skipped

For the three to five sites that survive the first filter, do four things:

1. Run capability tests: tool calling, streaming, structured output, caching.
2. Small reconciliation: top up the minimum, run a batch of real tasks, and reconcile against your estimate.
3. Concurrency ramp: find the capacity knee, as in the evening peak article.
4. Observe one business cycle, including a peak period.

Item 4 is the one most often skipped, and it is what separates "works fine normally" from "works fine when it matters".

Layer four: settle the operating strategy

Once chosen, three more things:

1. Top-up strategy

A single top-up no larger than one month of usage. That rule matters more than any discount. See the five terms to check before topping up.

2. Backup plan

• Keep at least a second supplier configured. It need not be enabled, but the configuration should exist and be switchable at any moment.
• The backup need not be the same tier. Its job is "keep the business running when the primary fails", not "deliver an identical experience".

3. Monitoring and reconciliation

• Your own probe, as in the build your own probe article.
• Call logs, as in the logging and reconciliation article.
• A usage alert: notify when usage passes twice the trailing 7-day average.

The complete decision path

1) What is the purpose?
   |- Critical production path -> stability first, price second -> sites that pass all must-haves
   |- Development and testing  -> cost first -> the cheapest usable site, with a small cap
   |- Batch offline            -> cost plus throughput -> low-price tier plus your own validation
   |- Agent                    -> tool-call reliability first -> the four cases are mandatory
   \- Personal learning        -> convenience first -> any site a desktop client can reach

2) What are the hard constraints? (capability / data compliance / invoicing / latency)
   \- Anything failing them is eliminated without regard to price

3) Verify among three to five candidates
   |- Capability tests (tools / streaming / structured / cache)
   |- Small reconciliation
   |- Concurrency ramp
   \- Observe one business cycle

4) Settle the operating strategy
   |- Top up no more than one month of usage
   |- Keep a second supplier configured
   \- Probe plus logs plus alerts

5) Once running
   \- Review quarterly: price, availability, whether better options have appeared

Three common selection mistakes

Mistake one: looking at a leaderboard before looking at your needs

A leaderboard ranks someone else's scenario. Your constraints differ, and copying it directly lands you on an unsuitable site.

Mistake two: prepaying large amounts for a discount

The gain from a discount is certain, say 20%. The risk is total, since the balance may never come back. Trading a certain gain for a risk of total loss is a bad deal.

Mistake three: looking only at price and never testing capability

Price differences are usually within a factor of two, while a missing capability means "you cannot build the feature". The latter is far more serious.

One last point

The data we provide — availability, latency, model coverage, multipliers and verification status across 194 sites — can carry you through the first-layer filter and part of the second-layer checklist.

It cannot carry you through layer three, verification, or layer four, strategy. Those depend on your own scenario.

Use our data as a sieve, not as a conclusion. That point is developed at length in the article on what the data can and cannot answer.