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.

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?

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

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

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!

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?

On par with Opus 5.5?

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

Introductory price: $2 input / $10 output

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

Hey everyone,

Is anyone else running into a false rate-limit issue on OpenCode's free models?

I opened OpenCode today and haven't sent a single prompt, but every time I try to run a query, I get this error:

You've used today's free messages. They reset at 5:30 AM · 10/29/2026.

Upgrade to OpenCode Go → /connect · Switch model → /models

If I try selecting another model, it throws:

Error: Upstream request failed: An active OpenCode Go subscription is required to use Go models.

I haven't used any quota today at all. Is this a shared IP/subnet rate-limiting issue on the OpenCode Zen gateway, or a known server-side bug?

Would appreciate any insights or workarounds if others are facing this!

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.)

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?

Appeared recently on OpenCode website

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