Two Weeks with OpenCode

Two Weeks with OpenCode

For the last two weeks I tested OpenCode's TUI for "AI" development. I pointed it at my Ollama server and tried several models. I installed Opencode through a package manager—not by running curl | bash, which would be reckless. For extra safety I also set it up in a Fedora Silverblue virtual machine, letting me evaluate Opencode and the ostree‑based system at once.

I keep the model thoughts separate from Opencode itself.  The Opencode TUI is great as it sets sane defaults and gets you started quickly.  Because it runs on your machine, it can access everything locally, so I used all my own utilities during development. I never let Opencode install missing tools; I handled that outside the app. With sudo permissions, Opencode could install the needed tools if I’d let it.

Open Code Itself

Opencode just works. It performs best when given a long context—32 k tokens or more—so it can feed the chat history to the LLM and produce answers that line up with what I need. I didn’t use any fancy tricks like agents or MCP; I simply wanted to experiment with hacking local code.

By default, Opencode uses the provider’s cloud models. It says it doesn’t collect training data, but that depends on the LLM host.  I tested the "Big Pickle" model on a few open repositories and it performed adequately.  

Connecting to Ollama isn’t as simple as running /connect ollama and picking a model.  
You must create ~/.config/opencode/opencode.json and manually configure each model that your Ollama instance offers.  I hope a future release adds an ollama ls style command so the models appear automatically, just like with other providers.  Once configured, Ollama behaves like any other provider.

LLM Models

Regardless of Opencode, the tool ships a bundle of prompts that you hand to the LLM to steer answers toward coding. It helps, but only modestly. As I noted earlier, the effect improves when you feed the model a larger context window.

GPT OSS 120b

I first ran the model on my Ollama server because it’s generally solid.  I found I had to spell out exactly what I wanted it to do.  It’s like working with a fresh intern who’s taken a few coding classes.  All in all, it’s not bad.

ZAI GLM-4.6/4.7

I first tested the model on my Ollama server. It’s built for coders and grasps code—even complex codebases.  Using it feels like working with a junior developer: the basics are solid, but you need clear guidance to keep it on track.  Treat the process as four steps: tackle one step at a time and verify each before moving on.  A large context window helps, but I still broke complex projects into sub‑steps to stay focused.  The model handles popular languages well, such as: shell, Python, SQL, JavaScript, and C. It can touch Haskell or Julia, but isn’t the best there.

I then tested it with Cerebras AI. The basic interaction doesn't change, but it's vastly faster. As I'll mention below, tasks that take more than 20 minutes on my Ollama server, are done in less than 2 minutes with Cerebras.

Qwen 3 235B Instruct

I found this model to sit between OSS 120B and the ZAI GLM models. It’s built mainly for coding in popular languages and does a solid job overall.  It feels like a junior developer: you have to spell out every step, or it gets lost.  It outperforms OSS 120B but doesn’t reach the level of the ZAI GLM models.

Lessons Learned

While continuing to work through Learn Physics with Functional Programming, I’m already thinking in functional terms about how to structure code. The LLMs make that mindset a necessity: they force me to lay out clear, logical steps toward a goal. The result is cleaner reasoning on my side and more useful, focused responses from the models.

Having a “free” junior developer at hand lets me focus on the tooling and glue scripts I need but can’t write myself. I spend about 15 minutes drafting logical prompts, and the model delivers a working program.

For example, my openbsd/autosize.sh script had a bug for a long time where it didn't quite calculate the sizing correctly. I always corrected this bug in my head when running the script. I asked opencode/zai-glm to figure it out. After roughly 25 minutes of iterating, it solved the issue and presented a working script. Why 25 minutes? Because it went down some very odd paths to finding and solving the bug. After reviewing the output, I asked it to write the commit message and then commit it. This commit is 100% human-in-the-loop but "AI" written and committed. I tested the exact same revision and code with Cerebras AI and the 25 minutes was reduced to roughly 2 minutes.

As for Fedora Silverblue, it just worked. Every update requires a reboot, which gets annoying fast. Even rpm-ostree apply-live didn't work well. I found myself updating just before shutting down to avoid rebooting in the midst of a coding session.

TL;DR

More logical thinking, "cheap" junior developer with the right model. Cerebras is faster than my Ollama machine.