The cat from the laptop

In July I showed you the ugly cat: a tomcat drawn blind in code, on a budget day, with a small model and no correction loop. Since then I've been carrying a term around with me — "ugly-cat AI", for models that quietly get worse under rationing. Now I wanted to know how drawing goes without a meter. The same brief, but not to a cloud model: to a local model on my own laptop. "Please create a single HTML page with a JavaScript-animated cat that walks across the page from left to right and from right to left."

This is what the first attempt produced:

Version 1, untouched: the local model put the cat on its back.

Legs and tail point at the sky, and the animal "walks" on its back. Still: clouds, grass, flowers, a tail that swishes. For a first go without any help, that was respectable. And no meter was running.

The laptop

The model drawing here sits on my hard drive as a 14-gigabyte file. A small program loads it into graphics memory and does the arithmetic. A language model consists of parameters — billions of numbers that emerged during training. Some makers publish those numbers; "open weights" is the term, and anyone can download and run them. In this case it's Qwen from Alibaba, version 3.8 with 27 billion parameters, squeezed down to around 3 bits per number so it fits into graphics memory. The squeezing is called quantisation and costs a little precision, like a more heavily compressed JPEG.

The laptop is no data centre, but it's no office machine either: an RTX 4090 in its laptop form with 16 gigabytes of graphics memory, plus 64 gigabytes of RAM. The model runs on it entirely. No account, no allowance, no data leaving the house. The tooling it needs is free: Ollama downloads and serves the model, OpenCode turns it into an agent that reads and writes files and runs commands. So the cat above wasn't copied out of a chat window. The model created it as a file itself, the way a colleague at the next desk would.

The foreman from the cloud

I didn't set this up alone. Claude, the cloud AI I normally work with, took inventory of the hardware, compared models and wrote the configuration — and then did what I had hoped it would: it watched the local model work. OpenCode stores every session in a database, and the cloud AI read every tool call and every file the local model had written out of it, and told me what had gone wrong.

That was plenty. The first model, a smaller and very fast Qwen variant, rewrote the entire file eleven times in half an hour, without reading it back once and without a single test. Four versions had syntax errors, two broke off mid-code. It overwrote the two usable versions along the way, and when I complained, it made up explanations: the browser cache, "typos from copy-paste". The cloud AI recovered the lost versions from the session database and wrote house rules for the local model into a file OpenCode reads at start-up (AGENTS.md in the working folder): new version, new name; read first, then change one thing; check after every change. Plus a small check script (check.js) that runs the cat without a browser and reports errors.

The plumbing needed care, too. When the speed collapsed, the cloud AI found an orphaned process in the logs — a leftover from a restart it had triggered itself. It was holding two and a half gigabytes of graphics memory, and part of the model was quietly running from RAM. A paid cloud AI tidying the workbench for a free model: that's the part of the story I didn't want to leave out.

From version 1 to version 13

It wasn't a straight road. Version 2 stood upright, but hovered above the ground and walked backwards as soon as it turned around. Then came the loop: the fast model couldn't find the ground line and made 45 edits to the same spot, resetting to the start twelve times, until I pulled the plug. Only the switch to the larger model brought calm: feet on the ground, one edit. Turning around, one edit. Ears and the humps on its back, flowers in front of the grass, a smoother hill — one round each, checked each time, reported each time.

Model	Speed	Behaviour
Qwen 3.6, 35 billion parameters, 3 billion active	60 tokens/s	fast, but rewrites everything and goes in circles
Qwen 3.8, 27 billion parameters, 4-bit	5 tokens/s	one targeted edit per problem, too slow for real work
Qwen 3.8, 27 billion parameters, 3-bit	25 tokens/s	the same behaviour at a usable pace

Then came the freestyle. A day-night cycle with a rising sun, a moon and stars: one round, eight edits, checked. At night the cat should walk more slowly and take a rest: the next round. That it stopped dead from full speed cost two more: first a simple ramp, then, because that still felt abrupt to me, an S-curve profile for starting and braking. In between, the context window — the model's working memory — filled up several times; OpenCode summarised the state and let it carry on. On this site, that's a home game.

Version 13, untouched: day and night in two minutes; at night the cat slows down, takes breaks and brakes for them.

No beauty yet. But it walks on its feet, turns around when it reaches the edge, and every version in between sits in the folder as its own file.

Borrowed eyes

On the screenshots, the cloud AI was wrong at first: it believed the local model had never been shown one. The logs say otherwise. The fast model had received them from the start, and they didn't help it. The larger model didn't get them at all to begin with: the toolchain took it for a text-only model and attached an error note to every image, "does not support image input". Only once Claude certified in the configuration that the model accepts images did they get through. Since then, July's loop is closed locally too: I take a screenshot, the model sees its work and corrects it. The smoother hill was the first round with a picture.

What a laptop can do today

Two months ago the cat had three dials working against it: model class, depth of thought, number of attempts. On the laptop the third dial disappears: attempts only cost time now. The first is capped: the model won't get bigger than the graphics memory, whatever I pay. And the second wears a new face here: depth of thought only helps if the model doesn't lose track while thinking.

Because in the end, the ugly-cat AI wasn't the model. It was the missing workshop. A model that never reads back what it wrote, never checks, and overwrites working versions will produce ugly cats no matter how clever it is. With house rules and a check script, the same model stopped destroying working versions and delivered its first clean round. For the rest it took the larger model: one that changes the right thing per round. What was missing was half intelligence. The other half was context.

On the laptop, context has a second, narrower meaning too: the context window, the model's working memory. The model could hold 256,000 tokens, but every token in the window takes up graphics memory, and that is scarce. I capped it at 32,000 at first; it's 48,000 now, still a fraction of what the big cloud models carry. For the cat, that's enough: one file, one conversation. For complex work — many files, long sessions — it fills up fast. OpenCode then summarises and carries on, as it did during the day-night cycle. But whatever the summary leaves out never happened, as far as the model is concerned.

What's still missing? I take the screenshot, not the model; the loop closes by hand, not by itself. And what Claude did in this story — reading logs, finding causes, writing rules — I never asked of any local model. Whether they could have done it, I don't know. Probably with more guidance, and a context window big enough for all those logs.

But a model that follows rules, reads a file before changing it, checks its own work and improves one thing per round: that runs on a laptop today, with no subscription and no meter.

And it needn't stay an either-or. Via the Model Context Protocol, the USB port for AI tools, the local model can be plugged into the cloud AI as a tool: the cloud AI plans and checks, the local model does the legwork, with no meter, and the bulk of the data stays on the laptop. The foreman would get an apprentice. How the protocol works is in MCP explained. That's the next experiment.