The model eats the tool · Philipp Schmid

The premise

The bitter lesson, applied to harnesses

He starts from Richard Sutton's essay.

“General methods that leverage computations are ultimately the most effective by a large margin”00:00:13

For agents, that means the more compute goes into the models, the less harness and the less code you need around them. The way models learn agentic work explains why: in post-training, the model attempts a task with tools and a verifier scores the result.

“No one is telling the model which tools to use, and basically it only receives that reward feedback.”00:01:58

So whatever path to the reward is cheapest, the model learns. A harness built around a particular set of tools is a guess about what the model needs, and the guess goes stale.

Evidence: transcript 00:00:13, 00:01:58

The method

Learning from the last harness

Every six months he builds a new harness and asks the same question.

“how much of the harness do I really need to achieve the Same task, and what is overhead to the model”00:03:20

The history is a sequence of things the harness used to carry. Two years ago: workflows with fixed steps, planners and retrieval. Then agents with many fine-grained tools. Then coding agents in 2025 with ten to twenty tools for editing files, planning and to-do lists, plus long system prompts full of rules about what to do and what not to do. System prompts shrank too: much of what had to be sent with every request is now part of the model.

From the notes: “he's referring to it as ‘the model eats the tool’”. That's the spine of the talk: each rebuild looks back at the last harness, finds the tools and rules the model has absorbed, and deletes them. In the recording his phrase comes out garbled (“Will keep eating the honors”, 00:13:33, likely “the harness”), and his Bitter Lesson slide backs that reading: its caption, partly hidden by him in the photo, ends “…ats the harness”.

Evidence: transcript 00:03:20, 00:06:11, 00:13:33

The rebuild

One tool: bash

His latest experiment gives the agent a single tool, bash, running in a clean subshell. Everything else the old harness provided, the model now does through it. Dedicated file tools become shell commands. Planning and memory become files the model writes and reads. Subagents disappear:

“If the agent itself is a CLI, it can call itself using bash.”00:04:31

The same repository change takes about ten turns with dedicated read and edit tools, and two with one bash script, at about a tenth of the tokens.

From the notes: “having it automatically go to the background after some number of seconds, just return the file descriptor, and it is smart enough to deal with it”. That's one of the few things the harness still brings in: his tool definition moves a command still running after 120 seconds to the background and returns its log path. The model handles the rest.

Evidence: transcript 00:02:31, 00:04:31

The other half

What the harness still brings in

Deleting tools isn't the whole method; adding back what's missing is the other half. Bash can't show the model an image: cat-ing a screenshot returns binary that fills the context, and the model can't see it. So his evaluation adds one tool back, a view-media tool that returns images in a form the model can see.

The harness that's left is small and specific: a shell, a way to see images, and a way to background long work. Each piece exists because the model can't do it through bash, not because a previous harness had it.

The reading: this is the part to copy. Not “one tool” as a rule, but a review on every model release: what did the last harness provide that the model now does itself (delete it), and what can the model still not do through a computer (provide exactly that).

Evidence: transcript 00:07:44

The demo

The model writes the tool

The demos show why it works better as models improve. With Gemini 3.5 Flash, bash-only and the default tools made the same number of calls: it used bash one command at a time. The newer Gemini 4 model does something different.

“it uses Python to write an inline script.”00:11:39

It searches for what to change and writes one script that makes all the edits in one go. The better model chains 2.2 to 3.7 commands per bash call against 1.3 to 1.8 for Flash, and uses up to three times fewer tokens for the same task.

From the notes: “its using bash but the bash is a python ‘one-liner’ so I'm not sure if that is valid”. In his framing it's the point, not a loophole. The bash tool gives the model a computer; the model writes whatever code the task needs and runs it. The edit tool didn't vanish: the model wrote its own, for this task, inline. That is the model eating the tool.

Evidence: transcript 00:09:37, 00:11:39

The measure

Same score, half the cost

The reason this is easy to miss: on his own set of about 350 coding, knowledge-work and terminal tasks, four harnesses scored roughly the same. Only the cost differed. Bash-only tasks used fewer tokens, hit the cache more often, and were almost twice as cheap.

“so if your harness Is more complex to use. The model will work around it.”00:13:33

It finds a way around an over-built harness, at the price of more turns and more tokens, and accuracy alone won't show it. He expects 2027 to be about how many tokens a task needs.

From the notes: “he thinks that the future will be fewer tokens, in terms of numbers not just token/sec”. The counterpoint to Natalie Serrino's talk this morning (When the bottleneck moves): she makes tokens faster, he makes tasks need fewer of them. Both shorten the wait.

Evidence: transcript 00:07:44, 00:13:33

What comes next

He'll rerun the experiment in six months, and he expects the next turn to be code: agents writing TypeScript or Python directly instead of bash, and MCP coming back, now that MCP servers can return structured output the model can script against. A typed code layer is also easier to secure than bash, where the commands are hard to inspect.

From the notes: “the code running tool is like the old cloudflare idea”, likely Cloudflare's earlier “Code Mode”, where the model writes code against tool APIs instead of calling them one by one. Unverified, but it's the same direction.

Evidence: transcript 00:14:23, 00:15:25

Also launched

A decision model

At the top of the talk he announced the Gemini Decisions API, launched about an hour earlier with a new Gemini Decision One model: multimodal input, up to 1,000 questions in one request, 150 to 250 milliseconds end to end, 10 cents per million tokens.

From the notes: “there's a decision model also”, and the follow-up to write about how to use decision models overall. That's the fourth today, after Cloudflare's Clef, TypeSafe's Jev and Workday's use of it. The two halves of his talk fit together: the harness shrinks to a computer, and the small yes/no and pick-one calls move to decision models.

Evidence: transcript 00:01:29