When to use Tokios — and when it's not the right choice

Tokios solves one specific problem: making a local model reachable from anywhere with per-user API keys, reliable streaming, and no inbound port. That’s the right solution for many setups — but not all of them. This page helps you decide honestly.

​

When Tokios IS the right choice

• You’re behind CGNAT. Your ISP uses carrier-grade NAT, so port forwarding is impossible. Tokios’s outbound-only connection works regardless.
• You need API keys for a team. Multiple teammates, external collaborators, or coding agents each need their own scoped credential (sk-tok-…) without sharing a VPN.
• Coding agent compatibility. Claude Code, Cline, Cursor, Codex, and similar tools expect a standard OpenAI or Anthropic base URL + API key. Tokios provides both.
• You want minutes, not hours. The full setup — install connector, register model, create key — takes 2–5 minutes. Building the equivalent DIY stack takes 4–8 hours.
• You need reliable SSE streaming. Tokens must arrive in real time. No proxy buffering, no timeout cutoffs mid-generation. Tokios’s gateway is built for this traffic pattern.
• You don’t want to maintain infrastructure. No nginx configs, no certificate renewals, no tunnel crash recovery. Tokios is a managed service.

​

When Tokios is NOT the right choice

​

Fully offline or airgapped

If your model runs on a network with no internet access — an airgapped lab, a secure facility, or an off-grid setup — Tokios can’t help. The connector needs to reach api.tokios.com over the internet. Use instead: Tailscale with Headscale (self-hosted coordination server) for a fully offline mesh network, or LAN-only access with the backend bound to a local interface.

​

You need full infrastructure control

If your organization requires that all traffic stays on infrastructure you own and audit — regulated industries like healthcare, finance, or government — a third-party gateway in the data path may not be acceptable. Use instead: A self-hosted stack with LiteLLM (or similar proxy) + Cloudflare Tunnel or Tailscale for networking. See Tokios vs DIY for the full layer breakdown.

​

You already have a mature stack

If you’ve already built a working setup — nginx + Cloudflare Tunnel + custom auth + monitoring — and it handles streaming correctly, switching to Tokios adds a dependency without solving a problem you have. Stay with what works. Tokios is most valuable when you’re starting from scratch or your current setup has streaming/auth pain points.

​

Multi-cloud provider routing

If you need to route across OpenAI, Anthropic, Azure OpenAI, and local models with load balancing, fallbacks, and cost tracking, Tokios isn’t designed for that. It connects callers to local backends — it doesn’t route across cloud providers. Use instead: LiteLLM or Portkey for multi-provider routing with virtual keys, budgets, and observability. You can put Tokios in front of LiteLLM for the public endpoint — see Tokios vs LiteLLM.

​

High-volume with SLA requirements

If you’re serving hundreds of users with uptime SLAs and need enterprise-grade load balancing, Tokios’s current feature set may not match what dedicated API gateways or enterprise LLM platforms offer. Use instead: Enterprise API gateways (Kong, AWS API Gateway) with dedicated LLM routing layers, or cloud provider endpoints with built-in scaling.

​

Only your own devices

If it’s just you — your laptop, your phone, your home server — and you want to reach your model from your own devices, a full API gateway with per-user keys is overkill. Use instead: Tailscale (free for up to 6 users). Install it on your server and your devices, and call the model at its Tailscale IP. See Tokios vs Tailscale.

​

Decision flowchart

Use this to find the right tool:

​

Quick comparison table