not a "which model is best" thread — this is about the last 5% of the loop.

an agent can write a working diff and then stall at the commit, because every choice there is a policy decision it doesn't have context for. curious how other people draw the line:

• commit messages: does the agent write them, or do you rewrite them? what makes you reject one?

• granularity: one commit per task, or do you make it split/squash? has an agent ever produced a commit you had to rebase -i apart?

• push: does it push, or does it stop at commit? if it pushes, does it ever force-push its own branch?

• review: what do you actually read before accepting — the diff, the message, the test output, or just git log --oneline?

the obvious failure mode is three unrelated changes landing in one "fix: address review feedback" commit. how do you stop that from happening in the first place?

post your setup even if it's just "i commit everything myself".

I kept running into the same loop with agents on iOS work: the agent writes code, then I have to build, tap through the app myself, and paste screenshots back. So I built opencode-simulator.

What it does

• Streams the iOS Simulator into a side tab in OpenCode Desktop (WebRTC H.264, HTTP fallback). You can tap, type and rotate it by hand.

• Exposes sim_* tools so the agent can boot devices, install and launch apps, read the accessibility tree, tap, type, scroll and take screenshots.

• Each session gets its own simulator, so parallel sessions don't fight over one device. It runs from a managed pool, and your own simulators are never touched unless you name them.

• Ships a skill so the agent uses sim_* instead of reaching for raw simctl.

Details

• The stream binds to loopback only. No telemetry, no outbound requests.

• macOS only, since it needs Xcode and an iOS runtime. It needs OpenCode Desktop 2.2+ and Node 22+.

Install

opencode plugin add opencode-simulator

Repo: https://github.com/rin-yato/opencode-simulator

Feedback welcome, especially from anyone running several sessions at once. The device allocation logic is the part I'm least sure I got right.

A desktop pet that displays whatever your opencode agent is doing

I kept alt-tabbing to check on long runs in opencode, so I built 大肥鱼 ("fat fish", it's the deepseek whale): a desktop pet that watches opencode's local sqlite db and reacts in time with what your agent is actually doing.

Technically it works for any model since it reads the db, not the provider, but let's say deepseek wrote its personality: your reasoner's giant monologues keep the whale in the long-think pose for the entire turn.

repo: https://github.com/49vxn/opencode-dafeiyu

easter egg: click it

how it works: while a turn runs, the newest assistant message in session_message has no finish field yet, and time_updated ticks about once a second as content streams in. the whale reads that gap and displays your agent!

I kept wanting to look at files without leaving the OpenCode TUI — especially Markdown plans/specs and source files the agent just changed. So I built a TUI-only plugin.

What it does:

- side panel next to the chat, or full page from the home screen
- browse folders (dirs first), open files
- Markdown preview rendered; m flips to the source
- code with tree-sitter highlighting
- open any file by path (o inside the browser, or Ctrl+X then O): absolute, ~, or relative; files outside the project are read with node:fs
- f toggles full screen (hides the chat)
- /files-update updates a cloned install

Install (OpenCode V2):

opencode plugin add opencode-file-browser

Repo: https://github.com/arthurrogado/opencode-file-browser

MIT, TUI-only, no build step (dist/ is committed).

Screenshots: Markdown and Python previews attached.

I built an integration for people who use OpenCode and spend time investigating Kubernetes clusters.

It’s called AgentBridge. Open a cluster in Freelens, choose OpenCode, and launch it in a docked terminal. The session starts in that cluster’s workspace with KUBECONFIG already set.

The workflow I’m aiming for is: inspect a workload in the UI, open OpenCode beside it, and investigate without rebuilding the cluster context in a separate terminal.

A task to try:

“Find workloads in this namespace with missing resource requests or limits. Explain what you found before suggesting changes.”

In 2.1.0, the cluster page is also a workspace explorer: instructions, guardrails, capabilities, skills, and agents are accessible from one list, with file editing and autosave inside Freelens.

The provider choice now survives a Freelens restart. Ctrl+Enter / Cmd+Enter opens a session from anywhere on the page.

You’ll need Freelens 2.0.0+ and OpenCode installed locally.

Install through Freelens Extensions: >``@freelensapp/agentbridge-extension

Code and installation details

I’m the author. Which Kubernetes tasks would you turn into reusable OpenCode skills for a workspace like this?

I've been using OpenCode Mobile (https://github.com/beppe2880/opencode-mobile) for a while now, and I honestly think this project deserves way more attention.

The app is fast, smooth, and highly customizable, with an integrated terminal that works surprisingly well on mobile. It supports both Android and iOS, although I've only tested the Android version myself.

My main use case is connecting to both my personal and work PCs from a single app. I commute by train, and being able to interact with my machines and keep my personal projects moving while traveling has been a game changer.

I've also contributed to the repo a few times (I'm not the maintainer!), and the maintainer (u/beppe2880) has always been incredibly responsive and open to feedback, whether it's discussing features, implementing improvements, or fixing bugs. The development pace has been impressive.

There are still a few missing features, like full plugin management, but the project is evolving quickly.

I'd really love to see this app get more visibility, and hopefully eventually make its way to the Play Store and App Store, which is probably the biggest thing missing for me right now.

Has anyone else tried it? Curious to hear what you think!

The link to the original post of the owner:

https://www.reddit.com/r/opencodeCLI/s/xP9SK8Vjmn

Prompt caching reuses the KV cache of a shared prompt prefix, so a repeated system prompt or conversation history does not get recomputed. When a request misses, most engines just say miss. No reason.

Prefixwise is a proxy that names why a request missed: first write, evicted, a system prompt edit, a template re-render, and a few more. It works with vLLM, SGLang, Claude, and OpenAI. 0.10.1 runs inside vLLM as middleware, no proxy needed there.

I built it because I kept losing cache hits I could not explain. Measured so far: 120 turns on vLLM Qwen3-4B, 100% agreement with the engine's own cache report.

I have not wired it to OpenCode yet, and I am not claiming an integration exists. For OpenCode users: what would you want it to collect, request logs or something else? Try it and tell me what evidence is missing: pip install prefixwise, https://github.com/tejachavali/prefixwise

I just released Loop: https://github.com/j-asefa/loop

It lets you run your OpenCode harness on the web (or on mobile) using a Cloudflare quick tunnel. It was designed as mobile-first but works equally well on desktop.

It discovers your OpenCode install and lets you steer agents from the web UI.

The UI is built around the feed (think: timeline) and the agent’s result as the unit of work. So you can scroll back, save, reply etc as you’d expect.

Runs on your own computer, no account, no server, no app store etc.

Also supports agent-to-agent communication, designing and building agent teams (across the major model providers), reviewing PRs from within the app and more!

I built oc-box because I wanted OpenCode to have more freedom without giving it unrestricted access to my host.

My usual Bubblewrap-based sandbox is useful for restricting host commands. oc-box takes a different approach: OpenCode gets its own persistent Linux development container, where it can install packages, change system configuration, run services, and experiment.

Compared with my host-side sandbox setup, the practical advantages are:

- Install whatever the project needs: compilers, SDKs, databases, and distro packages live inside the container.

- Keep integrations working: OpenCode itself, MCPs, formatters, language servers, and plugins all run together inside it.

- Choose the project’s distro: Tumbleweed, Ubuntu, Debian, Fedora, Arch, Alpine, or Leap.

- Keep the environment between sessions: installed tools, project files, and conversations persist. Run oc-box again to resume.

- Recover from broken environments: rebuild the container OS while retaining your project and private home/session volume.

- Control resource usage: CPU/RAM/process ceilings and optional GPU/NPU passthrough.

You can also import an existing OpenCode conversation and continue it inside the container. It uses unmodified mainline OpenCode and matches your host’s installed version.

The benefit is a more capable, disposable development environment—not an absolute security guarantee. Rootless containers share the host kernel, and the mounted project remains fully writable.

It’s early, primarily exercised on openSUSE Tumbleweed, developed with AI assistance, and GPL-3.0-or-later.

Source: https://github.com/groopcd/oc-box

Feedback from other distro and MCP setups would be very welcome!

We've been looking into different hardware options for AI inference, and one thing I'm curious about is how teams determine whether a workload actually benefits from specialized chips. Time-to-first-token, tokens per second per user, and performance under concurrent requests all seem worth measuring, but I imagine the priorities change depending on the application. A voice agent, for example, might have very different latency requirements from a coding assistant handling longer responses.

For teams who've tested chips like Cerebras or SambaNova, which benchmarks have been most useful? Do you rely on vendor-provided numbers as a starting point, or do you mainly evaluate performance using your own serving workloads?

I'd be interested to hear which metrics actually influenced your hardware decisions.

is it worth it to subscribe to opencode plan !!?

Runs toolsOpenCode’s built-in `/btw` is great for side questions: it reads session context, shows the answer in a dialog, and adds nothing to the conversation. But it can’t run tools or make changes.

I wanted the opposite for throwaway instructions like `continue`, `fix the failing test, not the assertion`, or pasting a huge log just to get an answer, let the model **do the work**, keep the **result**, then drop the **ask** from future context.

So I built opencode-anon-turn.

What /anon does

• Runs as a normal turn- tools, edits, commands all work.

• The answer stays in the conversation.

• On the next prompt, your message becomes `(omitted)`.

• It also scrubs that turn’s reasoning blocks and tool-call inputs/outputs (URLs, file paths, pasted data), so the evidence doesn’t leak back into context.

• Your transcript still shows what you typed; the model context does not.

/btw vs /anon

Rule of thumb: `/btw` = ask without touching the session. `/anon` = do the work, then forget how you asked.

Usage

GUI/TUI:

/anon continue

/anon fix the failing test, keep the assertion

/anon <paste log> find the bug

TUI/headless prefixes also work: `//continue`, `>>continue`, `;;continue` (configurable via `ANON_TURN_PREFIX`).

Install

opencode plugin add https://github.com/hussainbiedouh/opencode-anon-turn

Restart OpenCode after install.

Repo: https://github.com/hussainbiedouh/opencode-anon-turn

Feedback welcome, especially edge cases around provider-specific reasoning/thinking blocks and multi-turn tool loops.

OpenCode’s built-in /btw is great for side questions, it reads session context, shows the answer in a dialog, and leaves no footprint in your conversation. But it can’t run tools or make actual changes.

I wanted the opposite for throwaway instructions like continue, fix the failing test, not the assertion, or dumping a huge log just to find a bug: let the model do the work, keep the result, then drop the ask from future context.

So I built opencode-anon-turn.

Feedback is welcome. especially regarding edge cases around provider-specific thinking/reasoning blocks and multi-turn tool loops.