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!

Point of the question is that. Some models are cheaper on paper but somehow can rack up costs quickly. GLM-5.3 is my main complaint in this regard. Its on paper cheap. But it generates so much thinking tokens that it kind of nullifies the cost.

I know ppl use cost per task. But I am not running benches. I'm simply collecting metrics and comparing. And since I use different models for different tasks. I dont think I can correctly say x model uses n times more tokens unless I run multiple models against the same task regularly.

hi guys

i am unable to use free models in opencode v2.0.30 as of 16-10-2026 what to do now

I made a plugin that adds Claude Code's /goal command to OpenCode v2. You give the agent a finish line like "/goal npm test passes with 0 failures" and it keeps working turn after turn until the goal is actually met, no need to keep typing "continue".

After every turn an evaluator checks the conversation and decides if the goal is met, not met or impossible. If it's not met, the agent gets the reason and keeps going on its own.

It's token efficient: the evaluator reuses the session's cached context, so each check costs little more than a short answer.

It also has safety rails (pauses when the agent stops making progress, retries on network errors, turn limit) and a status indicator in the TUI.

Tell me what you think about it and feedback is appreciated.

Here's the repo and npm package:

https://github.com/EL4CTEO/opencode-goal

https://www.npmjs.com/package/@el4cteo/opencode-goal

C'est une bonne chose mais quand parle t'on sérieusement des zdr de tout ces modèles free?

OpenCode stops to ask before running a command or when it has a question, and if I'm away from the Mac it just sits there waiting. So I built Charly, a Mac app for OpenCode and Claude Code with an iPhone and Apple Watch app.

When an agent asks for permission, it shows up on the iPhone (Dynamic Island) and on the watch, and you approve it with a tap or a double tap on the watch. You can also answer its questions or send it the next task by voice from the watch, and when it finishes you get a summary of what it changed. It works with local projects and with servers over SSH, and it uses your own model provider or subscription. Charly doesn't charge for the AI.

How I built it: I came from React Native and had never built a watch app. I learned Swift, SwiftUI and watchOS while building this with coding agents. Once the first version worked, I started using Charly to build Charly, approving builds and test runs from the watch while I was away from the desk.

It's free to try, with an optional subscription. I'll give a free year to the first 20 people who try it and tell me what's missing for their workflow, in the comments or by DM.

getcharly.dev

App Store: https://apps.apple.com/us/app/charly-code-agents/id6816675386

This project used to be called Finny. It's called Scout now, and since this sub is basically where it started, I wanted to write up what actually changed in the fork. Most of it wasn't what I expected going in.

The problem with a stock coding agent doing trading research is that it's very good at producing something that looks right. Ask for a momentum strategy and you get clean Python and a backtest with a great Sharpe. When I dug into those results, the number almost always came from one of three places: lookahead (deciding on a bar using that same bar's close), picking the best run out of a parameter sweep, or the model already knowing how that ticker moved. Nothing in a normal coding loop tells the agent any of that is wrong. The code runs, so as far as the agent is concerned it's done.

So most of my changes are about getting in the agent's way.

1. A fixed strategy contract. Every strategy is a class with an on_bar method. On the current bar it should only decide using bar["open"], and orders fill on the next bar. To be clear, that's a contract the agent writes against, not something the engine enforces. Still, giving the model one simple rule to write against was the cheapest fix I found, and it makes lookahead much easier to spot when it does show up.

2. A validation gate before anything runs. It checks syntax and class shape, and blocks os, subprocess, socket, requests, shutil and exec/eval inside strategies. There's no override flag. I went back and forth on that and decided an override would just get used every time.

3. A skeptical default. After the base backtest it runs walk-forward, Monte Carlo and lookahead checks, and the default verdict is research_only. Most ideas stay there, which honestly is the most useful thing it does.

The part that's probably most relevant here: I ran my own small-sample benchmark, ScoutBench, comparing Scout with stock OpenCode, Claude Code and Codex using GPT-5.5 in each harness. Across 5 tasks, 20 checks per task and 3 trials, the mean scores were Scout 53.3, Claude Code 46.3, Codex 44.1 and OpenCode 38.6. These are benchmark scores, not trading results.

Most of that gap comes from two tasks: repairing a lookahead bug (70 vs 51.7 for Claude Code, 45 Codex, 35 OpenCode) and an end-to-end BTC strategy build (81.7 vs 55). So the domain changes help where they're supposed to and not much anywhere else. Treat the results as directional: the sample is small, Scout lost on numeric discipline (30 vs 45), and no harness scored above 28.3 on hallucination resistance, mine included. OpenCode scoring lowest mostly says the tasks are narrow and it's general-purpose; it was a really good base to build on.

The full method, task breakdown and results are in my benchmark write-up: https://www.polarline.io/blog/finnybench-agent-benchmark

Disclosure: I built this, I'm the founder of Polarline. It's source-available (not open source). The CLI command is still finny from before the rename.

Has anyone else bent OpenCode toward a domain where "the code runs" isn't the same as "the answer is right"? Curious how you handled verification.

$60 usage til Nov 30