I tried to build my own offline Claude Code

18 Oct 2026 · 6 min read · by Rahul Dhileep Kumar

I built an offline coding-agent experiment with Electron, React, Ollama and Monaco to poke at one problem: how much a local model can remember. Here's the stack, and the context window wall anyone trying this will hit.

Claude Code and Bolt made coding agents look easy. You type a sentence, and a model reads your files, edits them and runs things.

So naturally I wanted my own. Offline. On my machine. No account, no trial, no meter running.

I built a personal coding-agent experiment to explore one specific thing: contextual memory limits. How much can a local model actually keep in its head while it works on your code?

This isn't a results post. It's about the stack, and about the wall the experiment was built to poke at. Because anyone who tries this will hit the same wall.

The stack

Four pieces, all of them free.

Electron for the desktop app. In its own words: "By embedding Chromium and Node.js into its binary, Electron allows you to maintain one JavaScript codebase."
React for the interface.
Monaco for the editor. Its README calls it "the fully featured code editor from VS Code". You get a real editor without building one.
Ollama to run the model locally. Its FAQ is plain about it: "Ollama runs locally. We don't see your prompts or data when you run locally."

Why offline? Partly the obvious reasons: your code stays on your machine, and it works without internet.

Partly me. Early on, we chased every free AI trial going, with dozens of email accounts, because we didn't yet know how to use Claude or Codex. A model that runs on your own laptop never asks for a new email address. If you can get it for free, why spend money on it?

The real constraint: the context window

A model doesn't remember your project. It only sees what's in its context window: the prompt, the files you paste in, the chat so far. Everything outside that window doesn't exist for it.

A coding agent eats context fast. File contents, tool output, error logs, its own previous answers. It all piles up.

Local models start with a small window. The Ollama FAQ says "By default, Ollama uses a context window size of 4096 tokens." Its context length page says the default now depends on your VRAM: 4k under 24 GiB, 32k between 24 and 48 GiB, and 256k at 48 GiB or more. The Modelfile reference still lists num_ctx with "Default: 2048".

So even the docs don't agree with each other. Which is a lesson in itself: check what you're actually running. The context length page suggests running ollama ps and looking at the CONTEXT column.

The same page recommends at least 64,000 tokens for "web search, agents, and coding tools". You raise it with the OLLAMA_CONTEXT_LENGTH environment variable, or per request with num_ctx inside options, per the FAQ.

Why you can't just turn the number up

Because memory isn't free. Ollama's context length page says it directly: a larger context uses more memory.

The reason is the KV cache. While a model generates, it stores keys and values for every token it has seen, so it doesn't recompute them. NVIDIA's guide to LLM inference optimisation gives the formula: batch size × sequence length × 2 × layers × hidden size × bytes per value.

Their worked example is Llama 2 7B in 16-bit precision. At 4,096 tokens, the KV cache alone comes to about 2 GB. That's on top of the model weights.

And it grows linearly. Double the context, roughly double the cache. On a laptop, that's the whole game. Every extra token of memory competes with the model itself for the same RAM.

Bigger isn't the same as better

Say you find the memory. You still have a problem.

The 2023 paper Lost in the Middle, by Nelson F. Liu and colleagues, tested models on finding information in long inputs. Performance was usually best when the relevant bit was at the start or the end. It dropped when the information sat in the middle, even for models built for long contexts.

Their conclusion: "current language models do not robustly make use of information in long input contexts."

For a coding agent, that's uncomfortable. The file you read twenty minutes ago is now somewhere in the middle. It's technically in context. It may as well not be.

How Claude Code deals with it

The tool that inspired the experiment doesn't pretend the problem away. It manages it.

Anthropic's memory docs start with: "Each Claude Code session begins with a fresh context window." Knowledge carries across sessions in two ways: CLAUDE.md files you write, and auto memory that Claude writes itself. Both are loaded at the start of every conversation.

The docs also say to keep each CLAUDE.md under 200 lines. "Longer files consume more context and reduce adherence." Even the memory has a memory budget.

Then there's compaction. The context window docs say Claude Code "compacts automatically as you approach the limit". Running /compact "replaces the conversation with a structured summary". Afterwards it re-reads up to five of the files it read or edited most recently. The project-root CLAUDE.md is re-read from disk and survives.

So the trick isn't a bigger window. It's deciding what deserves to be in the window at all.

What anyone trying this will hit

My opinion, from the research above, for anyone building their own local agent:

The default window is smaller than you think. If the agent seems to forget your file instantly, check the context length before blaming the model.
Memory is the budget. Context costs RAM through the KV cache. On a laptop, you're trading model size against how much it can see.
Order matters. Put instructions and the most important code at the start or the end, not buried in the middle.
Write memory to disk. A short notes file that loads every session beats hoping the model remembers turn three.
Summarise on purpose. Long chats need compacting. Doing it deliberately beats letting the window quietly overflow.

None of this makes a local agent as good as the hosted ones. It does make it clear why they're built the way they are.

FAQ

What is the default context length in Ollama?

It depends on which page you read and how much VRAM you have. The FAQ says 4096 tokens. The context length page says 4k, 32k or 256k depending on VRAM. Run ollama ps to see what you actually got.

Why does a bigger context window need more memory?

The model keeps a KV cache entry for every token in context. That cache grows linearly with context length, so doubling the window roughly doubles its memory.

How does Claude Code remember things between sessions?

Through CLAUDE.md files you write and auto memory notes it writes itself. Both load at the start of each session. Long sessions get compacted into a summary.

Sources

What next

How I learned these tools in the first place: dozens of email accounts and zero shame. And what happens when an AI coding agent does its job and the humans don't: the night I broke production.