"A major overhaul": OpenCode 2.0 puts its terminal, desktop, and web apps on one shared service
Vince and Ava dig into OpenCode 2.0’s real claim: the product is no longer a terminal app with extra surfaces, but a shared local service that makes sessions portable across terminal, desktop, web, and scripts. They like the architectural honesty, poke at where the promises may overreach, and land on who should actually care: teams already living with coding agents, not people dazzled by another feature checklist.
Transcript
Vince The interesting part of OpenCode two point oh is not background agents. It’s that they quietly turned the app into a service.
Ava Yeah. That’s the real claim. Terminal, desktop, and web stop being separate products and become views onto one local process.
Vince Which is such an Exploring Next thing to get excited about. You take the boring plumbing, and suddenly the user story gets way better.
Ava Right.
Vince Start a session in the terminal, pick it up in desktop, let a script connect to the same thing later. That’s not glamour. That’s removing the stupid re-briefing tax.
Ava And it explains why the rollout looked messy for months. If you’re replacing the execution model under every surface, the weird in-between state kind of comes with it.
Vince Also, I enjoyed the extremely direct corporate line of, basically, the old API was bad. More companies should just say that.
Ava Oh, absolutely.
Vince You know what I mean, though. It’s weirdly reassuring.
Ava It is. And the technical evidence in the piece actually matches the claim. The new API gives the agent more environmental control. It can spin up a Git worktree for a task, move a session into that worktree, and interrupt another stuck session. That’s a system designed around long-lived work, not just one prompt in, one answer out.
Vince Mm-hm.
Ava The SDK matters too. They’ve got @opencode slash client for programmatic access, and @opencode slash sdk for embedding the thing into other apps. If that really uses the same core as the C L I, then okay, you’re not maintaining three half-different agent stacks anymore.
Vince Which is who should care here, right. Not somebody casually trying a coding agent for ten minutes. It’s the person already living in this stuff, or the team trying to wire one into an actual workflow.
Ava Yeah. And Kilo rebuilding its C L I and V S Code extension on OpenCode is decent evidence that this was already becoming infrastructure for other tools, not just a standalone toy.
Vince Tiny caveat before we sound too certain. We did the reading, not the full forensic rabbit hole, so if one detail sounds wild, check it. This field mutates faster than our tabs do.
Ava Exactly.
Ava The part I’d push on is Code Mode. Mechanically, I buy it. Wrapping M C P servers and OpenAPI endpoints as callable functions inside a lightweight JavaScript interpreter should cut context bloat and avoid a model round trip for every tool hop. That GitHub-to-Linear example is sensible.
Vince But the line about adding a thousand tools with minimal bloat is where your eyebrow goes up.
Ava Come on, Vince, of course it does. Minimal bloat, maybe. Useful discovery across a thousand tools, that’s a different question. You solved token overhead. You did not automatically solve planning quality, naming collisions, permissions, or whether the model picks the right function when fifty of them look semantically similar.
Vince No, that’s fair. But even that narrower win is real. If the tool layer stops eating half the context window, more integrations become practical, and that changes what people will actually bother wiring up.
Ava Yeah, I agree. Same with background subagents and shell commands. The value is not that parallelism sounds futuristic. It’s that I can keep moving while tests run, or hand code review to another model without freezing the main thread.
Vince There’s your product sentence. The job description is the product, and here the job is keeping the agent session alive across surfaces and side tasks without making you babysit it.
Ava Stop it. That is painfully on-brand for us.
Vince I cannot believe episode ten sixty-eight is us once again being impressed by receipts, worktrees, and a daemon.
Ava Okay, that’s genuinely funny. But also yes. The migration cost is the real practical check. One point oh plugins break. Old server API integrations need updates. Updates aren’t automatic anymore, so users have to run opencode upgrade dash dash major or use slash update. That friction is healthy if they’re trying to avoid surprise breakage, but it means this wins only if the new model feels obviously better fast.
Vince I’d put seventy-thirty on OpenCode publicly shipping clearer migration notes or in-product upgrade guidance before mid-November. Named thing: OpenCode two x docs or release notes get more explicit. Event: a visible migration aid lands. Window: one month. Because the confusion around whether two point oh was really stable is all over this story.
Ava That sounds right. Not a capability bet, a packaging bet. Honestly, that’s usually where these things get decided.
Vince Yeah… and annoyingly, you’re right. Anyway, Ava, this is one more point for the boring camp.