Multi-model in GIDE is more than switching models

When people hear that GIDE supports many models, they usually picture a dropdown: pick a model, and the next answer comes from it. That’s part of it, but it’s the least interesting part.

In GIDE, models share one workspace. They see the same conversation, work behind the same gates, write to the same memory, and can be brought in for a single message without disturbing the rest of the session. This post walks through the four pieces that make that work, and the workflow they add up to.

1. Two models loaded at once

The old cost of switching

Until GIDE 2.4.0, GIDE loaded exactly one local model, however much memory your machine had. Switching meant restarting the model server and reloading several gigabytes of weights. Switching was technically possible, but the cost made it something you avoided.

What happens now

GIDE keeps a second local model loaded when the remaining memory genuinely fits it. The model you pick answers, and the other one stays a mention away. Switching between loaded models is instant: it’s a pointer move, not a restart, and an attached CLI session keeps its warm state.

Honest about memory

Two models in memory have to share it, and GIDE doesn’t hide that. The model picker shows free memory above the list and marks any model that won’t fit alongside the current one, with the reason. If keeping both would cost a model part of its context window, the row says so before you choose it:

both loaded: 32K → 16K

You decide whether that trade is worth it. A loaded model that isn’t answering has an unload button, which frees its memory without a restart. On machines at the hardware floor nothing changes: one model gets the whole memory budget.

Behind the picker, GIDE sizes memory by simulating the runtime’s allocator for the exact model file, rather than computing a figure. On every model and context size the team checked, that matched the runtime’s own measurements.

From the CLI:

# Keep a second model loaded next to Ornith 1.5 9B
gide models keep <model>

# Free it again without touching the rest
gide models unload <model>

2. @ a model in the middle of a conversation

One message, not a new session

Type @ in the chat and pick a model. That one message goes to the model you named. Your default doesn’t change, so the next message without a mention goes back to it.

The model you address sees the conversation so far. You don’t paste context or re-explain the task: it reads the same thread everyone else in the session has been working in.

Local and online, connected together

Since 2.4.0, local and online models are no longer either-or. You can have Ornith 1.5 9B loaded locally and Claude connected on your own key at the same time, and picking a local model no longer disconnects your online ones. Each connection keeps its own key in your OS keychain.

Here’s what that looks like in practice (model replies shortened):

you             Find every place we parse dates by hand.
Ornith 1.5 9B   [lists the call sites]

you             @Claude Plan a refactor onto one shared date helper.
Claude          [proposes a step-by-step plan]

you             Do step 1.
Ornith 1.5 9B   [makes the edits, one Write Gate at a time]

Replies say who answered on the first reply, when the answering model changes, or when you used @. When the same model answers again, they stay quiet, so the transcript doesn’t fill up with labels.

3. The same harness for every model

Bringing several models into one session only works if you can trust each of them equally. In GIDE, the controls belong to the workspace, not to the model. Why the harness matters more than the model goes through each control in more detail.

The same gates and the same log

Whichever model answers:

• Plan Gate. The plan is shown to you before anything is changed.
• Write Gate. Every file write pauses for you to accept or reject it.
• Command Gate. Shell commands show the exact command and wait for your approval.
• Folder Trust. A folder has to be trusted before any model reads or writes inside it.
• Tools and the audit log. The same tools are available, and the same audit log records what happened.

A plan Claude writes goes through the same Plan Gate as a plan from Ornith 1.5 9B. An edit Ornith 1.5 9B makes waits at the same Write Gate as an edit from Claude.

Memory that outlives the model

Memory is stored locally, on your machine, not inside any one model’s session. When you switch models, or bring one in with @, the context carries over. The model changes and the project knowledge stays.

Same harness, different dialects

“Same harness” doesn’t mean every model is forced to talk the same way. Local models differ in how they were trained to call tools, and GIDE adapts to that:

• Models whose template carries a tool format GIDE recognizes run in the dialect they were trained on.
• Models without one have their tool calls driven through an enforced JSON grammar instead.

The gates, memory and audit log sit above that layer, so they behave identically either way. The model guide lists which families fall into which group.

4. Plan with Claude, execute locally

The three pieces above add up to a workflow that a single-model editor can’t offer: use a frontier model for the turn that needs it, and a local model for everything else.

How it works

1. Load Ornith 1.5 9B as your default and connect Claude on your own key.
2. Work normally on the local model. Exploring the code, answering questions, small edits.
3. @Claude for the hard turn. Planning a tricky refactor, untangling a design problem. Claude sees the whole conversation so far.
4. Approve the plan at the Plan Gate.
5. Let Ornith 1.5 9B carry out the steps. Your next message, without a mention, goes back to the local default, which reads Claude’s plan from the same conversation. Each edit still passes the Write Gate, and each command the Command Gate.
6. @Claude again for a review if you want a second pass over the result.

This is a manual workflow, and that’s deliberate. GIDE doesn’t decide which model handles which step. You choose, one message at a time, and your default stays where you put it.

Why it costs less

Online models are billed by the tokens you send and receive. Local models aren’t: gide usage reports what each key spent, and on a local model that’s nothing. Planning is usually a short exchange that benefits most from a frontier model. Carrying out the plan is the long tail: many small edits, test runs and fixes, each a round trip.

Putting the frontier model on the planning turn and the local model on the long tail means you pay for the turns where the frontier model makes a difference, and not for the rest. The model guide puts it the same way: plan the difficult turn with a frontier model, then hand the mechanical loop back to a local model.

When you do use Claude for several turns, GIDE 2.4.2 helps here too. Every online connection uses prompt caching, so a long conversation doesn’t pay to send the same history again on every step.

Pick the local model to match the work

The local side of this workflow has to be able to carry an editing loop on its own. The model guide puts the floor for coding at 9B: smaller models can answer questions about your code but won’t reliably carry a multi-step edit. Ornith 1.5 9B, the default, sits at that floor.

The model doing the long tail doesn’t have to run on your laptop, either. With VPS & Private Servers, it can run on a VPS, VPN or tailnet you control, with your prompts staying on that network.

The short version

• Two models loaded: switching is instant, and the picker tells you what it costs before you choose.
• @ mentions: bring any connected model in for one message, with the full conversation, without changing your default.
• One harness: gates, Folder Trust, tools, the audit log and local memory behave the same for every model.
• Plan online, execute locally: your choice, step by step, with the expensive model only where it earns its place.

To see which models fit your machine, and what loading two of them costs in memory and context, see the model guide and the memory and context matrix.