My Post-GitHub Copilot Stack for Cost-Effective Vibe Coding

Edit: Someone in the comments asked for a TL;DR, so here it is. In a nutshell, for ex-GitHub Copilot users like myself, the best path according to my research is:

• Implementation: OpenCode Go plan ($10/mo).
• Frontier models (planning, debugging, reviewing): Codex ($20/mo) for GPT models.
• When OpenCode Go gets rate limited: use the free models offered by OpenCode Zen (limited time, data used for training), or subscribe to Ollama Pro ($20/mo), or use cheap Chinese models via OpenCode Zen.
• When Codex gets rate limited: subscribe to Claude Code ($20/mo) for the Opus frontier model.
• IDE: VS Code, with the OpenChamber extension for OpenCode and the Codex extension for Codex.

---

Not so long before GitHub Copilot changed their pricing, I wrote a post explaining that GitHub Copilot was the best offer in the coding AI scene at the time. That post was mainly based on the fact that their pricing was per request and not per token, and that they didn’t impose any rate limiting.

Unfortunately, GitHub Copilot’s competitive advantage was simply that — a subsidized low price and an easy-to-understand pricing model, one that Microsoft was big enough to sustain for a long time compared to other smaller providers.

But the party was over late last month, as many had expected. The pricing for GitHub Copilot jumped 27× for people who paid for their yearly plan. For those on a monthly subscription, the choice was to cancel and get a refund for the remainder of the month, or continue subscribing and pay per token like most other providers.

My choice was obviously to unsubscribe. The selling point that kept me there no longer exists. (And I got a refund of under a dollar. Thank you, GitHub.)

Researching Alternatives

Soon after, I had to do some serious research to figure out the best options.

After lurking on Reddit for a while, I came to the conclusion that I needed to look for subscriptions, not a pay-as-you-go model. Most people said that subscriptions offer better pricing despite the rate limits, so I decided to start with subscriptions and only turn to cheap pay-as-you-go providers if a subscription proved insufficient.

The next step was deciding which subscription to buy. The two that came up most often on Reddit were OpenCode Go and Ollama Pro, with OpenCode Go appearing more frequently in comments.

I checked both and found that they both offer access to open-weight models, mainly Chinese models. OpenCode Go costs $10 per month ($5 for the first month), while Ollama Pro costs $20.

Beyond being more popular, OpenCode also offers the best coding agent, which I’ll talk about later. It’s cheaper, and it also offers OpenCode Zen. This means that if I need to buy models per token later, I won’t need to enter my payment card details on yet another site — OpenCode Zen already covers that, and OpenRouter would have been the main alternative.

In addition, OpenCode Go offers free models for a limited period. Among them is Big Pickle, which was the first model I used when I installed the OpenCode agent. It got me hooked on OpenCode for its speed and quality despite being free (and likely to remain cheap even later). It’s also the model I’m using at this exact moment to generate this blog post — hoping its writing style is good enough.

Big Pickle is said to be based on GLM-4.6 (or 4.7) by Z.ai.

By the way, free models are free for a limited time only (except GPT-5 Nano), and your data is used for training. But this seems fair to me — if you’re vibe coding some non-commercial project of low importance, you shouldn’t be too worried about your intellectual property or your codebase being used for AI training.

In my opinion, OpenCode Go wins on all fronts, and it’s my choice as the main AI subscription for implementation work.

The Frontier Model

I also need access to frontier models for planning, reviewing, and debugging. I can’t simply rely on lower-tier models for complex tasks.

My choice was Codex over Claude. My own experience in my last days using Copilot was that GPT-5.4 outperformed Claude Opus 4.6 by a significant margin. Checking posts and comments confirmed exactly that — it’s what most people were saying too.

Codex is also said to have more generous limits, so I should be able to achieve more with Codex than with Claude.

My choice for the frontier model was Codex.

Choosing a Coding Agent

OpenCode agent was the most obvious choice given that I subscribed to OpenCode Go, and it’s the most starred project on GitHub and the most talked about.

The team behind it, though, made a peculiar decision: they asked OpenRouter to remove OpenCode from their rankings. In their own words, fewer people use OpenRouter with OpenCode, so it appeared lower in the rankings, and this was hurting their reputation.

This is a strange move in my opinion. Professional developers using these tools understand easily enough that OpenRouter rankings track OpenRouter usage across different agents — most developers would rely on GitHub stars instead.

Anyway, I didn’t try any other agents. The other two that appear on OpenRouter’s agent rankings (Kilo Code and Hermes) have very few stars on GitHub, and comments online say OpenCode is far superior.

So my choice for the implementation agent was OpenCode.

For the planning agent, it seems that a Codex subscription could be used via OpenCode — which would offer a better user experience if all the models I use go through the same agent. However, Claude Code’s subscription is blocked by Anthropic from being used by third-party agents.

I decided to use the native Codex experience instead — both the Codex agent and the Codex subscription. In my opinion, this gives me the best out of Codex, as I’ll also be relying on Codex’s own harness in addition to the models.

My main agent for planning, reviewing, and debugging difficult issues is Codex.

Integrating Everything Together

At first, I installed the Codex desktop app on my Windows 11 machine and enabled the experimental feature that allows connecting to remote hosts via SSH. It’s still experimental, but it worked — despite some annoying bugs at first (it refused to create the sandbox). By the way, if you encounter this issue of Codex desktop refusing to create the sandbox despite installing bubblewrap and following the steps in their docs, simply close the project. Weird, but it worked for me. People online suggested renaming your .codex/config.toml file so Codex would recreate it, but that didn’t work in my case.

I got it working after a while. But the experience was bad.

The Git integration is extremely poor. My projects are usually monorepos with many submodules, and I found no way to use their Git integration to conveniently view the changes Codex was making.

I didn’t see anything good in their desktop app. It’s slow on my relatively performant computer and is essentially a thin wrapper around Codex CLI itself.

I ended up dropping the idea of using Codex desktop to access my Linux work instance remotely.

VS Code Wins Again

My next option was the VS Code plugin. I installed their official plugin in my VS Code remote development instance and it worked like a charm. The integration is good, and it gave me a familiar feel reminiscent of my past GitHub Copilot experience.

I had thought that since I don’t write any code anymore — probably haven’t written a single line in at least a year — I wouldn’t need VS Code or any code editor.

I was wrong. VS Code is simply superior. It’s very stable and complete. It just works. Git submodules work perfectly, workspaces work well, everything integrates seamlessly. So even if I don’t use it to write code, I still need it for the integrated experience and for making very small configuration changes.

I also gave Zed another shot — an editor I wrote about a while ago — but it still didn’t work for me. The aesthetics felt off, and I found it hard to use for more than a few minutes. It didn’t look polished to my eye, rendered some things oddly, and didn’t seem to scale well on my setup. I was quickly back to VS Code, which in my opinion remains the best editor and IDE for this AI era.

I also gave Neovim a try but was blocked almost immediately — I didn’t know how to open my whole project in it, and a Google search told me I needed to use a TUI called ranger to browse files. No thanks. I need a setup that is productive and well integrated by default. I’m not trying to impress anyone by making ten keyboard clicks for something that takes one mouse click everywhere else. The TUI experience, except in very rare cases like an AI agent, is overly complicated and hinders productivity.

OpenCode and VS Code “Integration”

The next step was integrating OpenCode with VS Code for a fully unified setup.

When I checked the OpenCode docs for how to use their agent with IDEs, I found that they literally describe running the opencode CLI in the IDE’s terminal emulator as “integration” and a “plugin.”

At first I thought that if I ran opencode in VS Code’s terminal, it would somehow detect it was in VS Code and install an extension. Instead, it was just strange to call running a CLI in a terminal emulator “integration.”

I was wrong — the OpenCode team genuinely describe running opencode in the terminal as IDE integration, which felt misleading to me.

The first thing I did after opening opencode in the terminal was press Ctrl+P, and it was grabbed by VS Code instead. That was a bad sign — it doesn’t seem like they even tried that workflow.

My next move was to change VS Code’s Ctrl+P shortcut to something else (I chose Ctrl+Alt+P), but I still wasn’t satisfied.

Then I remembered the OpenCode UI called OpenChamber, which is available as a web app, an extension, and a desktop app (Mac only). I had tried their web app before and didn’t like it much — it didn’t feel polished and didn’t offer enough value to be more than just an OpenCode wrapper.

I checked their extension in the VS Code store. It had very few downloads and the developer hadn’t verified their domain. It had nine five-star reviews though, so that improved the trust score, and I thought it was probably safe to install (hopefully — I’m actually using their extension right now to generate this blog post).

It had only 6k downloads in the VS Code store. I also didn’t like the name much — it contains the word “chamber,” which I think has a bad connotation.

As usual, my first move after installing was to open the extension settings and disable the “send anonymous telemetry” option, which is enabled by default.

Overall, I think the OpenChamber extension for VS Code provides a good UX, and I hope the developer keeps working on it.

Finding a Git GUI

The last thing I needed was a good Git GUI or TUI client.

I almost never use the Git CLI because it requires too much typing, and I don’t think typing is good for productivity. I’m trying to be productive, not impress anyone by memorizing Git commands and manually typing them every time.

Just asking the agent to generate and run Git commands doesn’t solve the issue either. I need something convenient that lets me navigate the codebase quickly, compare different commits, view changes in the index and staged changes, quickly see stashes, remotes, branches, remote branches, revert, merge, pull, fetch — and all of this needs to be convenient.

I checked the most popular option right now, which is Lazygit.

My experience was no different from when I tried Neovim — I closed the window within two minutes. It was simply too difficult to navigate the UI, and I would probably need to spend time watching YouTube videos to understand how to actually use it.

It’s 2026. We have graphical user interfaces that allow for more convenient interactions that don’t require a minute of learning. I moved on.

By the way, I’m a long-time vim user and use it every day — it’s very helpful when editing files locally or remotely, and the keyboard shortcuts are efficient. So I’m not anti-TUI. I only use them when they’re the superior tool, not when I need to spend hours configuring and learning them, then waste time making dozens more keyboard clicks to achieve what I could do with a single mouse click.

I was finally back to my usual Git GUI: Sublime Merge. I’ve been using it for many years, and to this day I can’t find a tool equally efficient and convenient for Git work.

Unfortunately, development by their Sydney-based team is very slow. They rarely release small updates, and they don’t support WSL or remote hosts (SSH). I also believe it doesn’t support Git worktrees, which is likely needed now (though I’ve never used them myself).

It is still possible to use Sublime Merge efficiently with WSL — the way I usually work — simply by running it inside WSL itself. Modern WSL supports graphical Linux apps, so the GUI will pop up. It doesn’t look as good as it does natively on Windows, but it’s still a better option than all the competitors in my opinion.

Also, don’t try to open the mounted Linux filesystem via the native Windows Sublime Merge — it’ll be a very slow and frustrating experience.

What Comes Next

What am I going to do when both OpenCode Go and Codex subscriptions exceed their limits, which will likely happen very soon? I’ll probably subscribe to Claude Code to replace Codex for planning, debugging, and reviewing, and I’ll use OpenCode Zen with free or very cheap models for the implementation phase. I may also give Ollama Pro a shot.

The one thing I’m least likely to do is use GPT or Claude via their pay-as-you-go pricing models — either from the providers themselves or via OpenCode Zen or OpenRouter — because they’re very expensive and most likely not worth the money given how close the Chinese models are to them in benchmarks.

Regarding benchmarks, I used to rely heavily on SWE-bench, but I think OpenRouter is the better resource for finding the best models right now. It gathers benchmarks but also shows real-time usage by real people. When a model is heavily used by developers the previous week, that’s a strong signal its price-to-quality ratio is high. Real users are the real benchmark — no one will keep using a model if it’s bad or too expensive for its value.

What I’ll Research Next

Finally, what’s my next area of research? I’ll likely need to investigate how to integrate different agents together, which will probably happen via Markdown text files in the repo itself. Some agents (like the planning agent) can write to these files, and others (like the implementation agents) can read from them and also write if needed. This would look a bit like the Claude Code agent teams feature where different subagents share a file to communicate.

I’m also a bit behind — likely because of my reliance on GitHub Copilot for too long — regarding Git worktrees, which I’ve never used, and also regarding agent skills and custom subagents. Hopefully I’ll learn enough about those topics and write a post summarizing my findings.

Git worktrees require some special treatment in the repo, according to many people online, to be used efficiently, so I need to research that first. I also need to find the best way to multitask, as my human brain produces worse results when I’m working on multiple tasks at the same time. Agents usually don’t take too long to run, so if I’m running two or three different agents working on different things simultaneously, I may end up confused and giving bad instructions or steering the models poorly. My main role as the human in this AI development loop is to make the right decisions.

I’ll need to give Git worktrees a good amount of thought — both on how to organize my work to stay efficient while using them to multitask, and on how to structure my repos (or monorepos) to support them effectively.

Please let me know in the comments if my reasoning makes sense to you. And for those like me who are ex-GitHub Copilot users, did you make a similar decision, or did you end up making different choices?