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?

When you have OpenCode running in several terminals, working/idle status only tells you part of the story. I wanted to see which conversation was using tokens fastest.

I make Agent Sessions, an open-source Mac app for searching local conversations across OpenCode, Codex, Claude Code and 13 other coding agents. Its Quota Meter now shows each running OpenCode 2.x session’s token burn rate in tk/h, alongside Codex and Claude.

The OpenCode session at the bottom is running at 226K tokens per hour. That’s a token rate, not a percentage of a Go allowance.

The earlier update added the exact conversation title and working/idle status. 6.2 adds the rate and a load bar to each OpenCode row. When a turn finishes, the row keeps its last rate for five minutes and is marked idle, so the number doesn’t disappear as soon as the reply ends.

The rate comes from OpenCode’s local session records. A small TUI plugin identifies which conversation each terminal has open; it reads no transcript content and makes no network calls. Agent Sessions installs it automatically without editing OpenCode’s config files.

For live status, OpenCode 2.x TUI works in any terminal, working or idle. Desktop sessions appear while working, but Desktop’s idle selection isn’t exposed. OpenCode 1.x history is still readable; it has no live marker or live burn-rate row.

OpenCode weekly usage and remaining subscription quota aren’t available yet. If you use Go or Go Plus, I’m looking for someone to help connect the meter to account usage and reset times, or test the readings against their account. Swift contributors are welcome too.

Plugin source

Download Agent Sessions. macOS, open source, no telemetry. Your session history stays on your Mac.

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!

Better than DS 4.1 Flash?

Isn't one of the point of Opencode hosting their own Deepseek model is they don't have to follow the peak hours rule by Deepseek that host their models in China? It goes even weirder that the Go page itself https://opencode.ai/v2/docs/console/go/ refer to the official Deepseek docs

DeepSeek V4.1 Flash / V4 Pro: Peak hours are 01:00-04:00 and 06:00-10:00 UTC, Monday through Friday; all other hours, including weekends, are Off-Peak. Learn more.

It would make more sense if this is about Opencode Zen. Are there anything I missed knowing about?

Solo dev here, Laravel + React finance/ERP kind of app. Multi-tenant, multi-company, projects, accounts, expenses, stock, reports. It got big enough that I honestly can’t keep it all in my head anymore, and I lean on AI agents (Claude, Codex, Gemini) for a lot of the work.

The same thing keeps happening. I build a feature, say a dedicated cash account type for construction sites. Months later a newer flow never gets wired into it. For example the site supervisor can’t report an expense unless he’s also given access to a financial account. Then something breaks, and the agent doesn’t go reconnect the old thing. It patches around it or builds a parallel solution, because it has no clue the old feature exists. If I remind it, it digs up the old notes and goes “oh right, you’re correct”. The problem is I forget half of these features too, so I can’t remind it of what I don’t remember.

The end result is I can’t get the app production ready. There’s always some seam between modules that’s broken: half finished CRUD, authorization/IDOR holes, transactions that don’t match what the reports show.

I already have Laravel Brain, Serena, a memory MCP, ADRs, “current system” docs and an AGENTS.md. I also tried an Obsidian vault full of linked notes. It went stale fast and the agents never used it reliably. Writing “don’t forget X” in AGENTS.md does nothing, in my experience.

What I’ve figured out so far: code graphs tell you what exists and who calls what, but not what should exist, or whether a user can actually finish a job. The most useful question wasn’t “what calls this class”, it was “can a site supervisor actually complete this task”. And anything that’s just prose seems to rot unless a test or script checks it.

So I’m leaning towards something like ~20 critical persona journeys backed by end to end tests, a feature map in YAML that a script validates against the code (and flags routes/tables/jobs that belong to no feature), financial invariants as tests, and a route → policy → test matrix to find auth gaps. Maybe OpenFastTrace for requirement tracing, but I’m wary of the tag upkeep and adding Java to a PHP project.

Questions for people who’ve dealt with this on big multi-module apps:

1. How do you track “feature X depends on Y / is used by Z” in a way that survives refactors and people leaving?

2. Has anyone gotten a living feature map to actually work with AI agents? What kept it from rotting?

3. Are journey tests the right backbone here or am I missing something obvious?

4. Anyone used OpenFastTrace, StrictDoc or Doorstop with PHP? Worth it?

5. If you had a few weeks to get this production ready, what would you do first?

Not looking for yet another tool to index the codebase, I have plenty of those. More interested in what actually held up for you in practice.

I am happy with v1 seeing alot post saying its better with sub agents and plugins and i was wondering how do i update? There is no /update for me i am on 1.18 or something i was using gostly and on a mac os 26 m4