The Right Tool for the Job at Hand

Opening Scene

A genuinely experienced craftsperson doesn’t reach for the pocket tool or the full workshop on a whim. They weigh the job’s actual complexity, the cost and time available, and honestly what the pocket tool was and wasn’t designed for, and only then decide. Choosing between a small and large language model deserves this exact same deliberate weighing of concrete factors.

In Plain English

A practical decision framework for choosing model size weighs several concrete factors together: whether the task shows the capability-gap signals covered in Article 9 that genuinely favor a larger model; whether fine-tuning, covered in Article 5, could close the gap for a narrow, well-defined task; the real cost difference at expected volume, covered in Article 10; and whether on-device deployment, covered in Article 8, is genuinely needed for latency, offline, or privacy reasons. No single factor decides the question alone.

The Old Way

Before this kind of multi-factor framework was applied deliberately, the choice between small and large models was often made on a single, incomplete signal:

Teams sometimes chose based on a single factor alone — raw capability, cost, or familiarity — rather than weighing the fuller set of relevant considerations together.
There wasn’t yet a well-established, shared framework for making this decision consistently across different projects within the same organization.
The decision was sometimes made once, upfront, and never revisited even as compression techniques and task requirements genuinely improved over time.

A genuine multi-factor framework, revisited as circumstances change, reflects the accumulated lessons from every individual factor this series has covered.

What’s Changing (and Why AI Is the Reason)

Organizations increasingly apply a consistent, multi-factor decision framework across projects, rather than leaving the small-versus-large model choice to individual habit or preference.
This framework treats hybrid routing, covered in Article 14, as a legitimate outcome alongside choosing either size exclusively.
The framework is increasingly revisited periodically, since compression techniques and small model capability continue to improve over a project’s lifetime.

The Metaphor, Fully Extended

The Multi-Tool	Decision Framework Concept
Weighing job complexity, cost, and the tool’s genuine limits together	Weighing capability gaps, fine-tuning potential, cost, and deployment needs together
A craftsperson’s deliberate judgment, not a habitual default	A team’s deliberate, multi-factor decision, not a default habit
Revisiting the choice as tools and jobs genuinely change	Revisiting the choice as model capability and task requirements change
Sometimes carrying both the pocket tool and workshop access	Sometimes choosing hybrid routing between small and large models

For Beginners: What to Actually Do

Practice walking through this framework’s factors explicitly for a real or hypothetical project, rather than jumping straight to a preferred model size.
Learn to weigh factors together rather than letting any single one — like cost alone — decide the question in isolation.
Get comfortable revisiting a past model-size decision periodically, checking whether the same factors still point the same way.

For Practitioners and Leaders: The Deeper Layer

Formalize a shared, multi-factor decision framework across your organization’s projects, rather than leaving the choice to individual habit.
Build a periodic review cadence for revisiting past decisions, since small model capability continues to improve over time.
Treat hybrid routing, covered in Article 14, as a legitimate, often optimal outcome the framework should surface, not an edge case.

Quick Recap

A practical decision framework weighs capability gaps, fine-tuning potential, cost at volume, and deployment needs together.
No single factor should decide the question alone — the framework’s value is in the combination.
Organizations increasingly formalize this as a consistent, shared framework across projects.
The decision should be revisited periodically as model capability and task requirements evolve.

Where This Fits in the Series

Article 13 pulled every factor into one practical framework. Article 14 looks at a specific, often optimal outcome of that framework: two tools working together.