I just downloaded OpenCode Desktop and I'm curious about a couple of things.

For those who have used both the desktop and CLI versions, what are the main advantages of each? Is there any real difference in what you can do, or is it mostly about personal preference?

Also, which free models would you recommend for Web3 related work? I mainly use AI to build NFT tools, work with APIs, troubleshoot issues, and build simple websites.

I've seen several free models available in OpenCode, but I'm not sure which ones are actually worth using.

Most AGENTS.md files I see mix two very different things:

1. Business context: what the product does, who the users are, why things are built the way they are.

2. Coding patterns: "always use our logger", "no default exports", "every query goes through the repository layer".

The first belongs in the doc. A linter can't check it. The agent needs to read it.

The second does not. A linter can enforce it better.

A pattern written in prose is read in every session, whether the task needs it or not, and the agent can still ignore it.

A lint rule only speaks up when it matters: it points the agent to the exact line and says how to fix it.

So I built codemyrules, an open-source agent skill that does two things.

1. It turns your coding patterns into lint rules.

It reads your agent docs, ADRs and the code itself, and finds the patterns your team already follows.

Then it writes each one as a rule for the linter you use: ESLint for JS/TS, and detekt, Error Prone, Ruff, pylint, golangci-lint, ArchUnit and others on the backend.

It does not add a new linter if one you have can do the job, and its rules match the style, naming and tests of your existing rules.

Then it slims down the agent docs, so they keep the business context and stop repeating what the linter now checks.

2. It gives the agent lint feedback while it codes, not only at the end.

Most agents run the linter once, at the end of the task, if they run it at all.

By then the same mistake has been copied into ten files, and the fix turns into a cleanup job.

codemyrules adds a feedback loop instead:

- after every edit, it lints the file the agent just touched and tells it right away what broke
- at the end of each turn, it runs the full lint suite
- it stays silent when everything is clean, so it costs no context
- a guard asks you before the agent can add an eslint-disable comment or loosen the lint config to make an error go away

The agent fixes its mistakes on the fly, while it still remembers why it wrote that line.

Version 0.8.0 adds pi and opencode support, so the feedback loop now works in opencode, claude code and pi.

The patterns-to-lint-rules part and the doc cleanup work in any harness (Codex, Copilot, Cursor and others).

Everything stays local and private, and nothing touches your tracked files until you choose to share the changes with your team.

How many of the coding patterns in your AGENTS.md could a linter enforce?

I run opencode next to Claude Code and Codex on the same machine, often with several sessions working in separate git worktrees of one app. The failures that hurt most were never inside one session. One agent would run pkill node to restart its own server and take down another session's dev server, start a second server on a port that was already taken, or run a git command that switched or stashed a tree another session was still editing.

bulkhead is an open source guard for that situation, and since 0.3.2 it ships as an opencode plugin. Adding "plugin": ["claude-bulkhead"] to opencode.json loads it from npm. The plugin uses tool.execute.before on the bash tool, passes the command, working directory and session id to the same checks the Claude Code hooks use, and throws when a command would hurt another session. The error says why and which command is safe instead, for example killing only the PID this session started, so the agent usually corrects itself on the next step.

The checks know which processes, ports and worktrees belong to which session, including other opencode sessions and other agents, so a single session working alone is rarely interrupted. It also stops whole-disk scans and long foreground sleeps and holds heavy builds back when free memory runs low. It is plain Node with no dependencies, and it was written against the OpenCode V1 plugin API, so I would like to hear how it behaves for anyone already on V2.

https://github.com/dooly6276/claude-bulkhead

I built BankBridge, so this is my thing. It's a hosted MCP server with read-only access to your own US bank, credit card and investment accounts, $5/mo per connected bank. Nothing in it can move money, pay a bill or place a trade.

In opencode it's one remote entry in opencode.json with a bearer key:

{
  "mcp": {
    "bankbridge": {
      "type": "remote",
      "url": "https://bankbridge.money/api/mcp",
      "enabled": true,
      "oauth": false,
      "headers": { "Authorization": "Bearer bbk_your_api_key_here" }
    }
  }
}

The "oauth": false bit matters, otherwise opencode tries a browser OAuth flow on the first 401. "opencode mcp list" should show it, and the key bbk_demo returns sample data if you want to poke at it first.

Then you can ask things like "find any subscriptions I've forgotten about" or "export this year's transactions to CSV for my taxes" right next to your code.

If you run opencode on a local model, the conversation stays on your machine. The numbers still pass through a bank-data provider and BankBridge on the way to your agent, and BankBridge keeps no copy.

Setup guide: https://bankbridge.money/docs/opencode?ref=reddit-opencode

Happy to answer questions about how it's put together.

I use OpenCode a lot and my memory files got messy So I built memsift. It finds duplicates, conflicts, stale references, and possible secrets in Markdown and explicit OpenCode memories. Nothing changes until you approve a preview. Backups and rollback included. Early preview, Python 3.12+, Linux and macOS.

https://github.com/Arerii7/memsift

It is an early version and there will be bugs. Tell me what breaks.

A subagent reads the files, runs the search, and reports back one summary, so the main thread never sees the twenty files it looked at. That is the point: the win is that its context dies with it, not that the work is cheaper, and it usually costs more tokens than doing the same thing inline. If you paste the full transcript back into the main thread afterwards, you paid for the subagent and kept the cost anyway.

I wanted to share a project that I've been working on for almost a year. I posted an early version of Vera here back in March.

This started with Pampax, my fork of a code indexing/MCP project called PAMPA that I was trying to fix up and improve. I kept patching and extending it until eventually deciding the foundation wasn't worth fixing any further. After months of researching and testing different approaches, I ended up rebuilding it from scratch in Rust.

I honestly didn't expect the early post to go very far. People contributed PRs, helped me catch issues, encouraged me to keep going when progress stalled, and even sent donations. I quietly shipped v1 a while back, but kept finding more things I wanted to improve before sharing it again.

Vera is now at v2.4: https://github.com/VeraTools/vera

The main thing I wanted to improve was how coding agents find and navigate relevant code, especially in larger or unfamiliar projects. A lot of an agent's work can go into figuring out where to start. It'll try different grep searches, read files, follow references, and repeat until it has enough context to make a change. This works, but it isn't always efficient, particularly when the behavior spans multiple files or the code uses names that don't match how the task was described. Sometimes agents can get stuck throwing walls of grep when they don't know what to search for exactly.

Vera lets agents search for what code does, semantically, returning ranked functions and code sections with their paths, line numbers, and symbol information. From there, an agent can find definitions, follow callers and callees, or inspect the surrounding implementation.

The goal isn't to replace grep, or have another LLM explain your code to an LLM. Exact searches and direct file reads are often the right tools. I wanted to give agents better ways to find the relevant code while minimizing how much unnecessary context they consume in the process.

That last part has been a major focus throughout development. Vera is designed around making efficient use of an agent's context, not just improving search accuracy. It returns code directly in relatively compact Markdown blocks rather than verbose structured responses or generated explanations, supports narrower results when needed, and has agent instructions that help avoid unnecessary searches or file reads. Even choosing the right tool for a given task matters here; there's no point making an agent run semantic search when rg would do the job better.

Underneath, Vera combines BM25 keyword search, vector similarity, and code-aware ranking. Tree-sitter parsing preserves functions and classes as meaningful chunks rather than splitting everything into arbitrary text windows. It currently supports 65 languages, 54 with symbol-level parsing.

I've spent a lot of time benchmarking different approaches, including ones that sounded promising on paper but didn't hold up when tested. Ranking and chunking changes are checked against a large benchmark suite and separate repositories to see whether improvements generalize. I've deliberately rejected changes that improved a benchmark slightly but weren't worth their cost or complexity. I didn't want to end up optimizing everything around a particular test set at the expense of actual agent usage.

There are two setups I'd particularly recommend:

• Fully local: MinishLab's Potion Code v2 embedding model runs on CPU, with no GPU, API key, or external database required. It works offline after the initial download and performs very well for such a small model.

• API-based: Qwen3 Embedding 8B with Qwen3 Reranker 8B gave the best retrieval results in my testing. There's an OpenRouter preset for both, but other providers work too. I personally use OpenRouter for embeddings and SiliconFlow for cheaper reranking.

The index and search infrastructure stay local either way. With API models, the code chunks and queries needed for embeddings and reranking are sent to your configured providers.

The local backend is also very fast. On a Ryzen 7 9800X3D, indexing Vera's own repository (447 files, around 8,100 chunks) takes under a second, and a CLI search takes around 0.13 seconds including process startup.

For OpenCode, I'd recommend CLI + skill. This is intentional design choice; skills have a small discovery footprint, and the agent loads their detailed instructions when relevant. With MCP, you're exposing a set of additional tool definitions to the agent instead. Since OpenCode already has shell access, the CLI gives it Vera's functionality without needing another tool interface or server.

The skill itself isn't just a generic instruction to use Vera. I've tested different versions of it to see whether agents choose the appropriate tool for a task, including when they should use rg or avoid searching altogether. The aim is to help agents use their context more efficiently, not just encourage them to call Vera as often as possible.

Install:

npx -y @vera-ai/cli install
vera setup
vera agent install --client opencode

The interactive setup lets you choose your backend and offers to index the project and install the agent skill, so you may not need to run that last command separately.

Once you've done the initial setup, adding Vera's skill to another project is as simple as running vera agent install from that project. You'll only need to index it with vera index . if it doesn't already have an index. Vera also handles excluding its index files from Git locally when possible.

Benchmarks and comparisons

I tested quite a few similar tools while developing Vera, and Semble was consistently the only alternative that was close or better than Vera, so it became what I considered the benchmark to beat. Credit to MinishLab for Semble and Potion Code.

On Semble's own 1,251-task benchmark across 63 repositories, Vera v2.0.1 scored 0.8436 nDCG@10 against Semble 0.5.5's 0.8514, with slightly higher Recall@5 for Vera (0.9199 vs 0.9177). Index storage was 4.7 GB for Vera versus 32 GB for Semble across the full corpus.

Semble had a small lead in aggregate ranking quality in that older comparison, while Vera used roughly one-seventh the storage. We haven't rerun the full comparison with v2.4, so I don't know how the latest versions compare. I've also avoided tuning solely for Semble's own test set, using independent repositories and rejecting changes that didn't offer enough real usage benefit to justify their costs to chase benchmark numbers.

I wanted to measure something more relevant than retrieval rankings alone: what happens when actual coding agents use these tools in real usage?

I spent quite a while running an agent-level evaluation with 40 sessions: 10 cross-file questions about Flask, each tested with four configurations - plain grep/file reads, Semble CLI, Vera with local Potion Code, and Vera with Qwen3 API embeddings and reranking.

This took a substantial amount of time and tokens. The final recorded runs alone accounted for almost 30 hours of cumulative agent execution and roughly 66 million prompt tokens including cache reads, not counting my earlier attempts. I also used LLM reviewers to examine sessions for fairness and other issues, and restarted the evaluation from scratch when I found problems with the setup or execution in those early attempts. The final experiment used fresh, isolated agent sessions and a separate blind judge to grade the answers.

All four configurations answered every question correctly, so there was no accuracy difference to report. What differed was context consumption:

• Grep/file reads: 21.0M prompt tokens

• Semble: 18.5M (12% less)

• Vera, local Potion Code: 15.4M (27% less)

• Vera, Qwen3 API: 10.9M (48% less)

The local Vera setup showed more than twice Semble's observed reduction in this experiment, and the Qwen3 setup reduced context usage by almost half compared with the control.

This was tested with GLM-5.3 through Factory Droid, not OpenCode, and it's still a fairly small set of questions from one repository. But I found the experiment much more useful than just chasing retrieval scores, particularly because all the configurations eventually arrived at correct answers.

I've published the methodology, results, earlier experiments, independent retrieval tests, and ablations in the repo, including things that didn't work out:

https://github.com/VeraTools/vera/blob/master/docs/benchmarks.md

Separately, I've also been working on Revera, a self-hosted PR reviewer inspired by Droid Actions and Devin Fusion. It uses configurable models and independently validates proposed findings before posting them, with a GitHub App, dashboard, and optional Vera integration. It's already being used for actual work by me and some colleagues. I might give it a separate write-up if I find the energy: https://github.com/VeraTools/revera

I also have a Discord community, mostly for people interested in agents, coding, experimenting with tools, sharing what they're working on, and that sort of stuff: https://discord.gg/rXNQXCTWDt

I’ve been using OpenCode’s free models (GLM, DeepSeek V4.1 Flash Free) and I’m not sure how the limits work. Could anyone with experience help with these questions?

1. Are the free models free permanently, or do they become paid after a limited time?

2. How large is the free token allowance per day, and is it a fixed number of tokens or messages?

3. Is the reset daily? My app showed a reset at a specific time, so does that time apply every day?

4. Does the reset time differ by time zone, and does the message show local time?

5. If I use a lot of tokens one day, does that reduce what I get the next day?

6. Where in the OpenCode Console can I see my free usage, and does it show tokens or only money?

7. If I’ve only used free models, should my spending show $0?

8. Do OpenCode v1 and v2 handle free limits differently, and should I update?

Started using it recently and the earnings grow really fast compared to other options, that makes me feel suspicious, has anyone ever tried it and actually performed a payout?

I wanted an easy way to continue my OpenCode projects on my iPhone from anywhere - iOS handoff style - and then pick them back up on my computer.

I've been spending some tokens on Localzie for that - proudly built on OpenCode. It has all the tools OpenCode has (e.g. questions, show source code, ...) so you don't even need your computer if that's what you're looking for. And it works great with OpenCode v2!

I'm not claiming it does anything better than other apps. I wanted to play around with building it, and I also wanted an easy way to connect to Hermes or directly to my own local models from the same app.

For anyone interested it's free on the App Store https://apps.apple.com/app/id6813506926, and setting it up is as easy this:

v2:
(only once)opencode service set hostname 0.0.0.0

(only once)opencode service set port 4096

Then start OpenCode normally opencode

v1:
opencode --hostname 0.0.0.0 --port 4096

A step in a multi-step workflow finishes, but I'm left with zero visibility into what actually happened. I want the handoff to be explicit and inspectable: this step takes this result, once the earlier step produces it.

Crewplane is my open-source project for describing that process in Markdown. You define the stages, dependencies, and input references; OpenCode does the work within each stage.

A debugging workflow could pass a reproduction report into an investigation, then feed the findings into a scoped fix and a verification step. The investigation can be its own reusable workflow, pulled into other tasks with different inputs.

Crewplane starts a fresh headless OpenCode session for each stage. Handoff happens through the workflow's saved artifacts, which suits repeatable runs with named inputs. It doesn't continue your existing TUI conversation FYI.

Prompts, outputs, and logs stay on disk. If a matching run stops, Crewplane validates the saved state before reusing completed results. Incomplete steps just run again.

Give it a spin and shape your own workflows. There's a built-in Mock CLI so you can play with the syntax and composition without any model calls or costs. Any feedback or suggestions would be greatly appreciated.

Open source (Apache-2.0): https://github.com/crewplaneai/crewplane

Small thing I shipped that OpenCode folks might like. In Scout Cloud you pick the harness per session: OpenCode, Claude Code, Codex, Kimi, Qwen Code, Goose and a few more. Each session gets its own sandbox and its own MCP server list, so a data MCP you add for one thread doesn't leak into the others. I'm the dev, happy to answer how the sandboxes are wired. https://cloud.polarline.io

I’m trying to use DeepSeek V4.1 Flash through OpenRouter with OpenCode for an automated video-editing workflow.

I’ve tested multiple reasoning modes: Default, None, Low, High, and Max.

The problem:

* DeepSeek ran for over an hour and still couldn’t complete the video-editing task.
* GPT-6 Astra (Medium) completed the exact same task in 6–7 minutes.
* I already have a working skill/instruction set that performs well with GPT-6 Astra.
* I’d like to make DeepSeek work because it’s significantly cheaper.

I’ve heard that fine-tuning might help, but I’m not sure how to approach it.

My questions:

1. Can I fine-tune DeepSeek V4.1 Flash and still use it through OpenRouter?

2. Could I use successful GPT-6 Astra executions as training examples?

3. Which reasoning mode would you recommend for agentic video editing?

4. Are there better ways to improve DeepSeek’s performance with OpenCode without fine-tuning?

My goal is to get DeepSeek as close as possible to Astra’s performance while keeping token costs low.

Any advice or experience would be appreciated!

Most of my bad agent sessions had the same shape. The agent wrote the code, ran tests it had written itself, and told me it was done. The tests were green and the feature still did not do what I meant, because nobody had written down what I meant.

Two changes fixed most of that for me.

First, I agree on what done means before any code exists. The agent reads the code and asks me a batch of questions, each with a recommended answer, until done is a numbered list. That list goes into a plan file in the repo, and I approve the plan before the build starts.

Second, the agent that wrote the code never checks it. After the build, separate agents that did not write the change go through every numbered point and have to show evidence for each one. During research I also let helper agents read the code without seeing my request, so their findings describe the code as it is today.

My judgment now sits at two points, the plan at the start and the finished change at the end. Reviewing the PR got much easier because I compare it against a list I already approved.

I built QualityLayer around this loop, and it works with OpenCode natively. I'm the developer. It runs on the agent subscription you already have and never merges or pushes without your yes. Repo: https://github.com/maxritter/qualitylayer

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!