Thesis
The point is not to pick one perfect model. The point is to build a system you can keep changing without starting over.
Models get better, cheaper, renamed, and deprecated all the time. If your whole setup depends on one provider or one version, you end up rebuilding every few months.
What should stay stable is the system around the model: how context comes in, how work gets routed, how outputs get checked, and where people step in.
You should be able to change providers without rewriting the whole thing. Prompts, workflows, evals, and docs should last longer than the model they started on.
If a better option shows up next month, you should be able to switch it in and keep going. That is a design choice, not luck.
The expensive part is not the API bill. It is losing what the system knows about your team, your work, your constraints, and your decisions.
Good context is small, clear, versioned, and easy to recover. Bad context is bloated, stale, and hard to trust.
If the work touches sensitive data, needs predictable latency, or has to keep running on your terms, start local. Keep cloud as an option, not a dependency.
This is not anti-cloud. It is just a more honest default for teams that care about control.
If the system only works because someone external keeps steering it, then it is not really installed yet.
The end state is simple: your team can run it, change it, and keep improving it without needing us in the loop every week.