Six signals that a relay service is about to disappear

One caveat first

There is no 100% reliable way to predict a relay service disappearing. It is a commercial act, not a technical failure. But commercial acts leave traces. A team running short of cash cuts costs first, then slows down updates, then stops responding — and that arc usually takes weeks to months.

The six signals below are ordered by how easily they can be observed. Any one on its own proves nothing, but three or more together are worth taking seriously.

Signal one: the exchange rate suddenly becomes absurdly good

This is the classic one.

For a normally run service, the rate is dictated by their upstream cost. They buy at a discount and resell at a discount, keeping the margin. If one day they advertise "limited-time 0.1 rate" or "triple credit on every top-up", there are only two explanations:

• they are buying growth, absorbing a short-term loss for user numbers (acceptable, but watch how long it lasts)
• they are pulling cash in fast

How to tell them apart: look at whether the promotion is sustainable. If the discount is far below their cost line (claiming a 0.05 rate when the vendor price is $3 per million tokens), the first explanation is essentially ruled out.

A useful tell: the promotion page says "3 days only" and it is still running three months later. They need the money.

Signal two: documentation and announcements stop

Go through their changelog. A healthy service keeps up with upstream changes — new models, endpoint adjustments, price changes — and each one produces an announcement.

Three months with no announcement at all, while upstream shipped new models in the same period, is a meaningful combination.

Careful with the distinction: "the docs are stale" alone proves little, since some operators simply never write docs. "Upstream changed and they showed no reaction" is a different matter.

Signal three: support response time stretches out

Before disappearing, teams usually cut support first. It shows up as tickets going from hours to days, and finally to silence.

If you are on an annual plan, deliberately raise something small that needs a human (an invoice request, say) and watch how fast it comes back. Response time is a leading indicator — more reliable than anything the site says about itself.

Signal four: refunds start meeting resistance

Note this one: a healthy operation is not afraid of refunds, because the money is there.

When conditions start appearing around refunds — "minimum ¥100 to withdraw", "20% processing fee", "allow 30 working days" — it suggests the cash is already tied up.

This is why we advise against one large top-up. Prepaid credit is a loan you make them: interest-free and unsecured.

Signal five: the service's own availability degrades

You can see this in our monitoring data. If a service previously sat in the "stable" band and recently keeps slipping into "fluctuating" — and it is not part of a broad upstream outage — it is worth noting.

One caveat: availability dips can also be an upstream problem or their own capacity expansion. It is not evidence on its own.

Signal six: the brand and domain change unexpectedly

• the primary domain suddenly changes
• the registration record is cancelled
• the official community falls silent or is dissolved

A domain change is sometimes routine (say, after being blocked). But alongside several of the signals above, it completes the picture.

So how should you protect yourself

You do not have to avoid relay services out of fear, but you can hedge cheaply:

One: top up against usage, not against bonuses. Work out your rough monthly consumption and top up a month's worth. No annual discount is worth carrying exit risk for.

Two: do not put everything in one basket. One primary, one backup. The cost increase is small; the protection against a work stoppage is not.

Three: record your balances. Keep a simple table of how much you put in at each service, how fast it burns, and what is left. A balance that suddenly burns unusually slowly is also worth noticing.

Four: prefer services that issue invoices and have a corporate account. Not because they would never vanish, but because they have more sunk cost — rebranding and reopening is far harder than for an individual operator.

A more fundamental way to think about it

Our view: treat a relay service as a replaceable channel, not as a supplier you need to trust long term.

As long as base_url is a configuration value and not hard-coded, switching channels costs one line of config. In that world, a service disappearing costs you "some balance", not "the business".

The genuinely dangerous setup is deep coupling to one service: using its proprietary SDK, depending on its special endpoints, storing your data on its backend. Then the cost of a failure is far larger than the balance itself.

Related reading

• How to check whether a relay service is quietly downgrading your model (guides)
• Six common tricks in cheap relay services (guides)
• How we measure uptime: our methodology and its limits (guides)