The Silent Killer: How Misconfigured Context Windows Killed My AI Coding Agent
There's a particular flavor of frustration that comes from watching an intelligent system fail for dumb reasons. I experienced this recently while experimenting with local AI coding agents—a trend that's gaining traction as open-weight models become more capable and privacy-conscious development grows in importance.
The experiment was straightforward: could a coding agent running entirely on local hardware build a functional game? Not a trivial demo, but something with real state management, rendering logic, input handling, and a playable UI. The answer, after considerable head-scratching, was yes—but getting there exposed a class of problems that the AI tooling ecosystem isn't handling gracefully.
The Setup That Should Have Worked
The stack consisted of three components that represent the cutting edge of local AI development: a provider-agnostic coding agent CLI, Ollama serving an OpenAI-compatible API from localhost, and Qwen3.8 27B running on the local machine. For context, this isn't some underpowered setup—the 27B model at 17GB fits comfortably in 32GB of unified memory and supports tool calling with respectable reasoning capabilities.
Initial results were promising. Within fifteen minutes, the agent had produced a complete HTML structure and nearly 200 lines of NES-flavored CSS with beveled cabinet styling and a proper color palette. More impressively, the agent caught its own mistake mid-stream: it wrote a file, re-read it, noticed a mismatch between what it intended and what landed on disk, and repaired it without prompting. That's genuine agentic behavior, and it suggested the model was up to the task.
Then the agent attempted to write the game logic file, and everything stopped.
The Death Spiral
What followed was a sequence that anyone who's wrestled with AI tooling will recognize. Thirteen consecutive attempts to write the game engine file, each one terminated mid-generation. The stream simply died, producing no error, no explanation, and no usable output.
The most maddening aspect wasn't the failure itself—it was watching the agent's reasoning process. Because each attempt started fresh, the model would re-derive the same design decisions from scratch, landing on different scoring tables and implementation approaches each time. Three retries meant three different answers to the same architectural question. The agent was doing an hour of thinking and shipping none of it.
The obvious culprit seemed to be memory pressure. Closing browser tabs freed up several gigabytes of RAM and things improved marginally, which seemed to confirm the diagnosis. But this was the wrong lesson to take away.
What the Logs Actually Revealed
Going back through the server logs told a different story. There wasn't a single out-of-memory error in any of them. Free system memory sat comfortably between 21 and 27 gigabytes throughout, against a 17-gigabyte model footprint. Memory was never the problem.
The real issue was a configuration mismatch that produced no visible error. The agent's config advertised a 32,768-token context window. But the Ollama server had been restarted with an 8,192-token ceiling, and this discrepancy went undetected. The agent would happily plan an 800-line file to write in one shot, because as far as it knew, it had 32k of headroom. When the actual generation hit the 8k wall mid-tool-call, the connection was severed with no error message the agent could reason about.
There was a secondary complication lurking in the startup logs: Ollama had launched with context-shifting enabled, which would have allowed the window to slide when it ran out of room, sacrificing older tokens to make room for new ones. But the model's architecture didn't support this feature, so it was silently disabled. What should have been a soft limit became a hard wall.
The DevOps Discipline AI Development Demands
This experience crystallizes something important about local AI development that the enthusiasm around open-weight models tends to obscure. When you're running models on your own hardware, you're not just writing code—you're operating infrastructure. And infrastructure requires the same diagnostic discipline, configuration management, and attention to operational parameters that production systems demand.
Context windows are not abstract model properties to set and forget. They're operational parameters that interact with your tool chain in non-obvious ways. When an agent's configured context doesn't match the server's actual ceiling, you don't get a warning—you get silent failures that look like model incompetence when they're actually operational misconfiguration.
The practical takeaway for developers exploring local AI coding agents is straightforward: validate your environment as thoroughly as you'd validate a production deployment. Check that your agent's configuration matches your runtime parameters. Read the server logs, not just the agent output. Understand what features your model architecture actually supports versus what the tooling attempts to enable.
The models are getting better. The tooling is maturing. But the gap between "works in demos" and "works reliably in daily use" still requires human judgment to bridge—and that judgment looks a lot like traditional DevOps discipline applied to a new class of infrastructure.
The Tetris build eventually succeeded. It took four and a half hours across two days, produced clean code across three files, and functions correctly. But the lessons came not from the success, but from understanding why the failures happened—and recognizing that sometimes the most expensive problems have nothing to do with intelligence.