Official API vs relay service: where the difference really lies, worked out

Start by listing the dimensions

Most people compare unit price. The decision actually involves four dimensions:

Cost: the official channel is not automatically pricier

This is the most counter-intuitive part.

When a relay service is cheaper (rate below 1): the site has a volume discount from its upstream and passes part of it on to you. Here the relay service really is cheaper.

When a relay service is more expensive:

• Rate above 1 (you are paying for payment convenience)
• The site does not support prompt caching - this one item can multiply your real cost several times over
• Hidden markup in the billing rules (thinking tokens billed twice, for instance)

So "relay services are always cheaper" is wrong. Work it out from your actual token mix.

Barriers: the real value of a relay service

For individual developers and small teams this is often the deciding factor:

If your main obstacles are payment and network, the value of a relay service is real - convenience is exactly what it sells.

Reliability: the official advantage is accountability

Official APIs fail too, but they have:

• A public status page and incident notices
• An explicit service-level commitment
• A legal entity you can hold to account

A relay service's reliability depends on several layers: its own nodes, its upstream channels, and its upstream's upstream. The longer the chain, the more places it can break.

That does not make relay services unstable by definition - a well-run site can be very stable. The difference is that when something goes wrong, you can find out why, and hold someone accountable.

Feature completeness: the most easily overlooked dimension

Official APIs have every endpoint working. A relay service may have implemented only "the popular ones".

Typical gaps:

• Newer protocols (the Responses API)
• Tool-calling fields
• Streaming details (some sites buffer the whole response)
• Special parameters (caching, thinking budget)

How to check: do not just send "hello" - run your real workflow through it.

A decision framework

What is your main obstacle?
- Payment or network does not work  -> relay service (this is its core value)
- High data sensitivity             -> official, or self-hosted
- You need full features            -> official
- You only care about cost          -> work it out from your token mix, not the rate

How large is your usage?
- Very small  -> relay service (low barrier, cheap to try)
- Medium      -> either; go back to the obstacles above
- Very large  -> worth doing the maths; self-hosting may win

A pragmatic combination

You do not have to pick one. A common high-performing setup:

• Primary traffic through a relay service (cheaper, easy to pay for)
• Keep an official channel as a fallback (usable when it matters)
• Keep base_url as a configuration value (switching costs one line)

That gives you the relay service's cost advantage with the official channel as a reliability backstop.

Related reading

• From list price to your invoice: a worked cost conversion
• Self-hosting a gateway vs buying a relay service: cost and where each fits
• Mainland sites vs overseas platforms: payment, latency, compliance