How the relay industry may move in the last three months of 2026

Set the rule first: reason only from what has happened

Industry forecasting turns into empty talk most easily, because it can be done irresponsibly. The reasoning here rests only on observable facts that have already happened, and then asks where they may take the industry.

A disclaimer first: what follows is trend reasoning, not prediction. A trend tells you which direction things are moving; it does not tell you when they arrive.

Fact one: evaluation and verification are becoming tooling

What has happened: 2026 saw a group of platforms dedicated to evaluating relay sites, each emphasising different dimensions. Some do model verification through fingerprint comparison and parameter boundary tests, some run live request measurements, some produce trustworthiness, economics and performance scores, some track community reputation, some offer an entry-level view.

What it implies:

1. Verification moves from "articles" to "tools". Testing a few sites by hand cannot cover 2,000-plus, so automated verification becomes standard equipment.
2. Evaluation granularity moves toward the channel level. Different channels on one site may come from different upstreams, so a whole-site score starts to look too coarse.
3. Methodological differences between evaluation platforms become a new information asymmetry. Availability means different things under different definitions, and that itself creates demand for methodological transparency.

What it means for users: more evaluation tools, but the ability to judge which evaluation is trustworthy becomes more valuable. Use the criteria from the article on the three leaderboard traps.

Fact two: protocol differences are being flattened at the gateway layer

What has happened: open-source gateways such as the One API family, New API and LiteLLM have moved from "unify everything into OpenAI format" to "convert in any direction": OpenAI to and from Claude messages, OpenAI to Gemini, and more. At the same time, routers have proliferated on the client side, with Claude Code Router and various derivatives.

What it implies:

1. "Can it connect" stops being the bar; "does it connect well" becomes it. The implementation quality of the conversion, chunk alignment under streaming and tool-call consistency, becomes the capability that distinguishes sites.
2. Implicit faults caused by protocol drift increase. The more rewriting layers, the higher the chance of "passes the test, fails in production". That creates a preference for implementations that rewrite as little as possible.
3. Client protocol support becomes a selection factor. Clients with native Anthropic support, and native Gemini support, gain an edge, because they carry one less conversion layer.

What it means for users: put tool-call usability and streaming implementation quality on your mandatory test list, not just "can it connect". Those two are precisely where conversion layers break.

Fact three: the price war is shifting from unit price to capability

What has happened: the number of relay sites in mainland China has passed 2,000, with a large share built on the same open-source projects. Pure unit-price competition has run out of room, because in a market of 2,000 options, price is already a fully competed quantity.

What it implies:

1. Differentiation shifts to capability: cache billing, Batch, structured output, multimodal, and enterprise governance such as sub-accounts, spending caps and audit. These combinations of upstream capability and gateway implementation become the new battleground.
2. "Not supported" becomes easier to detect. Evaluation tools are improving and the bar for capability testing is falling, so the room for claiming support you do not have shrinks.
3. High and low ends separate further. The low end keeps competing on price and carrying non-critical work; the high end moves toward enterprise governance and compliance capability. The middle ground is hardest, with neither a price advantage nor governance.

What it means for users: spelling out your capability requirements during selection pays better than negotiating on price. In a fully competed market, price room is limited, while a missing capability means you cannot build something at all.

Fact four: compliance requirements are tightening

What has happened: requirements around cross-border data transfer, personal information protection and model labelling continue to develop, and attention to whether data is used for training is rising.

What it implies:

1. "Where does the request actually end up" becomes a routine question. Using a domestic relay while the request is forwarded abroad is a chain more enterprises will put under review.
2. Data retention and training policies will be required in writing. That is one of the hard thresholds in enterprise procurement.
3. Enterprise governance capability becomes a procurement threshold. Spending caps, call logs and permission tiers move from nice-to-have to must-have.

What it means for users: build internal policy proactively — key separation, data classification, log retention, supplier management — rather than reacting later. See the article on breaking enterprise compliance into executable moves.

Three directions that are possible but not inevitable

The following are possible trajectories where the evidence is not yet sufficient. They are listed for observation.

1. The middle layer of direct official resale may be squeezed. If model vendors improve their own payment and onboarding experience, the value of a pure resale layer weakens. But cross-border compliance and payment friction will not disappear soon, so the resale layer keeps some room.
2. Vertical sites may increase. Sites that do not aggregate every model but serve one scenario, programming only or one model family only, can refine the experience further.
3. Policy risk on account-pool supply will persist. That kind of supply depends on upstream tolerance, which is an external variable: hard to predict and hard to eliminate.

Why list them separately: the evidence for these three is noticeably weaker than for the four above. Mixing them into the conclusions would mislead your sense of how certain each one is.

One sentence of advice for users

You cannot decide how the industry moves, but whether your own architecture can change suppliers is something you can decide right now.

Whichever direction the industry takes, one thing pays off with certainty: converge base_url, keys and model names into configuration, and keep a working configuration for a second supplier.

That takes half a day, and it preserves your options whichever way things move. Predicting the industry's direction, by contrast, has an uncertain payoff.

Do the certain thing first.