How to Effectively Reduce Account Bans for AI Relay Services

Wokey Team · 2026-06-27

Model providers recently carried out a massive wave of account bans — so broad that even individual users with legitimate usage got caught in the crossfire.

If you run a relay service, or if you're choosing one, this is worth thinking about seriously: are bans a matter of luck, or a matter of architecture?

My answer is the latter. Ban rates aren't random — they're determined by architecture.

Let's zoom out. When providers decide whether an account is being shared or resold, they typically look at these signals:

• IP changes & IP type — your requests suddenly jump from a residential IP to a data-center IP, or hop across different geolocations.
• Behavioral anomalies — call frequency, concurrency, and time distribution that clearly don't look like a single person.
• Multiple accounts sharing an exit — dozens of accounts' requests funneling through the same batch of IPs.
• Client fingerprint anomalies — request headers, TLS fingerprint, and device characteristics that don't match a normal client.

Stack these signals together, and the provider's risk system flags your account.

But if you ask which signal carries the most weight and is easiest to detect — I'd say it's IP.

The reason is straightforward: IP is the outermost, lowest-cost screening criterion. A request from a residential IP versus a data-center IP represents an entirely different risk tier in the eyes of a risk system. Data-center ASN + IP hopping + geographic anomaly — once these three appear together, it's practically telling the risk system "this is not a normal user."

Honestly, the architecture of conventional relay services lands squarely on this land mine: all requests exit from the relay's servers, with dozens of accounts sharing the same batch of data-center IPs. No matter how you load-balance or rotate your proxy pool, the exit point is fundamentally a server room. I've looked at solutions from other relay operators — they rotate proxies diligently, but a quick ASN lookup reveals they're all cloud providers. Different mask, same face.

That's why some people switch between three relay services and get banned every two weeks at each one — it's not bad luck, it's that every service has the same architecture.

So how do you keep the IP unchanged?

If you're an individual user, there's already a well-established approach: deploy a unified gateway like New API or One API on a home NAS, or use tools like sam-to-API, and route all provider APIs through it. Your phone, laptop, any client calling a model — none of them hit the provider directly. Instead, they go through your home device, which forwards to the provider API. This way, no matter which model you call, the exit IP from the provider's perspective is always your home broadband IP — indistinguishable from sitting at home using it normally.

What about when you're out? Use mesh networking tools like Tailscale or WireGuard to route your phone or laptop traffic back to the home NAS first, then out from home. Whether you're at a café, the office, or on a train, your requests still exit from your home broadband. The provider never sees your IP jump just because you switched Wi-Fi or toggled mobile data.

This approach is well-proven in the fnOS community and the AI self-hosting scene, with plenty of tutorials and practitioners. For individual users, it's currently the most reliable IP-pinning solution.

But this only solves one person's problem.

A relay service manages accounts from dozens or hundreds of providers. You can't go to each person's home to install a NAS and configure a gateway. You need a systematic solution that lets each provider install a lightweight node and connect to the platform — requests still exit from the provider's own network, but order distribution and traffic routing are handled centrally by the platform.

This architecture is called provider-side exit — requests exit from the provider's own network, not from the relay's servers.

An analogy: the NAS approach is like running your own roadside shop — you ship from home, handling sourcing, selection, and orders all by yourself. A Provider Node is like joining a platform franchise — you still ship from home, but orders are dispatched to you by the platform. The shipping address doesn't change; what changes is who's dispatching the orders.

This is what Wokey Provider Node does.

Installation is simple — a single command, supporting macOS, Linux, Windows, and Docker. After installation, open the local console, bind your Wokey account, and import your local subscription credentials. Once the node starts, it maintains a WebSocket connection with the Wokey platform. The platform pushes user requests over, and the node initiates the request to the vendor API locally. The entire process exits from the provider's own IP — to the vendor, this is identical to the provider normally using their own subscription.

Currently supported vendors include OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI, and more.

After running this architecture myself, the most intuitive takeaway is: it's not "fighting" risk controls — it simply never triggers the preconditions for risk detection. From the vendor's perspective, this is just a normal user at home using their own subscription, with nothing anomalous to explain.

The entire project is open-source under Apache-2.0, with the exit whitelist hardcoded in the source. It's not secure because I say so — it's secure because every line of code is auditable.

Of course, I won't claim that provider-side exit guarantees zero bans. IP is just one ban factor — call frequency, concurrency patterns, and time distribution can also trigger risk controls. No solution can guarantee a zero ban rate.

But the logic is clear: if you haven't addressed the biggest signal, every other optimization is building on sand.

The key to reducing ban rates is making your usage indistinguishable from normal. Keeping the IP unchanged is the most critical piece. Individual users have individual solutions; relay services need a systematic provider-side exit approach.

When relay competition reaches its endgame, it won't be about who has more models or lower prices — it'll be about whose architecture makes the provider unable to tell you're a relay. The service you're using right now — whose network do the requests exit from?