Multi-Provider Routing

One global model is convenient, but it is usually a bad long-term default.

Different scenes ask for different things.

One route may be best for deep planning, another for cheap casual conversation, another for local privacy, and another for remote access back to your own desktop machine.

Multi-Provider Routing is the part of Abolitus that lets you treat those routes as a toolkit instead of pretending one model should do everything equally well.

What Counts as a Route

In Abolitus, a route is more than a model name.

It is the full generation path you are sending the request through.

Depending on your setup, that may mean:

• a cloud routing provider,
• a direct paid model provider,
• a local OpenAI-compatible endpoint on your own machine,
• or a Desktop Tunnel route back to a stronger host device.

That distinction matters because two routes can expose the same model family and still behave differently in cost, latency, availability, and supported controls.

Why Route per Use Case

Multi-provider routing helps you balance several pressures at once:

• Quality.
• Speed.
• Cost.
• Privacy.
• Device availability.
• Feature compatibility.

Instead of forcing every conversation through one default route, you can align the route with the actual job.

What Changes Between Routes

Different routes are not interchangeable pipes.

They may differ in:

• context length,
• refusal behavior,
• reasoning quality,
• support for advanced controls such as reasoning effort or logit bias,
• token pricing,
• streaming smoothness,
• and general tone.

This is why route choice often matters almost as much as character card quality.

If one character suddenly feels flat or overly sanitized, the route may be the problem even before you touch samplers or wrappers.

Good Real-World Uses

Strong cloud route for heavy scenes

Use a stronger cloud route when you need deeper reasoning, better instruction following, or more stable long-context behavior.

This is often the right choice for:

• game-master characters,
• dense lore scenes,
• long planning exchanges,
• or scenes where instruction drift becomes expensive.

Local route for private or low-cost scenes

Use a local route when privacy or cost matters more than peak intelligence.

This is often good for:

• sandboxing a new character,
• casual companion chat,
• note-heavy worldbuilding,
• or scenes you do not want leaving your machine.

Desktop Tunnel for mobile access to a stronger machine

Use a tunnel route when your best model lives on a desktop, but you want to interact from another device.

That keeps heavy inference on the strong machine while letting the lighter device behave like a remote front end.

What This Feels Like in Practice

You do not have to mentally reset the whole app every time you change style or device.

Instead, you can build a workflow where:

• one character uses a stronger cloud route,
• another uses a cheap or local route,
• and a mobile session temporarily uses your desktop tunnel.

That makes Abolitus feel less like one generic chatbox and more like a routed creative workspace.

Privacy Boundary: The Important Distinction

Routing changes privacy, not just quality.

If you use a local model on the same machine, the inference stays local.

If you use a cloud provider, the prompt content goes directly from your browser to that provider for inference.

The Abolitus backend is not supposed to sit in the middle of ordinary inference traffic, but cloud-provider privacy is still not the same thing as local inference privacy.

This is one of the most important mental models in the whole product.

Device-Local Setup Rule

Provider definitions are local to the current device.

That means:

• API keys stay local,
• local base URLs stay local,
• tunnel host selections stay local,
• and one device can have a completely different route library from another.

Your synced creative preferences can travel across devices while the actual provider routes still need to be configured separately on each machine.

How This Relates to Failover

Routing decides what your main route library looks like.

Failover decides what happens when the primary route is unavailable, too expensive, or not capable enough for the current request.

If you want a deeper continuity strategy, read Multi-Provider Failover.

When to Keep It Simple

If you are still learning the app, start with one route first.

Multi-route workflows become much easier once you already understand your preferred sampler behavior, wrapper style, and token-budget habits.

Best Practices

Assign by responsibility, not by hype

Use the strongest route where it matters most, not everywhere.

Keep one reliable fallback in mind

If a critical scene depends on one route, know what you will use when that route becomes slow, expensive, or unavailable.

Expect style drift between model families

Even with the same character and same prompt environment, different routes can produce noticeably different pacing, tone, refusal behavior, and narrative texture.

Re-evaluate route choice before rewriting everything else

If a scene suddenly feels wrong, do not assume the character card failed.

Sometimes the route is simply mismatched to the job.

Related Pages

• Read LLM Connections if you still need to set up your route library.
• Read Multi-Provider Failover if you want ordered fallback behavior.
• Read Desktop Tunnel if one of your routes is actually a remote connection back to your own desktop.