Reasoning vs instruct for the local planner

Let's talk about the two conclusions that led me to this approach and testing.

1. Frontier models should be used when they are necessary. Each time my system wakes up and gathers its current state, I pay for tokens before any work happens, so the monthly cost climbs with the amount of work assigned. Open weight models need to be used where they fit.
2. Bad actors are building more sophisticated ways to steal data and breach systems using AI. To have a chance at defense, you have to interrogate the input, the plan, the execution, and the egress, meaning anything leaving for the outside world. That takes hooks into each of those stages.

If you are building on AI, are cost and security pushing you toward open weight models too, or somewhere else?

I need a planner that knows the tools it can call and can build a plan to solve a request with them. I want it running locally, reaching for a frontier model when a request needs one. So the test was narrow. Which local model can I trust as the brain?

I ran 34 prompts to see the difference between reasoning and instruct models.

1. DeepSeek R1 distill, 14B parameters. A variant tuned for reasoning that writes a <think> block before answering.
2. Qwen3 30B A3B Instruct. A sparse mixture of experts model that just answers, with 3B active parameters per token.

Both produced valid JSON. The difference was whether the plan matched the request. The reasoning model caught half the prompts where no tool matched. The half it missed failed though it reported success.

"Text my wife" became an email. "Push the latest changes to GitHub" became list_directory, read_file, summarize_text, with an expected_outcome field that said the user's changes were pushed to GitHub.

The plan claimed it did something it never did, which broke my trust. The instruct model caught those cases and ran roughly three times faster, though it took two more changes to the system prompt to get there. The fix was providing guidance the model could apply on its own.

1. Do not mark a request impossible when the user can clarify.
2. Imagine the user answers your clarification question perfectly. Can the plan complete with the tools in the catalog? Yes means clarify. No means impossible.

Qwen3 then hit 100% on both categories.