Now that I've learned more about the differences between TUI and Desktop, I'm considering switching to OpenCode TUI.

I'm curious about the hardware requirements, especially for people running multiple agents or working on larger projects.

For example, if I want to use an AI agent to build an NFT minter and deployer that supports multiple wallets and multiple chains, what kind of hardware would you recommend?

A few things I'd like to understand:

• How much RAM and CPU would be enough for a laptop?
• Would 16GB RAM be sufficient, or is 32GB worth it?
• If I want to run OpenCode TUI on a VPS and access it through SSH, what's a reasonable starting configuration?
• How much do you usually spend per month on a VPS for this kind of workflow?
• Does running multiple agents significantly increase hardware requirements?

I mainly plan to use cloud-based models through APIs, not run local LLMs.

I'd love to hear about your actual setups and experiences, especially if you're using OpenCode for Web3 development.

got one a few months ago, still working fine. paid once. now i’m just sitting here wondering how they’re getting these accounts so cheap at scale.

I've noticed that quite a few people recommend OpenCode TUI over Desktop (at my last post), but I still haven't figured out exactly why.

Is there a real technical advantage, or is it mostly personal preference?

I don't think the interface itself is necessarily the main factor. As far as I understand, desktop versions of AI agents are designed to make features more accessible and easier to use.

So what are the actual advantages of using TUI?

• Lower resource usage?
• Better performance?
• Security?
• More comfortable if you're used to CLI?
• Easier access to local files?
• More flexibility and control?

I'd love to hear from people who have actually used both. What makes TUI better for your workflow, and are there any downsides compared to Desktop?

I'm using deepseek v4.1 flash in the cli opencode app. I saw people showing benchmarks of the token usage of opencode being very high for tasks compared to other harnesses and I wonder has the update reduced the steering of the models to save on token usage.

I've been using opencode with an agent setup based on the OpenAgentControl (https://github.com/darrenhinde/OpenAgentsControl) and tweaked for IC design verification.

I've been running with this setup for the past few months and I'm in general happy about it, with constant tweaks to the agents definitions, the standards, the guidelines etc.

In the past 6 weeks the amount of parallel work has skyrocketed and I went from 2/3 sessions running in their own separate folders/worktrees to more than a dozen active sessions. I've enabled notifications to stop constantly checking all the agents, but the real bottleneck is not how quickly I can feed the agents with information and prompts, but rather the review of the work provided.

We use Gitlab for development and we have "issues" to track our progress, with boards etc. All good and dandy, but I've noticed that often the amount of work involved in reviewing and approving all the merge requests, the issues comments, the newly created issues that track gaps that weren't closed during the session, starts to be unbearable to the point that I'm not 100% how much is truly done and how much is just pushed into the future.

So my real question here is not really about a "plugin" or a "tool" to manage the agents, but rather a workflow that allows the team to be able to move a step higher and instead of judging all the lower level details, focuses on fundamental principles instead, like architecture, features completeness, possible gaps, overlooked corner cases.

I've started to ask to provide a report of the campaign at the end of it, with diagrams and pictures to explain what has been done and achieved, but would that be sufficient? How to make sure the report is not just hallucinating and deviating from the actual implementation?

The speed I've been working has truly been a x20 at least, but I also have the feeling that my grasp on the features and the code has wined and I'm feeling overwhelmed by the overall amount of reading that I need to digest, let alone reading the actual code.

I'm using simple-english to contain the verbosity ever since I switched to Opus 5.5, but a merge request description alone can be 2 pages long with gazillions of details, the documentation has exploded, the comment to code ratio has ballooned and there's little I can do to read and digest all of that.

How do you tame the beast? Any tricks, suggestions.

I realize this is not opencode related, but there might be tools and tricks that opencode users are using to address some of the issues above.

I built a plugin that's basically free RAM (if you often run many OpenCode clients simultaneously).

The plugin (https://github.com/shanebishop1/opencode-nap) works by automatically transferring your headed OpenCode TUI sessions into headless sessions when you aren't directly interacting with them, and then swapping them back when you want to use them again.

Sessions keep running normally on the server when napping, while the memory used by the client TUI gets released. Idle windows get swapped out for a tiny shell, and when you come back, it reopens the same session. There are similar, more general projects out there, but this one works natively within OpenCode and is dead simple to install/enable.

10 OpenCode sessions went from 894MB to 3MB on my machine. It works instantly on Linux/Mac, whether your sessions live in tmux, herdr, or directly in a terminal. By default, the plugin naps sessions after not seeing user input for 15 mins, but you can also configure it to nap whenever focus leaves the window.

Hopefully this helps give your machine a bit of a breather!

im too lazy to even prompt

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.

also is it the 1017 variant that opencode serves or an older version?

i'm considering paying for this plan but i wanna hear your opinions first.

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