In this post, I’d like to talk about some power user tips for OpenCode - an open source, model agnostic harness that more people should be using. Hopefully some of the advanced use cases convince you to give OpenCode (and OpenChamber) a shot.
I am specifically choosing to talk about some advanced tips in this post. If you’ve never used an agent harness or are looking to learn how to use OpenCode, this post can be useful but reader beware.
Unleash the leader key
##
While ⌃p (Ctrl + P) will list out all the possible commands (and is helpful),
OpenCode has the concept of a “leader” key (which defaults to ⌃x). The leader
key allows you to execute targeted useful commands more quickly and there’s a
slew of useful ones pre-defined1.

Manage multiple sessions - leader l
##
People reach for whole terminals and extra tooling to juggle between agent sessions.
I too had an overly customized tmux setup that looked like this:

OpenCode simplifies this. Just hit leader + l and you view current sessions
and can instantly switch to that session by just selecting it from the list.

The ability to quickly rename a session from this view is a godsend for me and what lets me be organized.
you can pass a --dir . flag to opencode when launching it, which filters
the session list to just this workspace/directory by default. You can
alternatively not pass that flag, and the session list will show all
sessions.
Fork (or Branch) sessions /fork
##
Forking takes the session you’re in and spawns a new one. You branch off into a separate conversation while the main agent keeps grinding on whatever you left it doing.
I love this feature and even cobbled my own version with tmux long before most harnesses shipped it.
Claude Code, Codex and other harnesses have caught up and support this feature. But OpenCode’s UX is the smoothest.
You simply type /fork in your chat. It gives you the option to fork the
current chat or from a previous point in the message. You can then rename the
forked session right from the list ui, and jump back and forth. The easy session
switching again comes in handy here.
Going back in a conversation - leader g
##
Need to rewind to an earlier point in the same conversation? In OpenCode, there’s no escape-escape dance. leader g shows you a timeline and you can revert the conversation instantly, fork a new session from there, or just copy the message text.
Model switching - leader m
##
Probably one of the main reasons I find it hard switching away from OpenCode. I
can bounce between GPT-5.5, Kimi K2.6, and Opus by just hitting
leader m2.
leader+mswitches the model on the fly.ctrl+tchanges the reasoning type.
I see a future where we will have smaller models we can run locally. OpenCode can point to that ollama model you have running on your own machine too.
Click here if you’re curious about my model choices.
LSP support ##
Not everyone realizes this but OpenCode ships with LSP servers built-in. This means the coding agents inside OpenCode understand how to navigate different programming languages better. You’ll find less file search and grepping.
Anthropic even recommends LSP server integration as an advanced move for making harnesses behave in large codebases.
OpenCode gives you much of that for free.
Custom agents ##
The other reason I swear by OpenCode: hit tab to cycle through custom agents.
Here’s a few I use a lot:
- red-team — think differently from the implementer with an independent adversarial lens and hunt for failure modes.
- ghostwriter — drafts messages, posts with a less AI tropey voice.
- brainstormer — custom agent that’s explicitly tuned to help me brainstorm ideas, plans etc.
- pr-reviewer — strict reviewer that ignores past conversation and reviews with fresh eyes.
- kimi-coder — a coding agent guardrailed to Kimi: fast, cheap implementation.
- agent-kombat — see my agent-kombat post. I have it wired into a custom agent for quick use.
When an agent fans work out to subagents, leader + down pulls up the
subagent view so you can watch them work.
Headless mode ##
Like others, you can use OpenCode for scripting and one-shot reviews:
opencode --prompt "Review the code in src/auth.ts" --output review.md
Enter OpenChamber #
So up until now, I’ve mostly talked about features in the context of the TUI. My good friend YY recently introduced me to OpenChamber and it’s changed a lot of things for me.
OpenChamber is an OpenCode GUI wrapper. OpenCode already has a web client btw. But OpenChamber has a lot of nice bells and whistles.

But here’s the kicker, it’s using your same OpenCode server. In a previous post I dug into OpenCode’s server-client architecture: you run OpenCode as a server and connect multiple clients to it.
A client can be a terminal tab, your phone, a desktop, a browser — each an isolated session pointed at the same server, fully synced. OpenChamber is just another client, but a super powered GUI one.
Free remote control from your phone ##
This feature has taken the world by storm; especially since Codex introduced their implementation.
OpenChamber gives you this feature for free with a super nice UX.

One button click and either using cloudflared or ngrok internally, it opens
a secure3 tunnel that you can connect your phone or another client to.
So now, your phone controls OpenChamber and by proxy OpenCode exactly as you
would from your computer.
This was possible with OpenCode and tailscale too (as I mentioned in my previous post) but OpenChamber’s UX and secure tunnel approach makes this fluid.
I almost never take my work laptop with me, when I’m getting out of the house now. Just speaking to my phone and a browser tab that has OpenChamber open.
Multi-run ###
The other OpenChamber feature I lean on: multi-run. You have a prompt and want to try it across several models at once. I think Cursor was the first to introduce this feature. OpenChamber provides a super nice UI for this. This is how I’ve been kicking the tires on Opus 4.8 and updating my model choices.
Tip on syncing OpenCode and OpenChamber #
There’s just one caveat to be aware of. OpenChamber by default probes
127.0.0.1:4096 for a running OpenCode server. If it doesn’t find an OpenCode
server there, it will silently spawn its own.
So if you truly want all your sessions in sync, you should start your OpenCode
server on port 4096 first, then open OpenChamber regularly and it’ll attach
to the one you already have.
I have a handy shell alias to just start a background OpenCode server now like so:
# start opencode server in the background on port 4096
abbr -a -- ocs "nohup opencode serve --port 4096 >/tmp/opencode.log 2>&1 &"
# attach a new opencode TUI instance to above
abbr -a -- oca "opencode attach http://127.0.0.1:4096" # --dir .
If you didn’t read this tip in time, and need to kill previous OpenCode server instances, I suggest the handy procs cli command.
# show opencode server along with port they're running on
procs -i TcpPort opencode
# this is a fish shell nicety where it'll correctly parse the output and feed it to the kill
kill (procs opencode --only pid --no-header)
There’s a lot more to both OpenCode and OpenChamber, but this is the stuff I reach for daily. The bit that’s stuck with me most is the one-server, many-clients setup — run a single OpenCode server and point everything at it: the TUI, OpenChamber, your phone. Steal whatever helps here, and if there’s a tip I’m sleeping on, send it my way.
Heads up: OpenChamber v1.12.0 added a headless web app mode, and remote instance switching now changes the OpenChamber API endpoint without loading the full remote UI. This seems to have busted the remote mobile tunnel setup I describe above. :/
The developer is responsive and working on a fix 🤞. Until then, I recommend sticking to v1.11.7, which you can download manually.
You can also bind commands that don’t have a predefined key. As an example, I bind the “Exit the app” command to
⌃x + qso I can quit OpenCode quickly. ↩︎yes yes, you’re probably nuking your prompt/KV cache, but you shouldn’t have long running conversations anyway. ↩︎
one-time + TTL + revocable connect link ↩︎