I changed the default model in my AI setup this week.
The tools stayed the same. The workflows stayed the same. The model changed.
I moved the default from one of the most expensive models I could pay for to DeepSeek Flash. In my use so far, the cost dropped and the quality held up on the work I actually tested: first drafts, summaries, lists, second opinions, debugging hypotheses, and other bounded tasks where I could inspect the result.
That is a narrower claim than saying the models are equal. I did not run a formal benchmark or build a complete evaluation set. I have not tested every kind of reasoning, creative writing, or real-world workload. I still keep a stronger model for difficult logic, important code, sensitive writing, and final judgment. The result is personal and provisional: for the workloads I moved, I have not seen a quality loss that justified the higher default cost.
The model is one worker inside a larger system
For a long time, I chose a model as if I were choosing a car brand. I picked the most powerful one I could afford and treated everything else as a compromise.
That felt safe. When the work mattered, I wanted the strongest model available. When the work was easy, I used the same model anyway because switching felt risky.
The bill grew because the expensive path handled everything. A summary, a first draft, a list of edge cases, and a second opinion all received the same level of model power.
The useful question turned out to be different: what kind of worker does this task need?
The model is only one part of my setup. Memory holds the facts I do not want to repeat, such as writing preferences, project conventions, goals, and recurring corrections. Skills hold the workflows and quality rules for repeated tasks. Tools let the assistant read files, run commands, inspect diffs, query services, and check whether an action actually happened. Files give the work somewhere durable to live. Handoffs carry decisions and unfinished work from one session to the next. Scheduled jobs add time to the system.
None of those parts is the model. They are structure.
That structure matters because a capable model can still produce unreliable work when the task is vague, the context is missing, or no one checks the result. A cheaper model can perform well when the job is narrow, the expected output is clear, and the workflow has a real verification step.
A model change is a personnel change, not a rebuild
My main assistant runs locally on my Mac. I use it in the desktop app for long sessions and the command line for quick work. My notes, projects, skills, and files remain in the same places. A separate coding tool handles heavier repository work. Publishing still uses the same tools.
When I changed the default model, none of that moved. The office stayed the same. Only the worker changed.
That made the switch easier to evaluate. I was not comparing two entirely different systems. I was changing one component while keeping the surrounding process stable.
Why the bill was high
The cost problem was not only the model choice. It was also the way I routed work.
I used the strongest model for simple tasks. I kept maximum reasoning on by default. I sent screenshots to expensive vision models when a short text description would have been enough. I had a recurring content scan running without first proving that the results were useful. Some requests also traveled through extra layers that added overhead.
The fix was a group of small changes.
I built a model hierarchy. The cheaper model handles volume, first drafts, summaries, alternative ideas, and debugging hypotheses. The stronger model stays available for final judgment, difficult reasoning, important code, and work where a mistake is expensive.
I no longer use maximum reasoning by default. I escalate only when the problem is genuinely hard. I created a cheaper path for screenshots that mostly contain text or a simple error. Expensive vision is reserved for layouts, charts, and designs. I removed the recurring scan and use focused searches when I have a reason to run them. I moved more daily work to the command line and kept the useful memory and skills active.
Those changes reduced waste without changing the main model. That was my first clue that quality was not living in the model alone.
What I tested
DeepSeek first entered the setup as a support worker. It handled cheap volume and acted as a fallback when the main provider was slow or overloaded. Over time, that gave me enough repeated use to consider making it the default.
Before doing that, I checked the configuration, made direct calls with real questions, and used bounded tasks where a mistake would be visible and cheap. I read the output back and inspected the result instead of treating a fluent answer as proof.
The workloads I moved were practical and limited. They included summaries, lists, first drafts, second opinions, and debugging hypotheses. These are useful tasks, but they do not cover everything. They are not a benchmark, and I am not presenting them as one.
The result has been good enough for my daily default so far. I have not noticed a failure in those lanes that made the higher-cost model worth using every time. That does not tell me how Flash would perform on every hard reasoning problem, every style-sensitive essay, or every codebase. It tells me what happened in my setup, on the work I actually ran.
The quality lives in the loop
Every task starts with a boundary. I define what goes in, what should come out, and what would count as wrong.
The tools verify the output. If the work touches files, I read them back. If it touches code, I inspect the diff and run checks when possible. If it touches an external service, I confirm the target and the resulting state. The model can be wrong. Verification is a workflow step, not a feeling of trust.
Skills carry the rules for repeated work. A cheaper model following a clear process can produce more useful output than a stronger model improvising without context.
Weak work gets held. If a draft is shallow, unsupported, or in the wrong format, it is rewritten or rejected. The person running the system still decides what good looks like.
That is why the change did not feel like a downgrade in my daily lanes. The expensive model was never doing the quality work alone. The system around it was defining the task, supplying context, checking the result, and deciding whether the result was usable.
What I still lose
There are trade-offs.
The strongest model gives me a cleaner first pass on creative writing and sensitive copy. Flash needs more editing before the tone feels right. I also give hard reasoning a second check. For a genuinely difficult logic problem, I do not assume the first answer is correct. I verify it with tools, ask for another pass, or escalate to the stronger model.
I read outputs more carefully now. That is not a defect in the setup, but it is a real cost of using a cheaper default. A lower price does not remove the need for judgment.
The practical test
You do not need to replace your whole setup to find out whether a cheaper model is enough for you.
Pick one repeated workflow. Use a weekly summary, a voice-note process, a folder review, a first-draft workflow, or another task where a mistake is visible and cheap.
Define the job before you compare models. Write down the input, the expected output, and the errors that matter. Keep the surrounding tools and instructions stable. Route the workflow to the cheaper model for a defined period. Read the result back and check the evidence at the layer where the claim exists.
For writing, inspect accuracy, structure, tone, and whether the draft does the job. For code, inspect the diff and run the relevant checks. For files, confirm that the right file changed. For external actions, read the target back. Do not judge the model only by whether the answer sounds confident.
Then compare the result with the work you were already getting. You do not need a universal model ranking. You need evidence about one workload in your own system.
If the cheaper model handles that lane, save the workflow and keep the stronger model for work that actually needs it. If it fails, the test still tells you something useful: that task needs more capability, tighter instructions, better context, stronger verification, or a different division of labor.
I still keep a stronger model around. It handles the work where final judgment matters and reviews some output from the cheaper lanes. That is not a contradiction. It is the design.
Cost optimisation is not choosing the cheapest model. It is using expensive intelligence where it creates real value, and building enough structure that routine work does not pay for it by default.
In my use so far, DeepSeek Flash has been enough for the workloads I moved. The model changed. The system did not. That is the part I trust more than a broad claim about model quality.