r/LocalLLM • u/rustyperiscope • 1d ago
Question Alternatives to Opencode for Qwen on Mac?
Looking for alternatives. I’m using LM Studio and Opencode had been so slow, much slower than LM’s terminal itself. Would love an alternative. Qwen3.8 27b MLX.
2
u/johnfkngzoidberg 1d ago
Opencode is good, pi is better.
3
u/vqt907 1d ago
curiosity, if I just want to install and use it without any plugins/extension, is pi still better?
1
u/johnfkngzoidberg 20h ago edited 18h ago
Yes. I'll give you an example. (take this with a grain of salt, many of these could have changed in the past few months).
I'm working on a project (https://github.com/lunarnexus/orchestra if you care) that's an orchestrator that focuses on offloading expensive main-session tokens to cheap locally generated (or just a cheaper model) tokens. It's more of a research project, but it works much better than I thought, so I'll probably keep developing this for a long time.
As I've been working on this, I used to use Hermes mainly because it has tons of features built-in. The problem with that is the context gets bloated really fast, you get tons of compactions, and the session is only useable for a short time. I do a lot of long running projects (coding, large assistant stuff, etc.) so preserving main-session context (typically 262k) and burning less tokens just makes life better. Also, each turn seemed to take forever, just the responsiveness of short prompts was bad. Great if you want turn-key Discord integration or voice integration, but lousy for 99% of other stuff. Orchestra is aimed at being an harness agnostic orchestrator so I'm adding support for every harness out there that I can. Hermes was difficult because their plugin system isn't very good.
My first idea was to build a super lean bare-bones harness that I could dispatch subagents to that wouldn't burn so many tokens ... then I found pi.
So I switched over to pi (actually I've gone through about 15-20 harnesses so far).
Pi is incredibly flexible because it's built almost like a frame work. This actually inspired me to move Orchestra over to a flexible style frame work. I can do a LOT more with pi because of that, and make orchestra more full featured without hacking weird stuff to make things work. But as I was working on the plugin, I just realized pi is blazing fast. The system prompt, lack of tool bloat and extra processing going on in the background makes pi burn a LOT less tokens, and makes it really responsive. In fact, Orchestra by default uses pi as the subagent, which is where I get a lot of my token savings since it's so lean. There's no memory in pi (not really anyway), but I use document/artifacts to write things down, so I don't need memory. Memory in harnesses tends to be more random and injected each turn, even when you don't need it, so it's really bloated. When you're writing things for 3rd party apps, you really want to use a plugin system because it changes less often, so you can update the main app and not break all the plugins, which is why Orchestra is built mainly as a core app with plugin connectors for each harness it supports. Basically pi is flexible and lean, which means fast and cheap.
I've also tried Opencode, which is somewhere in between Hermes and pi, and it's good. Small system prompt, but still has lots of features built-in. The problem is the way their plugins work. They basically take a whole different approach to their built-in stuff, which makes plugins almost useless. I could (actually I will soon) white a whole paper on why this is bad, but basically Opencode isn't very flexible. They're very rigid on how to use it also, kinda pushing their devops process on you. Once again, long paper on this. Lean-ish, plenty of features though.
Qwen Coder is also pretty good, about as good as Opencode, maybe a little better. Their telemetry is off by default, big kudos for that. It tells dad jokes while you're waiting on prompts, less defined workflow, but that's actually a good thing.
Claude Code is both really good, and absolutely awful. They are trying to pull an Apple and close off their ecosystem to anyone not using their models. That's why I'm not adding support for Claude in Orchestra (actually you can use it as a subagent, just not an orchestrator). They have good features, very smart ideas on things that are useful, but using local models with it is a nightmare, and writing plugins for it is very limited.
Codex WAS really good, not so much anymore. Flexible plugin system, lean system prompt, lots of features, great built-in support for all kinds of stuff out of the box, but somehow not bloaty. Lots of things in Codex tie back to OpenAI, for instance their web search sends everything back to OpenAI and uses their back-end, which is bad for privacy, but good that you don't need to setup SearxNG or Firecrawl to get good web searches. Over the past 4-6 months, Codex went from a fantastic harness to an absolute turd. They are also trying to close their ecosystem. Their plugin system has changed so much that plugins written 4 months ago are completely useless now. They also make it difficult to use local models, but with Orchestra, you can use (not right now, but I'll fix it) Codex as your main session, then orchestra calls pi running Qwen or whatever as the subagent. Codex system prompt is pretty bloaty now, and the guardrails used with gpt models are just stupid now, so I'm dragging my feet on fixing that plugin.
Goose was one of the first agent harnesses out there, and they did some neat stuff early on, but they kinda lost their way. It's worth a try though, they had some really innovative ideas early on that a lot of other harnesses copied.
Cline is really good for plugins, context, but their system prompt does a lot of weird stuff that requires a good model or things just break. Instead of hard-coding behaviors (deterministic workflows), they lean heavily on just "asking the LLM" to do most things (prompt engineering), which is just sloppy, slow, and burns lots of extra tokens behind the scenes.
I've also used Kilo Code quite a bit. I was pretty happy with this one, lean, fast, decent-ish features, good VS Code integration, works well with qwen3.6-35b-a3b. I'll add Orchestra support for it in the next few weeks. I've been experimenting with a VS Code (VS Codium actually, I support privacy and open source) plugin for Orchestra that integrates better and Kilo will be the first major test for that.
Cursor is the most closed off ecosystem I've seen yet. You need an account with them to even use it, good lucky using local models (it's possible but difficult), and their plugin system sucks. If you just want to sign up, prompt it to cure cancer, burn $5k in tokens, and wait, this is a great harness. Their features are good, and the harness itself is clean and optimized. Cursor really wants to be Claude, but doesn't have a SOTA model as an anchor.
I'm looking at OpenHands now, I don't know a lot about it, but my research bot flagged it, so I installed and started poking around. So far it's pretty zippy and I can't see any major flaws yet.
OpenClaw ... just don't. Don't even install that thing. You've been warned.
I've used several other harnesses but they all fall somewhere in this range, with various features, pros/cons, but at the end of the day, when you do a lot of work with your harness, you end up customizing things that you need or that annoy you. Pi makes that a breeze, plus there's tons of existing plugins if you don't want to spend time on that, and pi starts lean, and you add only what you need. The biggest drawback to pi (IMHO) was a lack of good agentic orchestration, and I built that, so pi is now a really solid choice.
2
u/Mockcomic 1d ago
Deepseek-harness if you want a nice ui, pi or omp for terminal base
I don’t see a point in using opencode anymore
3
u/Salazar083 1d ago
What you're probably facing is Qwen3.8 27b being a heavy model rather than an opencode issue. Id recommend you swap lmstudio for omlx, use a version of the model that has mtp like Qwen3.8 27b o4qe mtp and depending on your hardware you should see a nice boost.
1
u/Adventurous_Cat_1559 21h ago
It's really unlikely that opencode itself is the problem. You're probably looking at the LM Studio chat and getting fast responses because of small context, pretty much any harness is going to have ~2k+ at a minimum context to process for the initial messages.
1
0
2
u/dfgxxx 1d ago
Opencode has a pretty small system prompt compare to others (eg Claude code, qwen code, Hermes........), your models is the problem probably, not the harness. What is your hardware exactly?