The reasoning engine

PathWise needs a model to think with, the same way a technician needs a working brain. You choose which one, and the choice is yours to change at any time.

Why PathWise needs a model at all

Diagnosing a network problem is not a fixed script. PathWise reads an error, decides what evidence to gather, weighs what it finds, and writes a proposed fix with its reasoning shown. That judgment comes from a reasoning model underneath the product. PathWise itself never remediates, it only gathers evidence and recommends, but the model is what lets it reason about that evidence instead of following a rigid checklist.

Three paths to a reasoning engine

You pick the engine in Settings, under Model, in a field named Reasoning engine. It offers three choices.

• A frontier preset, connected with your own key. This is the default. You pick from five curated providers and supply the key that provider issues you. It gives the deepest multi-step reasoning and drives the probe loop most reliably. Described in Bring your own model.
• A private local model, run with Ollama. It runs on your own machine and needs no API key, so the reasoning stays on your own hardware. Small local models call tools less reliably, so this path is a privacy option, not the capability default.
• Your own LLM. Any OpenAI-compatible endpoint you host or subscribe to, with its own base URL, model name, and key.

PathWise boots without a key, but an investigation will not start until the engine you picked has one. Add the key in Settings and it takes effect on the next run, no restart needed. Each tier has a Test connection button so you can confirm it is live before running an investigation on it.

Cost tiers, and automatic escalation

Within the Anthropic preset you choose a cost tier, because a harder model costs more per investigation. The tier is a plain dropdown in Settings, under Model.

• Best. Opus 4.8. The deepest reasoning, and the most expensive per run.
• Balanced. Sonnet 5. This is the default a fresh install runs on, chosen to keep everyday cost down while still driving the probe loop well.
• Economy. Haiku 4.5. The lightest and cheapest, for simple checks.

A cheaper tier saves money on the easy tickets and can fall short on a hard, multi-step one. Automatic escalation covers that case. It is on by default. When a run on your chosen tier comes back inconclusive, meaning it asks for more data, lands at low confidence, or the verification pass lowers its confidence, PathWise re-runs the investigation once on the best model in the ladder and marks the answer with an "escalated" badge naming the model that produced it. The gathered evidence carries into that second pass, so the stronger model re-reasons over it and can run further probes.

Escalation is deliberately narrow. It fires at most once per investigation. It never escalates a solid answer: a medium or high-confidence diagnosis stands as it is. It does nothing when you are already on the best tier, when you have turned the toggle off, or when the run has no key to bill against. So you pay for the strongest model only on the runs that could not be settled without it. Set the tier and the escalation toggle in Settings, under Model.

The tradeoff, plainly

Neither path is free of a cost. The honest comparison:

• Local is private and free to run because it uses hardware you already own and never calls out to a provider. Its ceiling is your hardware. A small machine runs a smaller model, and a smaller model reasons less deeply on a hard, multi-step diagnosis.
• A frontier model is more capable at multi-step reasoning, but every investigation you send it, including the network details it gathers along the way, travels to that provider over the network. You are trading privacy for reasoning depth.

Neither path changes what PathWise is allowed to do. Whichever model is thinking, PathWise only gathers evidence and proposes a fix. It never executes a change on your network.

The caveat that matters: tool-calling fidelity

PathWise reasons by running a loop: it calls a tool, such as a ping or a DNS lookup, reads the result, and decides what to check next. That loop depends on the model reliably asking for the right tool in the right shape, every turn. Not every model does this equally well.

This is the reason the frontier path is the default: it is the path proven to drive the probe loop reliably. It is also why, if you go local, the model is chosen for its ability to call tools correctly first and for its size second. The same discipline applies to the curated frontier presets: a provider is only marked verified once its tool-calling has actually been exercised end to end against a real investigation. Until then it is marked reserved rather than presented as equally proven.