Show HN: From Claude Code to OpenCode – My Evolution in Vibe AI Engineering

2 points

3 months ago

I’ve spent the last few months iterating on my "Vibe Coding" workflow, moving away from closed-box solutions toward a more transparent, multi-provider stack. I documented the transition from Codex and Claude Code to an open-source setup using OpenCode and opencode serve.

Cursor -> Claude Code -> OpenCode -> OpenCode + OpenCode-Manager -> Codex + Tmux + Tailscale -> OpenCode Serve + Tailscale.

Press enter or click to view image in full size

Key takeaways from the journey:

The Provider Lock-in Trap: While Claude Code is powerful, the inability to switch easily between Azure OpenAI, Anthropic, and OpenAI became a dealbreaker for "multi-cloud" local development.

The Memory Wall: opencode consumes a lot, and I didn't find a good way to optimize it https://github.com/anomalyco/opencode/issues/12687. I didn't spend a lot of time on it, because mostly was focused on my own projects. But just query to profile and find leaks didn't help me (github.com/dzianisv/opencode).

The "Open Workspace" Shift: Moving to a browser-based IDE via opencode serve solved my remote access and Git work-tree needs more effectively than my custom Tmux + Tailscale hacks. But codex + my patches to support github copilot (github.com/dzianisv/codex) is still more reliable, because each codex agent doesn't consume more than 100MB of vRAM.

Question for HN: For those building with codingl agents, are you sticking to high-level CLI tools like Claude Code, or are you moving toward open-source layers to avoid provider lock-in? If so, what tools do you use? Does it make sense for me to focus on opencode memory leaks, or with typescript/bun there is no feature? Not a big expert in bun/nodejs VM, but think it still could be limited somehow, like --max-old-space-size=512? Or issue is more fundamental?