Why I switched to OpenCode Web UI

I have been bouncing between AI coding tools hard enough lately that it probably counts as a hobby.

The short version is that I ended up on OpenCode Web UI, and for the kind of work I do, it is the first setup that feels like it is lined up with reality instead of asking me to adapt myself around the interface.

That said, the phrase “I switched to” may be granting this entire situation a level of permanence it has not really earned. It is equally possible that I am just excited about the current thing and will be back in some other interface the next time I get distracted by a new capability, a better workflow, or a shinier button.

The longer version is a small tour through the current AI agent toolchain circus.

The path here

I started where a lot of people did: VS Code with Copilot. That was useful, but mostly in the autocomplete-plus-chat sense.

Around that same period, I also did the browser chat version of this whole thing with ChatGPT, which was obviously useful in its own way, but still felt one layer too far away from the real work.

Neither of those was yet the thing I wanted, which was a tool that could stay inside the work, keep context, use the machine, and actually help carry engineering state forward instead of just suggesting fragments.

From there I spent time in terminal-first tools: Cursor in the terminal, Claude Code, Copilot again in CLI form, and then OpenCode Client. After that came Codex CLI, which I still think is amazing. Then T3Code, which is also amazing, but for me it did not quite click all the way into a daily-driver shape.

Then Codex App, where I stayed for a while. I really liked Codex App, especially as a desktop experience. But one of the things I kept wanting more of was time with open-weight models and broader model access through services like OpenRouter. I was increasingly less interested in hopping between one interface for one family of models, another interface for another set, and a browser tab for something else again. What I wanted was one environment where I could keep the workflow stable and change the models underneath it.

Then OpenCode Desktop, which was excellent for the half a day I was using it.

And then, basically, I learned more about OpenCode’s Web UI.

That was the moment the stack snapped into focus a little.

Because the thing I kept running into was not model quality alone. A lot of these tools are now genuinely capable. The real problem was the combination of model access and interface layer around that capability. I wanted a setup that gave me a wider model bench, including open-weight options, without making me relearn the room every time I switched.

The terminal is not always the right answer

I like terminals. I have spent most of my life in them. This is not an anti-terminal argument.

It is just that a terminal is not automatically the best interface for every kind of developer work, especially once images and loose files enter the picture.

For web development, drag and drop matters. Copy and paste matters. Grabbing screenshots, dropping in reference images, pasting UI mocks, moving bits of visual context around quickly, and not fighting selection behavior all matter. A lot.

The pain point is very ordinary. If I want a model to look at a spreadsheet, a folder, a PDF, a screenshot, a broken file, or some old notes, I do not want to stop and go hunting for the path so I can paste it in like I am filling out tax paperwork. When I am iterating on a site, the loop of save screenshot, find file, copy path, paste path, repeat gets old fast.

Taking a screenshot and pasting it straight into the chat box is a huge win. Dragging a buggy file or an old pile of notes into the context is a huge win. It is exactly the kind of boring interface friction that seems trivial until it keeps showing up all day.

The problem gets more obvious once you spend enough time in layered setups like Windows Terminal, WSL2, tmux, SSH, browser tabs, local assets, screenshots, and chat transcripts all crossing streams at the same time. At that point, terminal purity stops feeling elegant and starts feeling like one more thing I have to work around.

The Web UI solves a very practical problem for me: it lets the real work happen in Linux while letting the actual human interaction happen in a normal browser. That is a much better split than it sounds on paper.

Why OpenCode Web UI won me over

The strongest thing about OpenCode right now, at least from where I sit, is that it looks like a Linux-first backend with multiple front ends attached to it.

That is exactly what I want.

I want the repo, shell behavior, permissions, package managers, and general build reality to stay in Linux. On Windows, that usually means WSL2, which lines up with my own experience closely.

Then on top of that, I want the frontend to be comfortable.

The browser gives me:

• normal copy and paste
• easy image drag and drop
• better text selection
• easier scrolling through long sessions
• less nonsense around mouse capture
• a more natural place to keep multiple sessions open
• the ability to fiddle with JavaScript against the page itself, which is absurdly useful when I am using that stupid but unbelievably helpful Chrome “Ask Gemini” feature

That combination matters more than the usual benchmark arguments about which surface is more “native.”

The TUI is still compelling. In some ways it is probably the purest form of the product, and the TUI documentation makes a pretty strong case for it. Codex CLI also set a very high bar for me there. But for normal day-to-day web work, the browser interface is simply easier to live with.

Why not just stay on Desktop?

OpenCode Desktop impressed me right away. I still think it is excellent, and if someone wants a dedicated app window and desktop-style presence, I get the appeal completely.

But once I understood that the Web UI gave me most of the practical comfort I cared about, without asking me to care as much about desktop-shell behavior, the browser started looking like the simpler answer.

That does not mean it is perfect.

In my case, the actual “Open Project” UI has been extremely broken, to the point that it stands out immediately as the weakest part of the experience.

So this is not me saying the Web UI is flawless.

It is me saying it currently has the best tradeoff curve for how I actually work.

What finally tipped it

The real deciding factor ended up being two pretty ordinary things: I wanted one stable environment across a bunch of different models, and webdev is visual enough that it really wants browser ergonomics.

When I am working on UI, I need to move fast with screenshots, pasted images, copied error output, reference snippets, and long-running sessions I can scan comfortably. At the same time, I do not want my tooling strategy to collapse every time I decide I want to spend more time with a different model family or test something open-weight through OpenRouter.

The Web UI gives me Linux-backed correctness on one side, browser comfort on the other, and a single place to work while I move across providers and models. That is the first setup in this category that feels like it respects all three parts of the job.

That is also why the journey matters. Every step on the way had something I liked.

Codex CLI is amazing. t3 code is amazing too. Codex App held my attention for a good while, and I still think very highly of it. OpenCode Desktop is good enough, fast enough, that I would not blame anyone for stopping there.

So OpenCode Web UI is where the tradeoffs have landed in the right order for me, at least for today.

Not the most ideologically pure answer.

Just the most usable one I have found so far.

That said, I have been changing AI tooling often enough lately that I would not call any of this a permanent settlement. In some stretches it feels like I switch tools every other week. On a more ambitious day, apparently twice before dinner.

So this is the best answer I have right now, not a blood oath. By the time you finish reading this, there is at least some chance I will already be enthusiastically testing something else and pretending that was the plan all along.