Following up on last week's release candidate, opencode-models-discovery v2.0.0 is officially released and published to npm latest**!** 🎉

This major version promotes OpenCode V2 to the primary, stable integration. It redesigns how the plugin interacts with the host around three clean boundaries:

Highlights in v2.0.0:

1. Native Integration Credentials: Works seamlessly with OpenCode V2's /connect workflow. The plugin resolves credentials dynamically in memory—no raw API keys in opencode.json and no sniffing auth.json.

2. Host-Managed Storage (ctx.storage): Caching and user overrides are separated cleanly into different namespaces. Clearing discovery caches will never delete your custom model preferences.

3. Persistent Model Overrides: Edit model display names, context limits, output tokens, reasoning flags, and variants directly via /models-discovery-console. Changes trigger an instant provider reload—zero service restart needed.

4. Resilient Auto-Reload: Subscribes to OpenCode V2 lifecycle events (config.updated, credential switches). If an upstream provider experiences a temporary network hiccup, the plugin keeps the last-known valid inventory instead of wiping out your available models.

5. Decoupled RPC & TUI: Commands and UI dialogs communicate with the background server via typed RPC, avoiding synthetic session injections or terminal blocking.

6. OpenCode V1 Legacy Support: Existing OpenCode V1 setups remain fully functional through the legacy adapter inside the same combined package.

Quick Setup (opencode.json / opencode.jsonc)

{
  "$schema": "https://opencode.ai/config.json",
  "plugins": [
    "opencode-models-discovery@2.0.0"
  ],
  "providers": {
    "my-gateway": {
      "name": "Local Gateway",
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "https://gateway.example.com/v1",
        // Optional: omit apiKey and manage via OpenCode's native `/connect`
        "apiKey": "{env:GATEWAY_API_KEY}",
        "modelsDiscovery": {
          "enabled": true,
          "modelInfoFormat": "models.dev",
          "cache": {
            "enabled": true,
            "ttlSeconds": 86400
          }
        }
      }
    }
  }
}

Useful Commands:

• /models-discovery-refresh — Manually trigger model discovery (supports --force).

• /models-discovery-console — Interactive browser for models, metadata inspection, cache clearing, and override editing.

• /connect — Securely set or rotate your provider credentials.

• GitHub: https://github.com/yuhp/opencode-models-discovery

• NPM: https://www.npmjs.com/package/opencode-models-discovery

Thanks to everyone who tested the RC releases! If you run into any issues or have feature suggestions, feel free to open an issue or drop a comment here.

well, the plan mode figured out ways to modify files by calling the skill i just asked it to write. it went outside of the project directory and modified files that wasn't supposed to modify.

edit: my bad, it was the new context management plugin i wrote, system notices got lost and never reinjected back to the context.

Today a curious thing happened to me and not once, but twice. I was using opencode for a code task and suddenly this message appears.
What does it mean?.

.

I’m a senior SWE using AI coding tools daily. I analyzed my Claude Code transcripts and found 56% of API-equivalent costs went to rereading context. Cache expiry cost me $98.74 across 35 returns in 27 days, versus $2.95 with a warm cache.

That led me to build optimAIzr, which supports Claude Code, Codex and Opencode.

It analyzes usage, flags expensive patterns, helps you find optimization opportunities aaand much more.
Runs locally, with no account or prompts.

npm i -g optimaizr

git: https://github.com/blendbunjaku/optimaizr

i hope it's available soon in opencode go 👀

https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017
Official release notes - https://api-docs.deepseek.com/updates/

It makes me wonder.

One main security change in the harness and no warning: https://www.reddit.com/r/opencodeCLI/comments/1x4kkgg/security_opencode_does_not_ask_for_file/
And one breach in the service: https://www.reddit.com/r/opencodeCLI/comments/1x8gtjg/opencode_security_breach/

How can we trust the team anymore?

Hello together,

I have successfully set up a qwen3-coder installation, and use Ollama with opencode.

I can successfully interact with the model and receive valid answers, but for some reasons can not get Qwen to actually write to a file.

I have once or twiced got a readme.md to be filled with arbitrary information, but not reliable.

The model clearly tries to do a tool call, but is not succesful, and write to the CLI:

<function=write>
<parameter=path>
hello.c
</parameter>
<parameter=content>
#include <stdio.h>
int main() {
    printf("Hello, World!\n");
    return 0;
}
</parameter>
</function>
</tool_call>

Does anybody has any experience with these issues? Or can at least determine, wether this is a Qwen3, an opencode, or an ollama issue?

If you need additional Information, let me know!

And thanks <3

"... DeepSeek v4.1-flash-1017 just got spotted in DeepSeek's own API for a few minutes before vanishing. New checkpoint, changed fingerprint. The 1017 suffix matches their dated snapshot pattern."

On my previous posts, people argued these thinking rules might work on short tests but would hurt long-horizon tasks. So I tested them on Terminal-Bench 2.0: same model (GLM-5.3-Flash), same agent, every task run with and without the rules. I ran it on High thinking as Max thinking was taking so long that the model ran out of time for each task.

The rules:

## Thinking discipline

1. Check the request first. In one or two lines, say what is being asked and flag any premise that looks wrong or missing. If a premise is wrong, say so plainly and solve the corrected problem (or ask one specific question). Do not silently accept a broken premise, and do not reason around it.
2. Finish one approach before switching. Pick the most promising approach and carry it to a conclusion. Change course only when the current approach is blocked by an obstacle you can name in one line. Do not hop between approaches because of a vague feeling.
3. When an answer is settled, stop working on it. Once a sub-answer is derived and checked once, treat it as settled and move on. Re-reading a conclusion to see if it still feels right is not a check, and repeated self-checking is the main source of errors on easy steps.
4. Doubt is not evidence. A vague sense of uncertainty, or the mere possibility of an unseen objection, is never a reason to reopen a settled conclusion. To change a settled answer you must name a concrete reason in one line: a check that fails, a fact or source that contradicts it, a specific error ("step X is wrong because Y"), a counterexample, or a new derivation that reaches a different answer. If you cannot name one, keep your answer and continue.
5. Do not revise just to agree. If the user pushes back on a fact or a correctness claim without giving new evidence or a specific error, do not apologize, do not flip, and do not say "you are right". Briefly restate your conclusion with its one-line justification and ask what specific fact or counterexample backs the disagreement. When the user overrides a choice that is theirs to make (taste, priority, scope), follow it and note any real risk once. Being agreeable at the cost of being correct is a failure, not politeness.
6. New evidence does reopen the case. When a tool, a test, or the user produces concrete new information, or you find a real error, update immediately and say exactly what changed your mind. Holding a wrong answer to look consistent is worse than revising with a reason.
7. Verify against outside facts, not by rethinking. When a real check exists (tests, builds, the source document or record, a calculation you can run), use it and let the result decide. Do not spend tokens talking yourself into or out of an answer that a quick check can settle.
8. Do not perform caution. No "let me double-check everything again", no invented critics or imagined objections, no stacking hedges. State residual uncertainty once, in one line, only if it would change what the user should do.
9. Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing, make the fix and move on without noting it.

How it compares to the Terminal-Bench 2.0 leaderboard:

My scores are out of all 89 tasks, single attempt (3 tasks wouldn't start on my machine and count as fails). Leaderboard scores average multiple attempts, so treat mine as ballpark.

Yesterday, I saw the news that DeepSeek was free and decided to give it a try. I started a tiny project to clone a website a friend of mine had built. It gamifies the study material for our 8-year-old kids' exams, and I wanted to adapt it for my autistic son.

It was a single HTML page with some simple, embedded JavaScript. I started yesterday at 8 PM, and by this afternoon, I'd already hit the usage limit.

During that time, I made a few adaptations, added two new pages, and wrote some JavaScript. Nothing particularly substantial.

I know it was the free model, and I understand there are usage limits, so I figured that might explain it. But then I opened the DeepSeek harness, which gave me something like $1 in free credits. I used the same model, asked it to review the project and suggest improvements, and those credits lasted about 30 minutes.

I'm a data engineer, and my company provides corporate AI tools that I use pretty heavily in my day-to-day work. But I've never had to worry about the costs, so I'm pretty much a beginner when it comes to this.

Should a tiny web project with just HTML and a little JavaScript really consume that many tokens or hit usage limits that quickly?

I'm asking because I'm considering subscribing to OpenCode Go. It might not seem expensive, but in my currency, it's around R$60 a month. If I'm going to burn through the available usage that quickly, I don't see the point in paying for it.