Harness, Part 9: Tool-Call Optimization
The finale: a small model handles the tool calls while the big one thinks - a division of labor you can measure.
What this is about
To close the series, an idea that points beyond the finished harness: not every decision needs the big model. Reaching for a tool - which one, with which arguments - is often routine, and routine can be taken over by a small model specialized in function calling: faster, cheaper, local. The big model stays in charge of what it does best - understanding and answering. This division of labor belongs to the extensions from Block II, and it is no blind flight: at the end stands a measurement, not a feeling.
Prerequisite: a local Ollama running a small function-calling model such as function-gemma - the same OpenAI-compatible endpoint as always, just at your place. No Ollama? You still build along: the piece is built as a switchable feature, the measurement then runs with the main model as router - and the local router stays noted as an open item in your docs.
At the end of this part, this works: the same task twice, with and without the router - and the numbers sit side by side in your docs.
How the build works
As before: copy the prompt, hand it to your coding agent, answer its questions. The prompt reads harness-doku.html and requires the complete state from Part 8.
This section belongs to the Pro tier. You get access to full code, deeper explanations, and rabbit-hole material.
See tiers →It works when
The same task ran twice - with and without the router - and your docs show the numbers side by side: duration and tokens per tool turn. With a local function-gemma the difference is measurable; without one, the switch remains as a cleanly built, documented open item. And with that, the series is done: nine parts, nine checkmarks, one harness - terminal, automation, context-frugal. It does exactly what you decided, and not one move more.