The problem
Ollama, llama.cpp and LM Studio make it easy to run a model on one machine. They all assume you're sitting at it, or at least on the same network. The moment you leave the house, the model you paid for in VRAM is out of reach, and you're back to a hosted API and its per-token bill.
Reaching it remotely means solving three things: getting through the router or firewall, keeping it private, and making it usable from the tools you already work in.
Four ways to do it
1. Port forwarding and a reverse proxy
Open a port on your router, put nginx or Caddy in front of the engine, add TLS and auth. It works and costs nothing, but your machine is now listening on the internet, you own every security update, and many ISPs and offices won't let you do it at all.
2. A mesh VPN, such as Tailscale or WireGuard
The most popular DIY answer, and a good one. Nothing is exposed publicly. The costs: a VPN client on every device that needs the model, which rules out a borrowed laptop or a work machine you can't install software on, and you still have no view of the hardware, no way to swap models remotely, and one machine at a time.
3. Move to the cloud
Rent a GPU or use a hosted API. Reachable from anywhere, but your prompts and code leave your control, and the cost scales with every token, every month. One heavy coding-agent month on a hosted API is a recurring bill. The same workload on your own card costs the electricity.
4. An outbound relay
The machine dials out to a relay and keeps one encrypted connection open; you reach it through the relay with ordinary HTTPS. No open ports, no client on the device you're using. The trade-off is that traffic crosses the relay operator's servers in transit, so you need to know exactly what they see and store, or run the relay yourself.
Side by side
| Approach | Open ports | Client on each device | Where data goes | Multi-machine view |
|---|---|---|---|---|
| Port forward + proxy | Yes | No | Stays yours | Build it |
| Mesh VPN | No | Yes | Stays yours | Build it |
| Cloud GPU / hosted API | No | No | Provider's servers | Provider's |
| Qadenza (relay) | No | No | Your machine; relay passes it through, stores nothing | Built in |
What to look for
- A written egress list. Every host the software connects to, and why. If a vendor can't give you one, you can't audit it.
- Nothing listening. Outbound-only connections from your machine.
- The API your tools already speak. An OpenAI-compatible endpoint means Cursor, Continue, the SDKs and your own scripts work unchanged.
- Revocable access. Per-tool tokens you can kill without touching the machine.
- A way out. Self-hosting the relay, or running fully air-gapped.
How Qadenza does it
Qadenza is option 4, built for people who run models on their own hardware:
- One command installs the agent and pairs the machine. No ports, no VPN.
- The relay passes requests and replies through, encrypted, and stores none of them. What it sees, and every host the agent connects to.
- Every machine in one dashboard: GPU temps, VRAM and power, plus loading, unloading and pulling models from wherever you are.
- Fit-check before you download, Ollama or llama.cpp, and models split across every GPU in the box.
- Use it from chat, VS Code, MCP or the OpenAI-compatible API.
- Run the relay yourself, or deploy the whole stack air-gapped.