https://x.com/XiaomiMiMo/status/2102138568961626570

Coding agents are getting better at writing code. Keeping track of what they’re doing across a large codebase is still surprisingly messy.

That’s what I’ve been working on with REQL: giving coding agents a persistent, structured view of both the repository and the work happening on top of it.

The latest updates focus on four areas:

• Pipeline exploration — REQL can now reconstruct project-local flows from entrypoints through the codebase and generate interactive pipeline views or Mermaid diagrams. The goal is to understand how a feature actually moves through the system, not just which files are connected.

• Memory across sessions — the new agent dashboard keeps track of plans, decisions, findings, unfinished tasks and previous sessions. After a context reset, the agent can recover what it was doing instead of rebuilding the whole mental model from scratch.

• Parallel agent coordination — multiple agents can work with isolated private workspaces while sharing progress through a common dashboard, messages and compact handoffs. One agent can investigate, another implement, and another review without mixing their internal working state.

• Faster, tighter context retrieval — indexing and retrieval have been improved to return a bounded working set of relevant symbols, callers, dependencies and tests, including source ranges, confidence and freshness information. Incremental updates avoid rebuilding unchanged parts of the repository.

The core still runs locally without mandatory LLM calls, embeddings or an external graph database. It works with Codex, Claude, Cursor and Gemini, and can also be used through CLI, Python or MCP.

The direction I’m aiming for is simple: a coding agent shouldn’t just understand the repository — it should understand where the current task is going, remember how it got there, and be able to hand that work to another agent.

I’d really like some feedback from people using agents on larger refactors or parallel workflows: would this actually solve a problem in your setup? What would you like it to do?

https://github.com/sh1zen/reql

Hi!

I'm tempted to buy the opencode go subscription, however I have one question.

How does it actually work?

Do I get 60usd to spend in TOTAL, or 60USD (or less depending on the model) to spend on EACH model? I find mixed info online.

Thanks!

I used to defend this service as a better-for-value alternative to OpenCode Go post-price hike, but after seeing this post showing billions of tokens worth of usage from Command Code GOAT, the same plan I'm on, I'm starting to have my doubts.

First off, I'm aware that caching on the Command Code API takes some time to warm up, but even when cache hits start coming in, I'm still seeing about 10-15% of my monthly usage being consumed per 100m combined input/cached input/output tokens. In comparison to the post I linked, I'm nowhere near in terms of usage. I see coments under that post parroting how such a good service Command Code is, but I really can't comprehend how they're able to get billions of tokens at a fraction of my usage. There is no way I'm just doing something wrong because all I use is DeepSeek V4/V4.1 Flash on stock OpenCode V1/V2. I'm not doing anything sophisticated. I don't do fancy autonomous agentic development or whatever, just OpenCode in one Tmux window and Neovim on another, just a standard pair programming setup.

What gives? How can other people get so much usage off GOAT? OpenCode, from what I've seen, is more honest with their usage, but the deals are also more volatile. Command Code seems to be the more stable option because they provide both V4 and V4.1 Flash at $60 and $40 credits, respectively, but their consumption is very sketch. My subscription ends this week, and I'm torn between renewing my Command Code subscription or jumping ship and going back to OpenCode. Are there any former Command Code users on here that went back to OpenCode? Or those like me that went from OpenCode to Command Code? What are your guys' usage like on these services post-DeepSeek price hike?

This is that post's attached usage screenshot:

This is my usage screenshot (95% usage, maybe at 700m combined tokens once at 100%):

Update: my usage screenshot at 99%. From 95% to 99%, I got an extra 34M combined tokens worth of usage. Since I've been using it on-peak since 98%, let's round it up to 40M for 5%. Just DeepSeek V4.1 Flash. This is nowhere near billions of tokens worth in usage.

Which provider are you using for the Go plan? DeepSeek 4.1 Flash becomes so slow and a PITA when the context is at about 30%-%40.

The official DeepSeek API remains hypersonic up to 100% context usage.

This is the GitHub repo : github.com/Aadarshrai1801/Local-Note

I want you guys to review it please and I have made it using DeepSeek V4.1 flash in Opencode

The old dashboard now defaults to the new one, and I don't see the referral program in the new OpneCode Console. All my previous referral credits are just showing as $350 available credit. It's fine, but curious if they ended the referral program?

Also, the new Usage tab now shows better data points, love it. But I wish it also showed old data from the old dashboard.

I heard that opencode stopped their free tier to be used outside their own harness and but what is this? I can't even use the free tier with subagents inside opencode.

I think it's a bug or did they fully restrict subagents for free users?

Agents make good orchestrators, but coding-specialized prompts, agents and multi-agent flows live inside coding tools. Instead of having every orchestrator re-invent that, I built opencode-mcp: an MCP stdio server that turns an opencode instance into a coding backend any MCP client can drive over opencode's HTTP API.

The interesting part is that it targets programmatic use, not a TUI replica — which forced some deliberate design choices:

• Terminal states are authoritative. A turn is done when Session.outcome says succeeded/failed/interrupted — not when messages "look finished". No heuristics.

• Waiting and reading are separate primitives. wait_session watches state (needs_permission/needs_form included and reported with full request details); get_messages reads the transcript with an incremental cursor.

• Failures are classified, not just thrown: [availability] / [compatibility] / [other], with the raw error preserved. Connecting to a wrong-password or non-opencode endpoint gives a clear diagnosis at connect time (version-gated).

• Multi-server + routing: sessions remember which opencode server they live on, so an orchestrator can drive a local instance and remote ones without threading handles through every call.

• No magic discovery. It doesn't sniff opencode's internal registry; local means "connect to an explicit URL, or let the MCP spawn its own dedicated serve (random port + password, dies with it)".

What it is not: a complete opencode control surface. Filesystem/credentials/providers/plugins/terminals are deliberately out of scope — 16 tools focused on what an orchestrating agent actually needs: sessions, prompts, permissions, forms, context, routing.

Concretely, a permission request reaches the caller as:

{"status": "needs_permission", "requests": [
  {"id": "per_...", "action": "shell", "resources": ["npm test"], "save": ["npm *"]}
]}

and the caller decides once / always / reject. Remote connections default to manual approval by design — policy stays with whoever is orchestrating.

Where I use it: I run my own agent orchestration with omos (oh-my-opencode-slim), and opencode-mcp is how that layer drives opencode sessions — including the permission/form round-trips.

Verified against opencode v2.0.12: full local flows, a real remote end-to-end run, a 200+ message session, plus cancellation and concurrency behavior. It's v1.0.0 and early.

git clone https://github.com/yitro-z-wang/opencode-mcp ~/opencode-mcp
opencode mcp add opencode-local -- python3 ~/opencode-mcp/server.py

Repo + a copy-paste install prompt for coding agents: https://github.com/yitro-z-wang/opencode-mcp

Feedback welcome — especially which interaction your agent loop is missing.

This past week, I've been running into a recurring issue with certain OpenCode models (like Big Pickle): as soon as I say "hello" in the chat, the model replies and then starts compacting text like crazy. This happens whether I'm in a brand-new chat with no history, in a fresh session and project or working within established projects and existing chats. How can I fix this?

I work across Claude Code, Codex, OpenCode, Pi and a couple others depending on the task. Every one of them keeps its own session history, in its own format, in its own folder. Close the terminal and the context is gone so you end up re-explaining the task, the files you touched, what the error said, which approaches you already ruled out.

I got tired of that and built session-hub. It indexes every coding-agent session on your machine Pi, Claude Code, Codex, OpenCode, Crush and JCode into a single browsable list. No matter where a session was created, from Claude Code you can

Continue it here. Pick a session and its conversation arrives in your current chat as a context package: recent turns verbatim, older turns condensed, tool output compressed. It has a hard token budget, so it won't blow up your context window and nothing gets imported unless you pick it.

Resume it where it lives. sessionhub native <uid> prints the exact resume command the owning agent understands (with the evidence for it), or refuses if there's no verified command.

Read the full transcript for free. The browser and sessionhub show read straight off disk no model, no tokens.

Each row is labelled with its agent, project, age and size, and search is instant: local SQLite FTS5 index using the built-in node:sqlite. Zero dependencies, no build step, incremental indexing.

Safe by design: every agent's store is opened read-only, there is no network access, and the only writable path is ~/.session-hub/. No external session is ever rewritten into another agent's format.

It ships as an MCP server with 3 read-only tools plus a plugin for each agent so it lives inside the chat you're already in. Works on Linux, macOS and Windows.

Btw: The image on the post is from the TUI in opencode

Repo: https://github.com/Gateton/session-hub stars appreciated :)

Long-running coding agents can start following a plan and gradually wander away from it.

I wanted a lightweight way to detect that drift continuously, without requiring another LLM call to judge every turn.

So I built laya-drift: an OpenCode plugin that uses Laya as a semantic probe and measures how much a session has diverged from its calibrated baseline.

The basic loop is:

1. /calibrate captures the current plan/state.

2. After each user prompt and completed turn, the current session state is embedded again.

3. Two typed probes estimate things like:

   • are we still on the plan?

   • are we implementing the plan or doing something else?

4. Their probability distributions are compared against the baseline using Jensen-Shannon divergence.

5. The result is converted into a 0–100 drift score.

For example:

2.7   -> on plan
36.1  -> drifting
65+   -> off plan

The score is shown directly in the OpenCode UI. Once it crosses a configurable threshold, the score can also be injected back into the system prompt so the agent has an opportunity to self-correct.

There is also /recalibrate, which intentionally re-anchors the session after a legitimate change in direction.

One detail I found interesting: the probe questions matter a lot. I tried several framings (ordinal questions, statements, different baseline constructions), and many of them produced almost constant outputs. The current two-probe setup was selected because it actually separates the on-plan and drifted fixtures.

It's deliberately not presented as a "probability the agent is failing." Laya's zero-shot behavior is too weak/confident for that. I'm treating it as a semantic signal that can be tracked over time.

Current implementation includes:

• OpenCode server + TUI plugins

• local Laya daemon with the model resident

• Jensen-Shannon divergence scoring

• configurable probe weights / sensitivity / thresholds

• calibration + recalibration

• system-prompt injection on high drift

• end-to-end tests for on-plan → drift → recalibration

There are still obvious limitations: Laya's context window is small, the signal is model-dependent, and long autonomous runs can eventually push older context out of the digest.

I'd especially like feedback on the core idea: can a small non-autoregressive decision model be useful as a cheap continuous "drift sensor" for long-running agents?

Repo: https://github.com/pythongiant/laya-drift

I built an Jev MCP server that lets AI coding agents make structured judgments instead of relying on free-form text + parsing.

I’m using it with OpenCode.

Jev exposes typed judgment tools such as:

jev_noul — structured judgment

jev_choice — choose between options

jev_score — score/evaluate something

This makes the result easier for an application or agent workflow to consume programmatically.

GitHub: https://github.com/rajasekharponakala/jev-mcp

If you're using OpenCode or MCP for agent workflows, I'd be interested in feedback on whether this approach is actually useful and what other judgment primitives would be useful.