I Ran Claude Code On A Laptop Model. 1 Of 2 Tasks Passed

Claude Code on a laptop model passed one of our two real tasks. Most demos of this setup stop at "hello"; we gave a small local model two jobs in a Python package and report what happened, along with the alias and the rule we kept.

The setup is simple. When your plan limit hits in the middle of a task, you either wait for the reset or hand the job to the same Claude Code running against a model on your own machine. On the job that crossed files, the local model reported every test passing while the rename it made had broken an import. One flag, --bare, turned a local run that changed nothing into a clean pass on the same task.

This article covers the alias, the flag that fixes it, the context window trap, the job that crosses files, and the rule for which jobs go local and which wait for your plan.

Claude Code is made of two parts. The harness is the program in your terminal that reads your files, runs your commands and makes the edits. The model decides what to do next, and by default it lives on Anthropic's servers and counts against your plan.

A single setting, the base URL, tells the harness where to send its questions. Ollama is a program that downloads open models and serves them on an address on your own machine. Nothing about Claude Code changes, only the address it talks to, which is why one line in your shell is enough. It is a bit like pointing your app at a local database instead of production.

To set it up, install Ollama with Homebrew, then pull one model that fits in your memory. Ours was qwen3.5:9b, 7.6 GB, on a MacBook Pro M1 Pro with 16 GB. The bigger versions of the same model would not fit at all. Compare the model's size with your own memory before pulling anything, because the whole model has to sit in it next to everything else you have open.

One caveat from Anthropic's own docs: it does not support routing Claude Code to models that are not Claude. If something breaks on this setup you are on your own, and the model you run is far smaller than the one your plan gives you.

An alias is a short name your shell expands into a longer command. Putting the whole switch in one alias means your everyday claude keeps using your plan, because the settings only apply when you call the alias.

Ollama's own guide supplies the settings: the local address, a placeholder token, and an API key. The key deserves attention. Claude Code's docs say a key you set is used instead of your subscription, even when you are logged in, which is why it lives on the alias line only. You open your shell file, paste the alias with the model name at the end, and reload the file.

alias claude-alt='CLAUDE_CODE_ATTRIBUTION_HEADER=0 ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_API_KEY=ollama ANTHROPIC_BASE_URL=http://localhost:11434 claude --bare --model qwen3.5:9b'

This is the final version, with --bare already in it (the next section explains why). CLAUDE_CODE_ATTRIBUTION_HEADER=0 is a setting that guides for local models recommend. We never measured what it does, so treat it as optional.

We started without --bare. The first real task, in a small Python package we wrote for this test, was to add one option to one file and run it. Claude Code started, warned that it did not know this model, and kept working while the clock ran. After 15 minutes it had not changed a single line, so we stopped it, and the option did not exist.

If you try the alias as it is, you will probably see the same thing: a session that keeps working and a file that never changes. The alias points Claude Code at your model, but on a small model that is not enough to get the task done.

Every Claude Code session opens with a long set of instructions: your memory file and your tools. That is fine for Claude and heavy for a small model on a laptop. The --bare flag is Claude Code's minimal mode. It skips hooks, plugins, memory and the project file, so the model gets a short page instead of a handbook.

You add --bare at the end of the alias and put the word ollama in ANTHROPIC_API_KEY, because in minimal mode Claude Code only reads its key from there. With the same request, the same small model and the same short context window, the run read the file, edited it and ran the command. It finished in 93 seconds with one file changed, and the command printed the slug with the prefix in front, exactly as asked: blog-hello-world.

You check it the way you would check a colleague's change: read one small diff and run the command yourself.

The cost is real. Minimal mode also drops your hooks and your project rules, so the local model never sees the conventions you wrote down. If your project depends on a hook to block something dangerous, keep that job on the plan, where your hooks actually run.

The second trap is easy to miss because Ollama picks the size of the model's memory for you. That memory is the context window, how much of the conversation the model can keep in view at once. Ollama's docs say that on a machine like ours the default window is small, 4k tokens below 24 GiB of VRAM, far below the 64,000 they recommend for coding tools. All our first runs used that default, and you would not know until you check.

To fix it, stop Ollama and start it again with the context length set to 64,000 (OLLAMA_CONTEXT_LENGTH=65536), then run ollama ps and read the CONTEXT column. You set this every time you start the server, and ollama ps is the one place that shows it took. The column went from 4096 to 65536, and the model took barely more memory: 7.6 GB before, 7.7 GB after.

Run	Context	--bare	Result	Time
a-4k-nobare (alias without --bare)	4096	no	FAIL: killed at the 15-min cap, zero edits, no answer	900 s
a-4k (alias)	4096	yes	PASS, blog-hello-world	93 s
a-64k (alias)	65536	yes	PASS, blog-hello-world	35 s

The one-file task passed in 35 seconds, much faster than with the small window. The job across files, covered next, also dropped from several minutes to a couple. The small default does not only limit memory, it makes every turn slower, and you would blame the model when the setting is the cause.

Claude Code also prints a warning that it does not know this model, and that it assumes a 200k-token window for auto-compact, much bigger than what Ollama serves. CLAUDE_CODE_MAX_CONTEXT_TOKENS sets the real value. The mismatch did not bite on our short tasks, and we did not test it on a long session. The limit is memory, because a bigger window takes more of it, and on a 16 GB laptop this is about as far as you can push it.

With the local model answering quickly, the temptation is to hand it real work. So we gave it a job that crosses files: rename smart_truncate to truncate_words everywhere in the package, and keep smart_truncate as an alias in slugkit/truncate.py. An alias in code is the old name kept as a pointer to the new function, so any code still using the old name keeps running.

The local model worked for a couple of minutes, edited the files, ran the tests, and every test passed. Then it reported the job done.

Run	Context	--bare	Result	Time
b-plan (plan, Claude)	n/a	no	PASS: 12 tests OK, old and new imports both work, tests renamed	38 s
b-4k (alias)	4096	yes	BROKE: "All 12 unit tests pass", but from slugkit import truncate_words gives ImportError; tests still call smart_truncate via import truncate_words as smart_truncate	464 s
b-64k (alias)	65536	yes	BROKE: 12 tests OK, reported done, but the alias went to __init__.py, so from slugkit.truncate import smart_truncate gives ImportError (the instruction said truncate.py)	142 s

When we imported the old name the way old code would, Python refused it. The model had put the alias in the package's front file instead of the module we asked for, so the old import path was gone. With the small window the same task broke differently: the new name was never exported, and the tests still called the old one.

How can every test be green while the code is broken? The tests only check what they check, and nobody had written a test for the old import. A green run from the local model tells you nothing the tests cover broke, and nothing about what they do not cover.

On the plan, Claude did the same job in 38 seconds, renamed the tests too, and both the old and the new imports worked. To be fair, the plan's work deserves a check as well, but here the local model got the cross-file job wrong both times. After every local run, read the diff yourself and import the old names by hand before trusting a green test run. That check takes less time than the run, and it stops a broken import from reaching your main branch.

When your limit hits, you have a few seconds to decide whether a job goes local or waits. A switch rule is a few lines you keep next to the alias, so the decision is made before you are in a hurry. Open your shell file and write three comments above the alias:

# claude-alt: one-file jobs I can check in a glance
# plan: anything across files, or that I can't check by reading the diff
# always: read the diff before committing

The local model gets jobs in one file that you can check at a glance, such as adding an option, explaining a function or testing one function. Anything that crosses files, or that you cannot check by reading the diff, waits for your plan. Whichever model wrote the code, you read the diff before you commit.

The rule comes straight from our run: the one-file task passed both times, and the rename across files broke both times. The pattern makes sense once you have seen it fail, because a job in one file keeps everything the model needs in front of it.

This setup also has limits that Ollama lists in its own docs. It has no prompt caching, where the server keeps the start of the conversation ready, so on a long session every turn re-reads everything and slows you down. It cannot force the model to use a particular tool. And Anthropic does not support Claude Code on models that are not Claude. Our rule comes from two tasks on one small package, so treat it as a starting point and widen it with your own runs.

When your plan limit hits mid-task, one alias runs the same Claude Code on a model on your laptop. On our test it passed the one-file task and broke the cross-file one. The broken run is the dangerous one, because it reported every test green while an import was failing.

Use it when you are blocked, the job fits in one file, and you can read the whole diff before you commit. Do not use it for anything that crosses files, for long sessions, or for work you will not review, because that is where it fails quietly.

On the plan, each task took under 40 seconds (21 s and 38 s), so when your reset is close, waiting is often the faster choice. The alias is not a replacement for your plan. It keeps you going on small jobs while you wait for it to come back, and if you set it up today it is ready the next time your limit hits.

The rule to remember: the local model is for jobs you can check at a glance.