How to Reduce Token Usage in OpenCode

The pitch for OpenCode is provider flexibility — swap in whichever model fits the task instead of being stuck with one vendor’s pricing and context window. Which is great, except flexibility cuts both ways: pick a model with a huge context window and you can accidentally treat it like a bottomless bucket, dumping in full files and long sessions because “there’s room.” There’s room right up until there isn’t, and by then you’re paying for all of it.

1. Match the model to the task, not the other way around

Since OpenCode lets you configure different providers, use that. A quick lookup or boilerplate edit doesn’t need the same model (or the same context budget) as a multi-file refactor. Reserve the expensive, large-context model for tasks that genuinely need to reason across a lot of code at once — OpenCode’s config docs cover how provider and model selection actually gets wired up per project.

2. Keep your instructions file scoped

If you’re using an AGENTS.md-style file (or whatever your setup loads as persistent project context), the same rule applies as everywhere else: it loads on every session, so keep it to build commands, conventions, and things the agent’s gotten wrong before — not a full project wiki.

# AGENTS.md
- Package manager: pnpm, not npm.
- Run `pnpm typecheck` before any change is considered done.
- API routes live in src/routes; don't touch src/legacy-routes.

3. Audit connected MCP tools per project

Every tool a connected MCP server exposes registers its schema into context before you’ve used it once. If a project only needs your database and filesystem tools, don’t leave three other servers connected out of habit — that’s context spent on capability you’re not using.

4. Start fresh sessions for unrelated work

A session that’s wandered from a bug fix to a feature request to a documentation question is carrying all three histories into every new message. Starting clean per task keeps each session’s context focused on what it’s actually for — OpenCode’s CLI docs cover session management if you’re scripting this rather than doing it by hand.

5. Read targeted, not broad

Whatever agent you’re running, asking it to “check the payments module” instead of “check src/payments/charge.ts lines 40–90” invites it to read more than it needs. File contents are usually the biggest context line item — bigger than the conversation itself.

6. Don’t hand it a screenshot when you mean a specific element

If you’re using OpenCode for frontend work, describing a UI tweak with a screenshot means the model has to interpret pixels and guess at the selector before it can act — often needing a follow-up to land the right one. Handing it the actual selector, computed styles, and DOM context as text skips that step.

That’s what UICuts is built for — point at an element in the browser, and it copies out the selector and styles as structured text, ready to paste into whatever agent you’re driving instead of a screenshot.

Key lessons learned

• Provider flexibility is a token-cost lever, not just a pricing one — use the cheap model when the task doesn’t need the expensive one.
• Instructions files and MCP connections both load whether you use them that session or not. Scope them per project.
• The biggest single line item is usually what you read, not what you typed.

Related reading

If you’re moving between agents rather than staying in one, the same principles show up with different names: Claude Code has CLAUDE.md, Cursor has Rules and @file targeting, Windsurf has Memories vs. Rules, and OpenClaw pays the same tax for connected tools and integrations. If you’re on the raw API instead of a CLI agent, see the prompt-engineering-level tactics for the API-specific version of this.

Install UICuts free if UI feedback ever comes up in your OpenCode workflow.