The local vs cloud decision

Local or cloud is not a matter of identity. It is a decision you make, per project, based on the actual constraints. The people who get burned are the ones who made it by default, in either direction.

The decision framework

Ask, in order:

1. Can the data legally and ethically leave the machine? For regulated or confidential work, the answer is often no, and the decision is made for you. This is the strongest signal.
2. What is the real cost? Local has upfront hardware and setup cost, then cheap marginal use. Cloud is cheap to start and charges forever. Run the numbers for your volume, not a blog's.
3. What does the task need? Hard, novel reasoning may need a frontier cloud model. Repetitive, private, or high-volume work often does not.
4. How much do you value control? If a vendor changing the model under you would break your system, local (or a self-hosted open model) wins.

The honest middle ground

It is rarely either/or. A common, mature pattern:

• Cloud for the occasional hard reasoning task.
• Local for the daily, private, repetitive and cost-sensitive work.
• Open weights on an inference provider as the middle path: an open model, but hosted, for when you want quality without running hardware.

The biases to watch

• "Local is always better." It is not. It is slower to set up and weaker on hard reasoning. Choose it for reasons, not identity.
• "Cloud is always easier." It is easier until the data, the cost, or the reliability question flips it.
• "Privacy does not matter for me." Maybe not, but decide that consciously, per project, rather than assuming.

The output

A written, one-paragraph decision for this project: what stays local, what may go to the cloud, and why. That paragraph is part of your design, and it is the thing you can defend to a client or a boss later.

Decide on purpose. The objective and the use-case model give you the facts; this lesson is where you turn them into a choice.