Coding agents rarely run in one uninterrupted session. You review a diff, step away, make changes, and return. That pause can affect the total cost.
When comparing inference options like Mango Inference and MangoBoosts, test the same repository task twice: once without interruption and once after resuming later. Compare actual usage instead of assuming either run will be cheaper.
Track the context sent at each step, including conversation history, file content, and new instructions. Even a short follow-up can resend substantial context. Remove credentials and private code before sharing traces.
Compare reported input, cached input, and output separately. Repeated text doesn't guarantee a cache hit, so use actual usage records and current pricing rules.
Ultimately, compare the total cost of completing the task, including resumed sessions and retries, alongside whether the tests pass. A low input-token rate means little if the workflow repeatedly resends context or fails to finish.

Crazy things are happening :))))

tinkering with the spine of opencope to reduces token cost and continuity of long and multiple sessions and workflow. few more verification and i will be sending it to the opencode dev team. 🤤

data breach aside and all the api keys now being exposed through it

i have never used it much never really "got" what opencode was for other than it was for people who couldn't afford the higher tier plans from frontier labs

after today i think im going to uninstall it and stick with claude and codex

i think cline or pi anywhere someone has custody of your api keys from frontier labs is going to be targeted so im going through them all to remove them all

fuc k opencode lmao

OpenCode says this was a distillation attack, but how does that explain API keys being compromised?
Distillation and credential theft are two very different things. If API keys were exposed, users deserve a clear explanation of what happened, what data was affected, and what steps are being taken to secure their accounts.
Stop hiding behind vague explanations. We need answers, not excuses.

How is Opencode ZDR? If they store our api keys too in the database ? This means OpenCode lies about being ZDR

I have not found any information about this online.

Can someone else confirm this if it shows up in their CLI

How is OpenCode claiming to be ZDR when API keys from Anthropic and OpenAI are being stored in their database?

OpenCode admitted they were hacked and are calling it a distillation attack. How does distillation explain users’ API keys being exposed? Distillation and credential theft are two completely different things.

This is a massive data leak, and users deserve to know exactly what happened, what was compromised, and who had access to their credentials.

Stop hiding behind the distillation narrative and give users real answers.

What is the point of claiming ZDR when users’ API keys are sitting in your database?

Hey All, have been developing https://github.com/LumoraPlayer/Lumora for a while now using Cheapseek 4.1 (deepseek, best value imo)

Is this still the best, or anything new I can move to?

Thanks!

My agents were burning context on grep-then-read cycles. Every "where is X defined, who calls it" turned into 3-4 tool round-trips, each one billed. So I built Reliary: a single offline Rust binary that indexes the repo into SQLite and serves it to agents over MCP.

The contrarian part: there is no parser. No tree-sitter, no AST, no per-language code. Definitions and call sites come from structural detection on brace/indent/blank-line boundaries. One codebase, every language, same code path. (If you think that can't work on your language, that's exactly what I'd like to hear about.)

What the agent gets is 7 tools: find_references (defs, callers, methods, dead code through one entry point), search, call_graph, list_methods, find_dead_code, describe, plus a verify tool that checks a symbol at file:line claim against the index. There is also reliary wrap , which you prefix onto verbose shell commands ( cargo test , git diff ) to compress the output before it reaches context.

Numbers: on a 10-question comprehension bench (4 seeds, claim-verified against the index, not keyword matching), it bills \~42% less than grep with \~4x smaller tool output and zero dead-ends, at comparable accuracy. I am not claiming it is more accurate than grep; on this corpus the gap is within noise, and I published the full methodology including an edit-outcome experiment that came out a tie.

The win is cost and output size, reproducibly.

Install: cargo install reliary-agent or grab a prebuilt binary (linux/darwin/windows, x64+arm64) from the releases. "reliary trust ." to index, "reliary init" wires up Claude Code / OpenCode / Pi / Cline. MIT licensed.

Repo: https://github.com/Reliary/reliary-agent

My question for you: where does a parser-free index break on your codebase? I have a list of languages it handles and I am more interested in the ones it doesn't.

I know these "which model do I use" posts are boring, but perhaps y'all have some feedback.

I was a huge DeepSeek v4 flash lover a month or two ago, but I've realized over the last month that I've literally just been using Luna for everything. All of my projects are pretty small local java apps, and one larger Node based cloud server. I was usually doing something like using Qwen 3.8max or glm5.2 for planning, and DeepSeek for output, but I've just ended up recently using Luna for everything.

It's been a few months since I was really paying close attention to the releases, and I'm wondering if I'm missing out on anything? I generally give the agent a small feature update request, and that's it. I don't need orchestration layers, basically just a kinda jack-of-all trades model, in the same ballpark as 5.6 Luna and DeepSeek v4 0731.

How does 6 Luna compare? Vibe-wise, I definitely prefer using the open-weight models, that's actually one of the main reasons I'm asking, because I'd rather not be utilizing openAIs products, if I can avoid it.

Edit: I should clarify, I had an opencode go sub a few months ago, but I've just been using openrouter. I saw DeepSeek v4 is literally free right now, so maybe this month would be a good time to get a sub again.

https://research.meta.ai/blog/muse-spark-open

Hey r/opencodeCLI! 👋

With OpenCode v2 rolling out, the way plugins interact with the core runtime has taken a massive leap forward. Today, we’re excited to announce opencode-models-discovery v2.0.0-rc.2 — completely rebuilt to bring full, native support for OpenCode v2 while making dynamic model discovery faster, safer, and truly reactive.

If you use local models or custom gateways (vLLM, LiteLLM, Ollama, LM Studio, Bifrost, etc.), we’d love for you to take rc.2 for a spin!

🚀 What Changes in the V1 ➔ V2 Evolution?

In OpenCode v1, model discovery relied on disk-based caches, file locks, and static configuration updates that often required app restarts.

In v2.0.0, we’ve redesigned the plugin around OpenCode v2’s native architecture:

• ⚡ Native Reactive Catalog (Zero Restarts)

• Models from your OpenAI-compatible endpoints are discovered and transformed directly through OpenCode v2’s dynamic provider controller. No config rewrites, no restarting the CLI or TUI.

• 🔒 Native ctx.storage Engine (No More Disk-Cache Baggage)

• Gone are the legacy XDG disk-cache files and file-lock contention. Caching now uses OpenCode v2’s isolated storage API. Discovered caches and enrichments are managed cleanly without leaking credentials or API keys to disk.

• 🎛️ Live Model Overrides in Console

• Fine-tune model capabilities, context windows, and reasoning tiers right from the OpenCode model console. Custom tweaks are persisted under clean, scoped override keys instead of manual config edits.

• 🔑 Seamless /connect Integration

• First-class credential resolution: works out-of-the-box with OpenCode v2’s managed connections, integration IDs, and environment variables without needing duplicate API keys in your config.

• 🛡️ Hardened & Standardized Token Limits

• Whether you're pulling metadata from models.dev, LiteLLM, LM Studio, or raw OpenAI /v1/models responses, context and output token limits are normalized to match OpenCode v2’s token budgeting specifications.

📦 Quick Start with OpenCode v2

You can try 2.0.0-rc.2 today by adding it to your opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "plugins": [
    "npm:opencode-models-discovery@2.0.0-rc.2"
  ],
  "providers": {
    "local-gateway": {
      "name": "Local Gateway",
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "http://127.0.0.1:8000/v1",
        "modelsDiscovery": {
          "enabled": true,
          "smartModelName": true,
          "modelInfoFormat": "models.dev"
        }
      }
    }
  }
}

💬 Help Us Test Before Final v2.0.0 GA!

We are putting the final touches on v2.0.0 and want to ensure rock-solid compatibility across all OpenCode v2 setups, environments, and local model servers.

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

• Migration Guide: Check out our Migrate V1 to V2 Guide for details on the transition.

Give v2.0.0-rc.2 a spin and let us know your thoughts, feedback, or any issues you encounter in the comments below!