Skip to main content
If your ISP put you behind carrier-grade NAT (CGNAT), you cannot forward a port to your machine — there is no per-customer public IPv4 address to forward it to. Run the tokios-connector next to your model instead: it dials out to https://api.tokios.com, so it needs no public IP, no port forward, and no router or ISP change. You get back one stable, authenticated endpoint you can call from anywhere.
An inbound request is blocked at the ISP CGNAT wall because there is no public IP or port to forward; the tokios-connector's outbound connection passes through the wall and reaches the Tokios gateway.

Inbound connections die at the ISP's CGNAT — there's no port to forward. The connector's outbound dial passes straight through.

​
Why CGNAT blocks port forwarding

Port forwarding works by telling your router “traffic that hits my public IP on port X should go to this device on my LAN.” That only works if your router has its own public IPv4 address in the first place. With CGNAT, it doesn’t. Your ISP has more customers than public IPv4 addresses, so it puts many customers behind one shared public IP and hands each household a private address instead. Your router’s “public” side is actually just another private address on the ISP’s internal network — there’s no unique inbound address pointing at your home for a port-forward rule to attach to. That means:
  • You cannot open port 11434 (or any port) for inbound traffic, no matter how you configure your router.
  • You cannot fix this yourself — it’s a setting on equipment inside the ISP’s network, not yours.
  • Calling your ISP to request a dedicated public IP is sometimes possible (often as a paid business-tier add-on), but it’s not something you configure directly, and it isn’t guaranteed to be offered.
This is why “just open a port” isn’t a home-server option for a large share of residential connections, and why workarounds like renting a VPS to relay traffic, or setting up reverse SSH tunnels into a box you control, exist at all — both require standing up and hardening a separate always-on server just to get inbound reachability. An outbound-only connection sidesteps the problem instead of routing around it.

​
The outbound-only fix

The tokios-connector never listens for inbound traffic. It opens a wss:// connection outward to Tokios, the same direction your browser already uses to load a webpage — so CGNAT, your router’s NAT, and most firewalls never see it as anything unusual.
1

Run your model locally, as usual

Start your backend the normal way — no OLLAMA_HOST=0.0.0.0, no bind-to-all-interfaces flag, no router changes. For example, with Ollama:
Leave it listening on http://127.0.0.1:11434 (Ollama’s default). Tokios also works with llama.cpp, vLLM, and LM Studio — see Supported backends.
2

Pair the connector

Sign in at tokios.com/console, open the Setup tab, and click Start pairing. Tokios shows a one-time claim code shaped TKS-XXXX-XXXX, valid for about 15 minutes.On the machine running your model, run the install one-liner for your OS:
Windows
macOS
Linux
Already have tokios-connector installed? Pass the code directly instead:
Back in the console, approve the device on the Setup or Connectors tab. The connector’s token is delivered over the tunnel once approved — you never see it on screen or paste it into a file.
3

Register a deployment

In the Models tab, register your local model and choose a public name — for example, llama3-tunnel. Clients send this public name, not your backend’s local model id, in the model field of every request.
4

Create an API key

In the Keys tab, click Create key. Optionally scope it to specific deployments with model-name patterns (comma-separated globs, * for all). Copy the sk-tok-… key now — it’s shown only once.
At no point in this flow does your router, ISP, or public IP address matter. The connector reached out; the console approved it; the model is now reachable through Tokios’s endpoint, not your network.

​
Use it from anywhere

The model field is always your registered deployment name, never your backend’s local model id. See Use Claude Code for persisting these environment variables across sessions.
Strict corporate or campus firewalls create the same problem as CGNAT from the other direction: inbound connections get blocked even when you do have a public IP. Because the connector only ever initiates an outbound wss:// connection, the same setup works behind those firewalls too, with no exception request to file.

​
Your model stays on your hardware — your endpoint works everywhere

CGNAT means your ISP controls inbound reachability to your home network, not you. Routing around that with a rented relay box or a reverse SSH tunnel means standing up and hardening a whole separate server. The connector removes the inbound requirement entirely: it dials out once, you approve it once, and from then on https://api.tokios.com is the stable address clients use — regardless of what your ISP does with your IP address.

Quickstart

Pair a connector and register your first model end to end.

Tunnels vs Tokios

See how this compares to Cloudflare Tunnel, ngrok, and Tailscale for streaming LLM traffic.

When to use Tokios

CGNAT is one constraint — this decision framework covers the others: team size, agent compatibility, airgap requirements, and when a different tool fits better.