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

denis4inet · 19 hours ago · view on HN · opinion
quality 2/10 · low quality
0 net
AI Summary

A developer shares their personal evolution in AI-assisted coding workflows, transitioning from closed-source tools (Claude Code, Cursor) to open-source alternatives (OpenCode, Codex) to avoid vendor lock-in and achieve multi-cloud provider flexibility, while documenting memory consumption challenges.

Tags
ai-coding-tools developer-workflow open-source-development provider-lock-in memory-optimization ide-tools multi-cloud
Entities
Claude Code OpenCode Cursor Codex Tailscale Tmux Azure OpenAI Anthropic OpenAI GitHub Copilot
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?

← Back to stories