Different Tools for Different Jobs

You do not use a screwdriver to tighten a nut. You do not use a spanner to cut wood. Anyone who has worked with their hands knows that a toolbox is not a collection of the most expensive tools available. It is a collection of the right ones, and the skill is reaching for the one the job needs.

Artificial intelligence is arriving at the same position. There are now many models with different strengths, costs, limitations and conditions of use. Some are strong at mathematics, some at code, some at writing or translation. Some are fast and cheap, others slow and better at hard reasoning. Some understand images or speech. Some run on your own machine; others only on someone else’s. Some you may use however you like; some come with restrictions that rule out the work you had in mind.

So the useful question is not “which AI is best?” It is: which available and permitted AI is the right tool for this particular job? Chapter 18 was about making your working environment your own. This chapter is about choosing the intelligence that works inside it — and, when you build applications, choosing the intelligence that works inside them.

Does the job need a model at all?

The first question comes before any comparison of models, and it is the one most often skipped.

A skilled worker does not pick up the most sophisticated tool because it is there. A simple screwdriver is exactly right for a simple screw. In the same way, a great deal of work that people now hand to a large language model does not need one. Exact arithmetic, checking that a date is valid, sorting a list, converting a file from one format to another, looking something up in a table: an ordinary program does these perfectly, instantly and identically every time, and a generative model does them slowly, expensively and occasionally wrongly.

Before asking which model should do a task, ask whether the task needs a model at all. You do not need to be able to write that ordinary program yourself — the machine will write it for you, which is rather the point of this book. You only need to notice when the job is deterministic and say so.

Not all intelligence is the same

When a job does need intelligence, it helps to have a vocabulary for what kind. These categories are illustrative, not a permanent taxonomy, and they overlap.

General conversational models discuss, explain, draft and respond to broad requests. Deliberative or reasoning configurations spend more effort on hard, multi-step problems — planning, mathematics, difficult technical questions — usually at the price of time and money, and without any guarantee that thinking longer produces a better answer. Coding models understand repositories, implement and debug; as Chapter 07 argued, how well they do depends heavily on the agent and tools around them. Research and analysis systems interpret documents and synthesise sources; what a system retrieves from current sources is not the same as what its model happens to know. Then there are specialised capabilities — speech recognition, speech generation, image understanding and generation, classification, ranking, and the embedding models that let software find similar text — each designed for a narrower job and often far better and cheaper at it than a general model. And there are local or constrained models, which run on hardware you control, chosen for privacy, offline use, predictability or cost, and limited by that hardware.

A complete application may use several of these, not one general model for everything. The categories are not a ranking. They are the names of different drawers in the toolbox.

A model is not where you use it

One source of confusion causes more bad decisions than any other: treating a model’s name as if it told you everything. It tells you surprisingly little. Five different things are involved whenever you use AI, and each can change the answer.

The model is the underlying capability, at a particular version. The provider is the service or infrastructure making it available, and the same open model may be offered by several providers with different prices, speeds and privacy practices. The tool or agent is the application you actually work in, which coordinates one or more models with files, commands and other capabilities; a coding agent is not the model it runs. The deployment is where the model actually executes and where your data is processed. And the entitlement is whether you are allowed to invoke it, under which terms, for which purposes. A model you reach through a chat subscription may also be available through an API with entirely different pricing, limits and data terms; a subscription frequently does not include that API access at all.

So “I’ll use model X” is never a complete decision. Through which provider? In which tool? Running where? Under which terms? Two people using the same model name can be making very different choices.

Permission before performance

This is the part of choosing a tool that has nothing to do with how good it is.

A model can be technically excellent and still wrong for the job, or not allowed for it at all. Licences may restrict commercial use. Provider terms may limit automated use, resale or what happens to your data. Your employer or your customer may have policies about which services can see their information. Confidentiality agreements, data residency requirements, privacy and security rules, and national or regional laws — including export controls and sanctions — may all apply. Some access is offered only for research, promotion or in exchange for your data being used to improve the model, which may be fine for experiments and unacceptable for private or commercial work.

Where a model comes from deserves the same care. A model’s country of origin is not, by itself, a universal prohibition. One company may decide that a particular foreign-hosted service cannot see its data, because of its own security policy, its customers’ requirements or the law that applies to it; another company may reasonably decide differently, or may run the same open model on infrastructure it controls. What matters is the actual arrangement: which model, which provider, where it runs, what the contract says, and what rules apply to you. That is something to check, not assume, and where the stakes are real it is a question for whoever is responsible for legal or security decisions in your situation, not for this book.

Two more distinctions save people from expensive surprises. A model appearing in a catalogue is not proof that you can invoke it through the interface you are using. And being able to invoke it is not proof that your intended use is authorised. Eligibility and permission come before performance and price. Rule out what you cannot or should not use first; compare only what remains.

My own Worker project shows what that looks like in practice. Its writing experiments include a privacy gate: unpublished manuscript excerpts may not be sent to free models whose terms permit training on the data without explicit consent naming the model and the excerpt, and results on private material must be reported separately from results on public or synthetic material. That rule is not about which model writes best. It is about which models may see the work at all.

What it costs to get it right

Budgets differ. Some readers will happily pay for a powerful service; others want to work with free, local or inexpensive models. Both are legitimate, and the choice is not as simple as it looks.

I spend a good deal of effort preserving my limited access to expensive coding models by sending routine work to cheaper ones. Worker’s capability experiment states that goal plainly: qualify free, local and inexpensive models for work that does not need the premium services, so that those services are kept for escalation when the evidence says it is needed. In my experience, high-end paid models have substantial advantages on genuinely difficult tasks. I treat that as experience to keep testing, not as a law: free models can be excellent at particular jobs, premium models can do badly at particular jobs, and the gap moves with every release.

Chapter 03 gave the measure that matters: not the price of the first call but the total cost of an accepted result, including failures, retries, waiting and the work of correcting mistakes. A cheap model that needs four attempts and your attention each time may cost more than an expensive one that gets it right once. An expensive reasoning model that spends a great deal of effort on a trivial task wastes money however good its answer. And the price on a list may not be what you actually pay, especially under a subscription; Worker distinguishes an estimated value derived from a dated price schedule from billed cost, which stays unknown until a real invoice says otherwise. Keep those apart and you will make fewer confident mistakes about what something costs.

Open, closed, local, remote

A closed model is usually available only through its provider. An open-weight model can be downloaded and run on other infrastructure — though “open weights” does not necessarily mean the training data, the training code or an unrestricted licence came with it. A local model runs on hardware you or your organisation control; a remote one runs on someone else’s.

Local execution can help with privacy, offline work and control, but it is not automatically secure; that still depends on the software, permissions and configuration around it. Remote execution gives access to much larger models and saves you running infrastructure, at the cost of sending your data somewhere else under someone else’s terms. Neither is automatically right.

You do not need to buy hardware or learn to serve models to benefit from this. Browsing a model hub such as Hugging Face, where each model’s card is meant to describe its intended uses, limitations and licence, is enough to start seeing the range of what exists and what conditions come with it. If you later want a model on your own machine, there are runners that make that a few commands, and the machine can walk you through them.

Four different achievements

The most useful lesson my Worker project taught me is that four things people treat as one are actually separate achievements, and each can fail on its own.

A model being listed in a catalogue is the first. Being accessible — actually invokable by you, through your route, today — is the second, and it fails more often than you would expect. Worker’s records include a free model that appeared in the catalogue, was tried, and failed with a quota error before producing any evidence about its quality at all; they also note that some free offers work through one tool but are refused when called directly. Being qualified for a particular task — having actually passed a test of that task — is the third. Being good value for that task — passing at an acceptable total cost compared with the alternatives that also passed — is the fourth.

Worker’s dashboard begins with the question “What model should I use?” and answers it narrowly. Among the models with task-specific evidence, which passed the task’s evaluator at the lowest estimated cost? For tasks with no evidence, it says “No verified model yet” rather than recommending something on the strength of its catalogue entry, its price or its reputation. Its current recommendations come from one run per model and task, and it says so: that is a diagnostic, not a ranking. A larger experiment across coding, fiction editing, research reasoning and formal mathematics is prepared and waiting for my approval; nothing from it has been run, and nothing is claimed from it.

I find that honesty more useful than any leaderboard. A good model selector must be allowed to say it does not have enough evidence yet. So must you.

Intelligence inside your application

Everything so far applies to choosing the machine you work with. It matters even more when you build software that uses AI itself, because then you are deciding where intelligence belongs inside the thing you are making.

Imagine an application that helps someone investigate a scientific question. It might retrieve documents, extract metadata such as authors and dates, compare papers for relevance, explain an unfamiliar concept, propose a hypothesis, check a result and write up a report. Those are seven different jobs. Retrieval and metadata extraction may need no generative model at all, or only a small, cheap specialist. Comparing papers may suit an embedding model. Explaining a concept suits a general model. Proposing a hypothesis may justify a strong reasoning model. Checking a result may need a tool that actually runs the calculation rather than more reasoning about it. And any step that touches private material may need a provider chosen for its data terms rather than its benchmark scores.

Thinking of these as distinct intelligence jobs within the application is the shift. The lazy design sends everything to the largest model available. It works, often, and it is slow, expensive and harder to trust. The considered design gives each job the intelligence it needs.

You do not have to work this out alone. A capable model can help you list the jobs, propose candidates, investigate their conditions and build the result. Treat its proposals as hypotheses to test, not decisions. And do not design the application so that an expensive planning model is consulted every time a cheap operation happens; that quietly spends the savings the design was meant to make.

A rule of thumb for choosing

When a choice matters, a short sequence keeps it honest: identify the job, check permission, compare candidates, test the result, consider the cost, then choose — or reconsider. It is a way of thinking, not a ceremony for every request.

Permission comes before price: anything you cannot or should not use is out before you look at what it costs. The remaining candidates are compared on representative work, judged by what they actually produce. The choice balances adequate quality, reliability, speed and cost, and a model that does the job adequately is often a better choice than a more capable, much more expensive one. If a model fails, escalating to a stronger one can be right when the consequences justify the cost — but escalation should be a decision, not a reflex. In particular, an application should never send sensitive material to a different provider just because the first model failed. Permission does not lapse under pressure.

Try Machine Coding — Three Jobs, Three Tools

This needs no application, just the models you already have access to. It has not been run for this book; it is for you to run.

Choose three jobs of different kinds. For example: extract the key facts from a short document into a fixed structure; find and fix a small bug in a short piece of code; and think through a hard design or research question you actually care about. For each job, pick two or three models you are permitted to use, including at least one cheaper or free one. Give each the same material and the same instructions, and decide before you start what counts as a good result.

I want to compare models on three tasks. For each, help me write one clear instruction and a way of judging the result that doesn’t depend on which model produced it. Then help me record, for every attempt, the model and version, the date, whether it met the standard, roughly what it cost, and anything surprising.

Run them. Look at the results before you look at which model produced them. You will very likely find that the best choice differs between the three jobs, and that the most expensive model did not win all three. You will also find that one run proves little: a model that succeeded once has shown it can do the task, not that it reliably will. That difference — between a useful demonstration and a robust claim — is the habit this exercise is for.

Try Machine Coding — My AI Toolbox

If you want to keep what you learn, build a small personal catalogue: a deliberately simpler cousin of Worker. It is proposed here, not built; nothing below describes a working version.

Build the catalogue.

I want a small application called My AI Toolbox, so I can see which AI models I can use, what they’re good at, where they run and what they cost. Build a simple browser application in my GitHub repository with the data in a file I can edit. Make it easy to add and update models.

Record what matters — and admit what you don’t know.

Add fields for model name and version, provider, the tasks it’s meant for, reasoning options, whether it runs locally or remotely, licence, access restrictions, data and privacy terms, and cost. Wherever we don’t know something, show “unknown” — never guess. A model being listed must not mean it’s marked as usable.

Choose by job.

Let me pick a job — coding, summarising, research, maths, speech recognition — and show me candidates that might suit it, and which capabilities matter for that job. Don’t rank anything without evidence.

Record real tests.

Help me pick a few models I’m genuinely allowed to use and design a small, repeatable test for one of my real tasks. Store the task, model version, date, result, cost information and what we learned. Keep tested and untested models visibly separate.

Recommend — or refuse to.

Based only on results we’ve actually observed, suggest which model I should use for this task, weighing quality, price, speed, restrictions and availability. If the evidence isn’t good enough, say so and tell me what to test next.

Make it yours.

Ask me what work I do, which models I can access, whose rules I have to follow and what I’m willing to spend. Shape the toolbox around my projects rather than a generic leaderboard.

It has succeeded when it can show you meaningful differences between the tools you have, and holds a small amount of real evidence about which ones suit which of your jobs.

The freedom to choose

The particular models in anyone’s toolbox will change quickly. Names change, prices change, free tiers appear and vanish, licences are revised, new kinds of model arrive. That is why I do not want you to memorise a catalogue. I want you to understand what kinds of tools exist, what separates them, how to find out whether you may use one, and how to test whether it does your job — and then to let the machine help you make those choices better over time.

Some tools are expensive and some cheap. Some run on your desk and some far away. Some are excellent at mathematics or code; some do routine work perfectly well without the expense of anything grander. Some you will not have access to. Some you will not be permitted to use for the work you want to do. And sometimes the right tool is not an AI model at all.

The future is not one AI that does everything. It is the freedom to choose the intelligence your work actually needs.

What comes next

Choosing the right intelligence for each job raises the obvious next question: what happens when the jobs are done by different machines that have to work together — a researcher, a builder and an independent reviewer, each the right tool for its part? That is the subject of the next chapter, When Machines Work Together.