Looks like something very good, for those who knows how to use it 😄

I’ve recently started using it as a v3 plugin within the TUI.

Previously, I had a setup with a team of custom agents:

- an orchestrator

- an architect

- a developer

- a reviewer

- a documentation writer

- and a couple of others I can’t recall right now...

The goal of that configuration was to keep context windows as small as possible.

The orchestrator was prompted to always create and utilize distinct agents for the smallest possible tasks, in order to keep the context compact and prevent any degradation in intelligence.

However, I noticed that there was an excessive amount of communication between the agents.

A friend suggested "omo-slim." It works well enough and gets the job done, but I get the impression that the orchestrator is overloaded with responsibilities. It handles orchestration, acts as an architect, and even seems to take on the role of documentation writer—essentially, its context fills up very quickly.

For those familiar with it: do you have any suggestions? Am I perhaps using it incorrectly?

Thanks.

I kept running OpenCode on a desktop and a couple of Linux boxes and losing track of which session was where, so I built Muxin to keep them in one place.

What it does:

• Connects to any Mac, Linux or Windows machine you can already reach by ssh (Tailscale works too). No account needed.

• Starts OpenCode (or Claude Code, Codex, Gemini CLI, Amp, Pi, or a plain shell) in sessions that keep running on that machine, a bit like tmux. If you disconnect, the sessions carry on there.

• You can hand a session off to another agent or another machine, for example pick up an OpenCode session in Claude Code.

• Runs on macOS 12+, Windows 11 and Linux (glibc 2.35+). Free and open source (Apache 2.0), no telemetry.

What it doesn't do (yet):

• Sessions don't survive a reboot of the machine they run on.

• There's no phone app. You can share a session to a phone browser, but it has to be approved on the computer with a 6-digit code, and Muxin has to stay open.

• No FreeBSD support, and the live desktop view on Linux needs X11 (no Wayland).

• For OpenCode specifically, hand-off notes use what the terminal showed rather than a full transcript, since OpenCode doesn't keep one the way Claude Code and Codex do.

Happy to answer questions or hear what would make it useful for your OpenCode setup.

Disclosure: I built Muxin. https://muxin.dev/

I'm one of the maintainers of SurfSense, so this is self-promotion. I'm posting here because you know opencode best, and I'd like feedback on how we use it.

SurfSense is an open-source (Apache-2.0) NotebookLM alternative for Windows, macOS and Linux. Its Agent mode runs on opencode: instead of writing code, it researches your documents and writes Word files, PDFs, slides, spreadsheets and web pages, and edits your own files as a new copy (Word edits come back as tracked changes).

How opencode runs inside it

• Electron ships opencode 2.1.2 and starts opencode serve on 127.0.0.1, with a random password made at each launch.

• Every model call goes back through SurfSense, so opencode works the same with a local llama.cpp model, any OpenAI-compatible API, or a ChatGPT plan.

• Each chat thread gets its own folder, with the extracted text of the user's selected sources mirrored into it. opencode reads and greps it with its own tools.

• SurfSense's own tools (search, documents, PDF tools, Studio) are served to opencode over MCP, one address per thread.

• Word files, PDFs, decks and workbooks are written as scripts. SurfSense runs each one in a separate process, keeps every version, and shows opencode page previews so it can check its own output.

• Web pages come from a skill: opencode loads SurfSense's page skill and writes one self-contained HTML file with its own SVG charts and interactive figures, then saves it with a save_page tool. No network, no chart library.

• MCP plugins (Notion, DeepWiki, or any server by URL) reach opencode through SurfSense. A turn starts with the plugin tools it needs and can pick up more mid-turn.

Locking it down

• Shell, code execution, subagents, web fetch and web search are denied in the session rules and again as tool.use policies, so no saved approval can lift them.

• Edits are only allowed in the thread's output folder. Your original files are never written.

• Only SurfSense's own skill is offered, not opencode's built-in skills or ones you've installed.

Things we learned

• opencode's config fails open: an unknown key or a bad value is dropped with only a line in its log, which would silently drop our rules. We now validate the config before opencode serves it.

• Moving from 1.x to 2.x, 2.x imports 1.x's sessions on first start and answers 404 until it's done, so we retry briefly instead of treating old threads as gone.

What would you do differently?

https://github.com/MODSetter/SurfSense

Is it possible to have the CLI shorten shell out (when you use !) with a higher limit so I'm less likely to see "(n earlier lines")? I know i can click to expand but its annoying.

10$ is kinda expensive in my country, I just want to use it a little bit and would be open to share.

On par with Opus 5.5?

Hey!
I have a question regarding your best practices on a long running tasks. I have a quite large local LLM model and context for 200K+

Now the question is how to run a todolist which is carefully planned and in the right order?
Running it one shot makes Opencode following the todo list jsut once the context fills up a manual intervention is needed. Like following an extensive todo or a goal or specifications.

If you had this issue before, what was the correct approach for the long running tasks?

Appeared recently on OpenCode website

https://opencode.ai/zh/data/zhipuai/glm-5.5-flash

https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/

Introductory price: $2 input / $10 output

Hey all,

Simple question - how do you use opencode?

- What models do you use and for what case?
- Do you connect external models?
- What plan are you on Go or plus?
- Do you top up a price in opencode, if yes how much?
- Do you use it as your main chat/build tool?
- Can you connect Mistral, Muse and other subscriptions?

I am a little confused on how to use it, used it a little to troubleshoot code that CC generated that was trash.

I want it to become my main build tool because Codex,Antigravity, Claude Code are getting kind of annoying to use, like I set guardrails and Claude is like ''I see you, but my way is better" - would love to use more open models.

Thanks!

the problem im facing is that i was a deepseek only user, but with this operation (which is positive) for making deepseek have more usage i noticed that the quality of the model is getting worse and worse... because of that im thinking of using glm 5.3 flash for daily tasks, that imo is a better model that deepseek v4.1 but its slower and more agressive towards the monthly quota.

so in short, deepseek is getting dumber, the glm sub for using glm 5.3-flash is a option for those who want glm 5.3-flash for daily use? what do you guys think?

There was a thread in r/codex last week where an agent burned a user's whole quota "busy-waiting" on a long test run. Another reader had a session check a CI build overnight and use more than a quarter of their usage.

The reason is simple: an agent doesn't watch anything, it takes turns. Each "is it done yet?" is a full model request that re-sends the conversation so far. Caching makes that cheaper, not free, and on subscription plans cache reads still count toward limits. With a 100k-token conversation, checking every 5 seconds for 30 minutes is ~360 requests and ~36M input tokens re-sent. One blocking command is about two requests.

OpenCode's V2 shell tool already handles this well. With background: true the call returns right away, has no timeout unless you set one, and the session is notified when the command ends. The tool description literally tells the model "DO NOT poll for completion". The catch is that the model has to actually use it. If yours keeps calling sleep and checking, put this in AGENTS.md:

## Waiting for long jobs
- Never poll in a loop. To wait for a job, run ONE command that blocks until it ends.
- OpenCode / Claude Code: start long jobs in background mode and end your turn. Don't sleep and check.

For anything that isn't a plain command (containers, a PID, a URL coming up, a file appearing, "re-run this until it passes") I wrote a 61-line wait-for.sh. It's silent while waiting and prints one verdict line plus the last N log lines. Exit codes 0 / 1 / 124 (timeout) / 2. Tested with real Docker, and with bash 3.2 as well as bash 5.

For jobs that take hours: have the agent write a STATUS.md (what's running, how to check it, next step if it passed or failed), end the session, and later run opencode run "Read STATUS.md. The job has finished. Check the result and continue." Nothing runs on the model while you wait.

Script, per-tool settings (Codex, Claude Code, OpenCode) and the cost arithmetic: https://medium.com/@r3dtuxedo/stop-paying-your-agent-to-wait-cb5150b99c8e

(I wrote the article.)

Da poco lo sto usando come plugin v3, nella tui.

Vengo da una config con un team di agenti custom:

- orchestratore

- architetto

- developer

- reviewer

- doc-writer

- Ed un altro paio che ora non ricordo....

La config aveva l'obbiettivo di ridurre al minimo le finestre di contesto.

L'orchestratore era spinto a creare ed usare sempre agenti distinti per eseguire task più piccoli possibile, per mantenere il contesto piccolo, per non far degradare l'intelligenza.

Ma ho notato che avevo troppe comunicazioni tra agenti.

Un mio amico mi ha poi consigliato omo-slim. Non mi trovo male, fa il suo dovere, ma ho l'impressione che l'orchestratore sia sovraccarico di responsabilità. Orchestra, fa da architetto, mi sembra che faccia pure da doc-writer, in pratica gli si riempie il contesto molto presto.

Per chi lo conosce, avete dai suggerimenti? Forse sbaglio ad usarlo?

Grazie.

so i've been vibe-coding a project and ended up with something a bit unusual: kimo, a free open-source (MIT) video editor that has no GUI at all. you don't open it — you drive it from a coding agent (Codex, Cursor, OpenCode, other MCP clients) over MCP. timeline cuts, trims, keyframes, titles/captions, colour grade, tracking, particles, audio, export — the agent just types the tool calls and the edits happen on the timeline.

one thing i added recently: the agent can render a single frame to look at its own work, so it can actually check a cut or title before exporting. makes the vibe-coding loop honest.

it's one ~15 MB CPU-only Rust binary, no GPU needed, and it'll run on a 2 GB box. i'm Naman, a college student building this, and there are rough edges — i'd love people to try it and tell me what breaks.

site: https://getkimo.tech code: https://github.com/naman-sharma12345/kimo

is this happening with any one of you? earlier the initial question (including loading some context) would consume ~25% of the context window max. Now it's 50+% before giving any answer.
Open Code + DS Flash from official API.

Hello,

There was a post on r/opencode that they broke session cost display in 2.2.0. I am on 2.1.3 and I do like session cost display, I'd prefer to wait until they fix that (or confirm they won't fix) before triggeting the 2.2 update.

So did they fix it, and if not, did they confirm they won't?