How the d1 router picks between our small model and the cloud

The default pick on tryingopen.com is LFM2.5-VL 3B, marked "Runs on an edge device". As of October 14, 2026, two models on our own hardware sit behind that label. One is the small model that writes answers. The other is d1, a decision model from Liquid AI. It reads each message first and decides whether the small model answers it or a cloud model you choose does.

The board itself has its own post: Our default model runs on a palm-sized Jetson Orin Nano.

What d1 is

Liquid AI released d1-3B as open weights on October 7, 2026, alongside an experimental d1-omni-600M (Liquid's announcement). Liquid calls them decision models. Its docs say a decision model returns "calibrated probabilities across a fixed set of outcomes in a single call with zero generated tokens."

You can ask d1 a yes/no question, ask it to choose among named options, or ask for a score on a scale. It answers with probabilities in a single forward pass.

That shape suits a router. For each message we make one d1 call that asks a few questions: is it simple enough for the small model, does it need the web, were you unhappy with the last answer, and did you ask for the cloud. All the answers are ready as soon as the forward pass ends.

From Jev to d1

The edge device became the default pick on September 30, 2026. From then until October 12, routing was done by Jev, a routing model from TypeSafe. Our privacy policy at the time said TypeSafe kept what it was sent out of training and made no zero-retention promise. So the routing step sent your message to another company.

On October 12, five days after d1 came out, we moved routing to d1-3B on one of our own Jetsons. The privacy policy, effective that day, now reads: "That decision is made on our own hardware; no other company is sent your message to make it." We run the open weights ourselves on that board, so the routing decision happens entirely on our hardware. The policy adds that our devices record only the size and timing of requests.

What d1 sees

d1 reads your latest message and a little of the conversation before it, as text only. When you attach a picture, d1 gets only the note "the user attached an image" in place of the picture.

Each reply from the default pick has a Learn more link. It opens a dialog titled "How the small model answers", and its "d1, the router" tab states the main question d1 answers: "can a 3B small model on our edge device answer this well, or does it need a large model in the cloud?"

The rule since October 14

For its first two days, d1 scored code, math and expert topics as separate signals. Since October 14 it asks whether a message is simple enough for the small model, and only plainly simple messages stay there. The same tab lists the rubric:

In the same call, d1 says whether a web search would help. When it would, the page runs one search first and hands the results to the small model, so a quick lookup can stay on the edge device. That search goes to a search provider through OpenRouter and sits outside the zero-retention promise. How web search works on tryingopen covers it in full.

The bars in the Learn more panel

The "d1, the router" tab also gives one sentence about that reply: d1's chance that the small model would answer well, how long the decision took, and who answered. When the small model answered, the dialog opens on its other tab, "The edge device".

Under "What d1 noticed in this message", bars show d1's estimates, from 0 to 100%, that your message has each quality:

• Simple enough for the small model: the small model can answer this well
• Unhappy with the last answer: you were dissatisfied with the previous reply
• Needs the web: a search would help
• Asked for the cloud: you asked outright for a bigger or cloud model

Older replies still show three retired bars: Code, Math and Expert topic.

How long a decision takes

Liquid reports that d1-3B answers a single question in 50 ms on a Jetson Orin Nano, and its Hugging Face post gives 73 ms for three questions on the same board. On tryingopen, the dialog says a decision "usually takes a few hundred milliseconds". Our figure is the whole round trip: from our site over an encrypted connection to our edge devices, through d1, and back.

When something fails

The default pick keeps answering when parts of it go quiet:

• If d1 fails or takes too long, the small model keeps the turn, because "it has priority".
• If every edge device is busy or offline, the message skips d1 and goes straight to the cloud model.
• If the fleet doesn't answer within 4 seconds, the cloud model answers, "so the page keeps working with every edge device unplugged."
• A PDF always goes to the cloud. Only the cloud path reads PDFs, so a PDF skips d1. Sending pictures and PDFs, and getting files back has the details.

Every reply then draws the route it took (You → d1 router → Small model or Cloud, with a globe badge when a web search ran), folds it away after a few seconds, and leaves a line naming who answered. A reply opened from a share link starts folded. "Show route" brings the drawing back. What each reply tells you about how it was made walks through the rest of that row.

Picking the cloud fallback

The cloud model is yours to choose. The Cloud fallback picker in the composer offers every cloud model on the page (22 as of October 14, 2026), and it starts on GLM 5.3 Flash. The second edge entry, Gemma 4 E2B, is routed by d1 the same way, and its cloud fallback starts on Gemma 4 31B.

Since October 8 a provider picker has sat beside it, and your choice there applies to the fallback model. That matters for the starting fallback, GLM 5.3 Flash: with no provider picked, it goes to Z.ai's own API and carries a "Provider may log" label. Pick a provider and the fallback goes through OpenRouter with a zero-retention requirement. Choosing the company that runs your model lists the fallbacks that have no zero-retention route and explains how the provider list is built, and What zero data retention covers, and where it stops covers the limits of that requirement.