Desktop Tunnel

Desktop Tunnel is for the situation where your best model lives on a desktop machine, but you want to chat from another device.

It lets you keep heavy inference on the machine that can handle it while still using Abolitus from a lighter client such as a phone, tablet, or secondary laptop.

[!IMPORTANT] Desktop Tunnel is a Premium feature.

When to Use It

Use Desktop Tunnel when:

• Your best local model runs on a desktop.
• You want to continue the same workflow from a second device.
• You do not want to expose your home machine directly to the public internet.

What It Does

In simple terms:

1. Your desktop advertises that it is available.
2. Your other device connects through the premium control plane.
3. Prompt traffic is encrypted for the session.
4. The desktop performs the actual model work.
5. Replies stream back to the client device.

The model still runs on your desktop. The second device is acting as a remote front end.

That is the most important mental model to keep in mind while debugging it.

If the desktop host is unhealthy, asleep, locked out, or misconfigured, the tunnel experience will also be unhealthy.

What It Does Not Do

• It does not turn Abolitus into a public hosted model service.
• It does not require opening your router to the world in the usual direct-hosting way.
• It does not move your provider keys into cloud sync.
• It does not make a weak client device actually run the heavy model itself.

Why People Use It

Desktop Tunnel is especially useful when:

• You have a strong desktop GPU but prefer reading and replying on a mobile device.
• You want local-model privacy without being chained to one machine.
• You want one primary local model host for your personal workspace.

Security Model

The important trust-boundary idea is this: Premium enables the control plane, not plaintext access to your story.

The tunnel session uses encrypted transport for the live exchange. That means the service helping coordinate the connection is not supposed to become a readable copy of your conversation.

From a practical point of view, the remote device is asking your desktop to perform the generation inside your own encrypted workspace context rather than handing ordinary plaintext operation over to a central hosted chat service.

Host Availability and Session Lifetime

Desktop Tunnel depends on a live host advertisement from the desktop side and a short-lived session request from the client side.

That means the system is designed around active availability rather than permanent exposure.

In normal use, expect these consequences:

• the desktop needs to stay online,
• the selected host needs to remain visible to the current encrypted space,
• and a stale connection attempt may need to be re-issued instead of endlessly retried.

This is one reason the feature feels closer to secure remote access than to a standard cloud model account.

Preconditions That Matter

Desktop Tunnel is not just "turn it on and hope." The route depends on several real prerequisites.

In practice, the tunnel workflow is healthiest when:

• your vault is unlocked,
• the relevant account session is active,
• you have selected a valid desktop host,
• and the desktop-side provider route is already functioning normally on its own.

If the host route cannot generate locally on the desktop, the tunnel will not fix that underlying problem.

Operational Limits

Expect Desktop Tunnel to depend on:

• The desktop being online.
• The desktop route itself being healthy.
• The Premium entitlement being active.
• Network conditions that are good enough for a live streamed session.

If the desktop is asleep, the local server is down, or the premium path is unavailable, the tunnel will not behave like a normal always-on cloud provider.

That is not a flaw in the concept. It is the price of keeping the model anchored to your own machine instead of moving the whole workload to somebody else's infrastructure.

Best Practices

Keep one simple fallback route ready

If a live scene matters, it is smart to have a cloud route or secondary local route available.

Use it for heavy models, not every trivial task

Tunnel is most valuable when the desktop model is meaningfully better than what the client device can run locally.

Treat it like remote access to your best local machine

That mindset helps you debug it properly. If the desktop side is unhealthy, the tunnel experience will be unhealthy too.

Use clear device labels

Clear device names make it much easier to identify the correct host machine when more than one device participates in your encrypted workspace.

Related Pages

• Read Device Handoff if you want to move scene continuity between devices rather than run generation through a remote host.
• Read Billing and Premium for the entitlement model behind Desktop Tunnel.
• Read Multi-Provider Routing if tunnel is only one route in a larger multi-provider workflow.