OpenCode's Token Budget Problem: When AI Agents Move Too Fast

OpenCode promised to end the approval theater of IDE-based AI coding assistants. No more clicking "accept" on every suggested change. Just tell the AI what you want, and watch it edit files, catch errors through LSP integration, and iterate on builds until they pass.

Then version 0.2.3x arrived, and developers started exhausting their token budgets in minutes.

Terminal AI Without the Approval Theater

The core innovation: bring agentic AI to the terminal. Most AI coding tools require an IDE, where every edit needs human confirmation. OpenCode eliminated IDE dependency with a terminal-based interface that included LSP support—the AI could immediately see TypeScript errors, linting issues, and build failures, then fix them without waiting for approval.

Backend engineers used it to generate entire API routes. Frontend teams watched it fix cascading TypeScript errors across multiple files. The workflow: describe the problem, let the AI work, intervene only when necessary. Some developers reported using it daily alongside Claude Code for full-time coding tasks.

The tool's model-agnostic design—supporting OpenAI, Google, and local models—meant teams weren't locked to a single provider. Combined with open-source code, this offered an alternative to Anthropic-only tools and less mature options.

The 0.2.3x Problem: When Automation Meets Token Economics

After version 0.2.3x, OpenCode started including full project diagnostics in every edit request. What seemed like a feature—giving the AI maximum context—became a resource problem. Token budgets that should have lasted days evaporated in minutes.

The problem was structural. Each autonomous edit triggered a new diagnostic scan across the entire project, feeding thousands of tokens into the context window whether the AI needed them or not. Developers found themselves choosing between the autonomy they wanted and the computational costs they could afford.

CPU Usage, Security, and the Control Trade-off

Token consumption wasn't the only resource issue. Users reported CPU usage hitting 30-50% while idle, sometimes spiking to 90%, slowing LLM responses. The pattern persisted across versions before partial fixes arrived.

Then there were the security implications. OpenCode's default high-privilege behavior—acting like a remote control agent with broad filesystem access—raised questions about safer defaults. The tool's philosophy prioritized autonomy over permission gates, a contrast to competitors like Aider, which takes a more permission-focused approach. Neither model is inherently wrong, but they serve different risk tolerances.

The tension is fundamental: every permission prompt slows development; every autonomous action introduces potential for runaway resource consumption.

33k Stars and the Demand for Terminal Agents

OpenCode hit 33,200 stars with 22.1x growth in Q3 2025. The momentum reveals demand for open-source terminal agents that aren't locked to specific AI providers. With 514 releases and 286 contributors since its April 2025 launch, the project moves fast—sometimes too fast for its resource model to keep up.

The Question Engineering Leads Should Ask

The evaluation isn't whether OpenCode works. It's whether your context matches its trade-offs. Do your token budgets support diagnostic workflows that scan entire projects? Are your teams comfortable with high-autonomy agents that prioritize speed over control? Is the productivity gain worth the computational cost?

OpenCode solved real problems—IDE dependency, manual approval overhead, vendor lock-in. It created new ones around resource management and control. The guardrails question remains: we wanted autonomous coding agents, but we're still learning what happens when they get what they want.