Using OpenCode for 6 Months: What Actually Saves Time

I have been using OpenCode for about six months now. I started out just treating it like a chat box. It took a while to figure out what actually works.

The default mode is Build. You say something, and it starts changing code. The problem is, most of the time I do not know exactly what I want yet.

So I started using Plan mode first. It is read-only. You describe what you need, it gives you a plan. You read it, think about it, then switch to Build and let it do the work.

That saves a ton of back-and-forth. There is far less of the wait, that is not what I meant, undo, let me rephrase cycle.

Now I do this even for small changes. A quick mental plan first. Complex stuff goes straight to Plan mode. It takes an extra minute and saves ten.

Run /init Once, and It Pays Off Every Time

When I clone a new project, the first thing I do is run /init. OpenCode scans the whole codebase and generates AGENTS.md.

Think of it as a README for the AI. What language, what framework, how the folders are structured, code style rules.

Later when I ask it to change something, it already knows the project uses Vue. It does not guess. This matters a lot when the project mixes multiple languages or has weird folder structures.

It is a one-time setup. Takes maybe a minute. It saves me from explaining context over and over.

Parallel Agents Are Not a Gimmick

OpenCode can run multiple agents at the same time. I thought it was a marketing feature at first. Now I cannot go back.

Say I am adding a feature that touches the frontend component, the backend API, and test files. I spin up three agents, each handles one file. They work in parallel.

It is not 3x faster, but it is noticeably faster. No waiting for one agent to finish before starting the next.

One rule: do not let two agents touch the same file. Split by file, keep it clean, and the parallel work stays safe.

LSP Integration Cuts Out the Compile Step

After every change, OpenCode runs LSP checks automatically. If there is a type error or syntax problem, it sees the error message and fixes it on its own.

With other AI tools, I would edit code, switch to the terminal, compile, see errors, copy-paste them back, and ask it to fix. Repeat.

OpenCode does that entire loop without me. Not a flashy feature, but I probably skip 20 to 30 manual compiles a day. That adds up.

/undo Is More Useful Than You Think

Messed something up? /undo. You can go back multiple steps.

Real scenario: I ask an agent to rewrite a function. It does it. I look at it and realize the approach is wrong. /undo. Back to square one. Rephrase the request. Try again.

No manual git checkout. No copy-pasting backups.

And you can /redo to jump forward again. That helps compare two different approaches side by side.

Cheap Models for Searching, Good Models for Coding

OpenCode supports switching models. I use two tiers.

One with cheap models like DeepSeek or Groq for exploring code. Search for relevant files, understand the structure, find where something lives. It does not cost much. DeepSeek’s API has a few quirks worth knowing before you wire it in, by the way.

Then I switch to Claude or GPT for actually changing code. Better quality on the important part.

It works well. Cheap for the grunt work, expensive for the decisions.

Custom Commands Cut Repetitive Work

There are things I do every week. Run lint before a PR. Format code. Run tests.

I turned those into custom slash commands.

Just write a markdown file with a prompt. For example, I made review.md that says check the current branch changes, run lint and tests, and list results. Now in OpenCode I type /review and it is done.

Good for any routine you do multiple times a week.

MCP Extensions Are Worth the Setup

OpenCode supports MCP, so you can hook up external tools.

I connected the database MCP. Now it can query table schemas before writing code. No need to describe fields manually.

I connected the browser MCP. It can open a page, take a screenshot, and check whether the UI changes actually look right.

Not required for everyone. But if your workflow involves checking docs, databases, or visual output, it removes a lot of back-and-forth.

Session Sharing Saves Meeting Time

/share generates a link. Send it to a teammate and they can see your whole conversation.

Scenario: I make an agent change a chunk of logic. My colleague asks why did you do it that way. I send the session link. They see the whole thread, the original requirement, the different approaches we considered, and why we settled on this one.

That saves a 15-minute verbal explanation.

Real Combinations I Actually Use

Here is how these things come together in practice:

Picking up an old project: /init to scan, then Plan mode to ask about structure, then Build mode to make changes.

Fixing a bug: spin up an explore agent with a cheap model to find relevant code, read it, switch to Build with a good model, and let LSP auto-check.

Adding a feature: Plan mode for a high-level approach, split tasks by file, run parallel agents, then run tests.

Code review: two agents. One checks logic. One looks for obvious issues.

Final Thoughts

OpenCode is not that complicated. The core is just agent plus LSP plus multiple models. Each feature alone looks like that is it. But used together, in the right order, they save more time than I expected. I compared it against Cursor, Claude Code, and Trae before settling here, if you are weighing the same options.

The key shift for me is this: do not treat it like ChatGPT. Let it read the code itself, check types itself, and run checks itself. You are not there to read the code and feed it back to the AI. You delegate the work. You do not teach it step by step, and that is where the real time savings are.

Comparing AI coding tools? Our AI coding assistants compared page indexes every hands-on report.