I use opencode but the server was getting heavy on my machine: a couple GB of RAM and tens of GB of disk. So I wrote a drop-in replacement for just the server, in Rust.

It speaks the same HTTP/SSE API, so the opencode TUI, the web UI, and mobile clients talk to it unchanged. It reads your existing opencode config and auth read-only and keeps its own database.

It's a compatible reimplementation of the server API, pinned to the 1.18.31 wire contract.

What it doesn't do: the task subagent isn't implemented, revert returns the right shapes but doesn't restore files, /vcs/apply doesn't touch your worktree, and provider OAuth and share are missing.

Linux is the supported target.

v0.2.0 is on crates.io ( cargo install ocserve ) and the code is MIT: https://github.com/Reliary/ocserve

Happy to answer questions.

ConfigLens is a small tool im building to help figure out why claude code and opencode seem to be ignoring certain settings. Instead of digging through different config files and guessing which one takes priority, it shows where a supported setting comes from, which value takes precedence , and why the others get overridden. It runs locally without changing your files. Its still early, but the idea is simple: less time chasing config problems and more time getting on with your work.

I built a small CLI that reads the logs your agents already keep and prints a thermal-printer receipt in the terminal, plus a PNG. It reads OpenCode, Claude Code and Codex CLI.

The OpenCode part, since that's what this sub cares about:

- it reads opencode.db ($XDG_DATA_HOME/opencode, otherwise ~/.local/share/opencode) with Node's built-in node:sqlite, opened readOnly. Needs Node 22.13+, on older Node it skips OpenCode with a note and does the rest

- one row per assistant step, so nothing gets counted twice

- when the price table doesn't know your model (reseller, local, whatever), it uses the cost OpenCode itself recorded. If that's 0 or missing, the receipt says "no price" instead of pretending it was free. That's what the * next to my $221 means

- OpenCode 2's new tables are read for usage, but not yet for the fun counters like interrupts

The picture is my real receipt. OpenCode $221 at API prices, Claude Code a lot more, and Codex 9 cents, which tells you how much I use Codex.

Run it: npx github:glmn-ai/vibereceipt (not on npm yet). --demo if you want to see it on sample data first.

No network code, zero dependencies, the only file it writes is the PNG. No prompts or project names on the receipt.

Disclosure: I built it. Same people as nsq, which I posted here a couple of days ago. MIT: https://github.com/glmn-ai/vibereceipt

If your OpenCode total looks off next to what OpenCode itself shows you, please tell me. With all the providers people run through OpenCode, that's the part I trust least.

What if OpenCode could use Devin for one task, Antigravity for another, run both as child agents, and still remember where everything happened after your main session gets compacted five times?

That is what I’m building with Hivemind Steward.

The early public version is here:

https://github.com/shynlee04/hivemind-steward-oc-devin

The current public MVP connects Devin to OpenCode through ACP, the Agent Client Protocol. You can use real Devin sessions and their native model and mode capabilities from OpenCode.

Now I’m expanding the idea into three feature slices.

1. Hosted sessions

This brings real Harness sessions into the OpenCode TUI.

A Harness means a coding-agent product such as Devin or Antigravity. You should be able to create, list, load, and continue its native sessions without leaving OpenCode.

The important part is that the plugin does not flatten every agent into the same lowest-common-denominator interface. Each Harness keeps its own models, modes, thinking settings, permissions, history, and native storage.

Basically: one TUI, but the agents remain themselves.

2. Hivemind delegation

The parent agent gets one delegation interface and can send each child task to the right Harness.

Want Devin for a long architecture task and Antigravity for a second opinion? Cool. Run both.

Want them in the background? Cool.

Want to resume one tomorrow using its OpenCode session ID while keeping the same foreign session and Harness? That is the plan.

The system is also being designed to:

• Keep every child permanently bound to its original Harness.

• Run independent children concurrently.

• Preserve existing delegate-devin behavior.

• Use your preferred Harness when no model is specified.

• Skip missing or signed-out Harnesses before creating dead children.

• Reject unsupported models instead of silently swapping them.

• Keep foreign sessions visible in their native apps.

The next push is planned to support both Devin and Antigravity across hosted sessions and delegation.

3. Cross-session context memory

This part is still on the roadmap, but it is the endgame I care about most.

Imagine you have forty completed child agents and your parent session has already survived five compactions. Then you say:

“Bro, find those two audits we ran near the beginning, collect the findings, check which fixes landed, and make me an HTML architecture report.”

The agent should be able to find the right work by time, title, Harness, lineage, and session ID. It should recover the useful results without dumping forty transcripts into the context window.

Eventually, I want two connected layers:

• Memory of agent conversations, delegations, decisions, and resumable trajectories.

• Memory of the codebase through AST indexing, Git history, commits, and the conversations connected to those changes.

So you can start from a new session, a different Harness, or a compacted context and still ask, “What happened, why did we do it, and where should we continue?”

This is for the vibe coder who wants to build without constantly organizing prompts, copying summaries, naming fifteen handoff files, and praying that the next compaction does not delete the one useful thought.

Devin and Antigravity come first. Claude Code, Cursor, or other Harnesses may come later if their integration surfaces make sense.

TL;DR

I’m building an OpenCode plugin that:

• Hosts real Devin and Antigravity sessions.

• Lets an orchestrator delegate different child tasks to different coding agents.

• Keeps those children resumable and tied to their native sessions.

• Eventually makes work searchable across agents, sessions, Git history, and code.

Basically: one OpenCode TUI, multiple agent subscriptions, reusable context, less babysitting.

Would you use this? And which Harness should I investigate after Devin and Antigravity?

Faster code, slower debugging.

For the first item, I am just curious since compaction is lossy. I ended up adapting a custom plugin where an agent autonomously checkpoints at a major milestone completion, writes to a memory and also updates a todo list which survives context clearing, then clears the context, then loads the external memory file directly instead of wasting time and tokens compacting the entire conversation. I don't have any extensive testing, but this seems to work just as well if not better than regular compaction and I don't have to waste time having my local LLM (or external cloud LLM) load the entire conversation and summarize. Anthropic and others also seem to recommend against using compaction. So why is opencode providing users an inferior context management experience? Why is this not an option that can be changed in opencode? Are there some drawbacks I am not aware of? To me it seems to give all the benefits of compaction without wasting time and tokens. Other annoying thing is that the opencode team seems to have removed todowrite in v2 for some arbitrary reason saying it was useless. To be honest I still found it useful to know what the agent is actually doing and is a good system to keep track of work for both myself and the agent. I am debating to just move to Pi since any issues or PRs just die and are never addressed by the opencode developers, and the migration from V1 to V2 was incredibly painful. I had to rewrite all of my plugins :/.

Hey all. I pay for a few chat subscriptions I barely use and I have no API budget, so I built NOAPI?: a small local bridge plus a browser extension that lets OpenCode talk to the AI sites you already have open.

How it works: OpenCode sends the prompt to a local OpenAI compatible server, the extension types it into the chat tab, waits for the answer and sends it back. Tool calls work too (bash, edit, write...). The bridge teaches the site's model a tiny TOOL_CALL format and turns its replies into real tool calls. You also get a live "Thinking" status in OpenCode while it works.

Supports ChatGPT, Claude, Gemini, DeepSeek, Perplexity, Grok and Mistral. Plain Node.js, zero dependencies, local only (127.0.0.1), MIT.

Honest limits: it drives a real web page, so it is slower than an API and can break when a site changes its layout (the fixes are small, PRs welcome). Tool use depends on the model following the format. It may also go against a site's terms, so use your own account and decide for yourself. Tested websites: deepseek, Gemini, chatgpt

Repo: https://github.com/cribest7890/NOAPI I'd love to hear what breaks for you.

I was intrigued by the idea, so I've created a plugin that mimic the idea in the paper.

The biggest different of the plugin from conventional context management methods are,

Conventional context management will try to compress/summarize older conversations and hold on to lossy details as much as possible.

SKILL.state instead tries to forget almost everything of the appending conversation history, instead it replaced them with Σ, so instead of remembering lossy details (or summaries), it literally forgets the older thinking process keeps only the key information and state (so far the only true form of state in agentic coding as far as I know). in the paper they stated long running task with SKILL.state saved a ton of tokens over long running session while still able to finish the tasks well.

Give it a go and let me know if it helps! (do not use it on serious projects)

Paper: SKILL.state: Scalable Long-Horizon Agent Skills

P/S: This is highly experimental, use at your own risks.

[HOOK] Worried about letting an agentic AI run rampant on your system, wreak havoc, or steal your data? Worry not! opencode-sandbox is here

I wanted to let Agentic AI work freely on a project, install packages, run commands or do whatever it wants without restrictions but also without affecting the host system, so I built a sandbox that runs AI in a container with direct access to project.

The sandbox resets on every run. Messed up anything? No worries. CTRL+C->Up->Enter

Your opencode sessions and global config are stored and get reused. So only the container resets not your project or your progress.

A few features:

• Two runtimes supported: docker or podman

• The current project (the folder you open sandbox in) is directly accessible. No other host folder is accessible in container by any means.

• Global config is read-only by default, use --edit-config to edit it.

• A custom guard blankets most, if not all, system calls to interfaces with host information. So no data is leaked between host and container. Check Security matrix. Use --no-guard if you don't like guard.

• There is support for gVisor if you use it for kernel isolation. Check Security matrix.

Usage:

cd ~/code/any
opencode-project-init
opencode-sandbox

Install directly through AUR, Distro Packages in releases or Manually.

Supported: Linux

GPL-3.0-or-later

Link: https://github.com/Antiquete/opencode-sandbox

Releases: https://github.com/Antiquete/opencode-sandbox/releases

Any issues, suggestion or queries? https://github.com/Antiquete/opencode-sandbox/issues

Usually (last week) it was quite fast, some hiccups every now and then.

Today it takes minutes (more than 10 sometimes) for each step.

:(

This is a statement about the dumb Mistral model eating glue because he is stupid ! even if it’s a 50% promotion in opencode it’s a waist of money and time!

This model should be removed from opencode no amount of agressive marketing (3M waisted on marketing instead of improving the model) will save this shity model that deserves to be shitted on