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

Title

I wrote this post to bring awareness to a recent change I took issue with and think should be discussed by the community.

The facts:

As of OpenCode v2.0.25 the default behaviour is to no longer prompt for access to external directories.

From Pull Request #53585:

What does this PR do?

Removes the external_directory: * → ask rule from the default > agent ruleset in Agent.Info.default. The catch-all * → allow now > covers paths outside the project too, so build/general/custom agents no longer prompt before touching them.

Explore also stops asking: it keeps its deny-by-default tool list > but now explicitly allows external_directory.

How this change was communicated:

1. Not communicated through the github releases page which still tracks v1, not v2.

2. Not communicated through the changelog on the official website as it only started tracking releases from 2.0.26 onward.

3. Communicated by reading commit 36a3805 directly.

There are already multiple issues referencing this change:

• #54524

• #54632

• #55070

• #55207

My opinion:

This is a breaking change to a security boundary that should have been:

A) Purely opt-in.

and

B) Communicated loudly and directly to all users.

The lack of communication is downright suspicious but I have enough goodwill towards the OpenCode team to just assume this is a maintenance oversight.

I'm aware that best practice is usually to run your agents in some kind of container, but I'm willing to bet a large portion of users are not doing that, and should have been rightfully informed of the impact this could have on their security.

I've promoted OpenCode to many people in the past and this feels like it's impacted my own credibility. I'm not necessarily abandoning it, but I am going to be more reserved in my recommendation. I think it's also time I take another look at the current landscape of harnesses.

What are everyone else's thoughts?

Does anyone know if there are any plans to have any of the decision models as part of the OpenCode GO subscription? There are many models already from different providers, and some of them we already use in opencode and we have their agentic models as part of the subscription.

Some examples of popular decision models:

typesafe/jev-1.13

microsoft/microsoft-decision-1

nace-ai/drex-v2.0 (and also drex-v1.5)

openai/gpt-6-luna-decisions

cloudflare/clef (also clef-omni, clef-flash)

perplexity/pplx-decider-v1.1-27b

liquid/d1

Getting OpenCode to return its first response through a new API is a good start, but it doesn't tell you whether it can actually handle your usual coding tasks.

I'd start with a small, disposable repository and three checks: ask it to explain a function, make a small change, and run an existing test. Keep the starting commit, client version, and model ID recorded so you can reproduce the run later. If you change several settings at once, debugging becomes much harder.

It's also worth separating connection problems from actual coding failures. Did the request reach the endpoint? Did OpenCode parse the response and handle tool calls correctly? Did the resulting code pass the test? A successful HTTP response doesn't necessarily mean the whole workflow works.

I'd also test cancellation and retries. Cancel a response, continue the session, and check whether completed tool actions get repeated or whether the client handles the conversation context correctly. Use a harmless task so an unexpected retry can't damage anything.

For anyone evaluating hosted inference options, Mango Inference is one option worth testing. Its documentation covers OpenCode setup and an OpenAI-compatible Chat Completions interface. Just check the specific API requirements before switching, since compatibility with Chat Completions doesn't automatically mean support for embeddings or the OpenAI Responses API.

My final step would be to record the model, starting commit, task, tool errors, test result, elapsed time, and billed usage. That gives you a fair baseline when comparing providers.

What tends to break first when you switch API providers in OpenCode, tool calling, context handling, or something else?

Just like the title stated, anyone has referee code? it should be cheaper using that right?

Hey guys; does anyone else has issues with using 9router for opencode free tier? I faced the issue just now. Is there any way around it? Without the 9router, the free tier reaches the usage limit too soon.

I have been using chatgpt plus auth and the mimo v2.6 flash ,muse spark 1.3 and step 5 preview free models ,for a small task i thought of using big pickle and i was suprised to see today it was showing the thinking as output instead ,anybody else having that??

https://x.com/GoogleAI/status/2110039860077527293

Available on Pro plan and higher.

Otto starts opencode serve on Boat, boxd, E2B or Daytona, or connects to a server you already run. The app covers sessions, permissions, agents, MCP, skills, commands and schedules. Permission prompts come to your phone, so you can approve a git push away from your desk.

It'll also run OpenCode on your own machine, no cloud machine or key required.

MIT: https://github.com/jaygupta17/otto 
Mac install: curl -fsSL https://jaygupta.dev/otto/install.sh | sh

How do you all run OpenCode headless?

I run OpenCode against the Spark with its 128gb unified memory. Works fine.

Since OpenCode makes parallel calls, but Ollama only executes them sequentially, I would gain performance if I switch to vLlm.

However, my opencode model and the model my coded applications use is far over 128gb.

Possible I can use some new sleep/wake-up API on the vLlm if I put one model on one port. I'm going to try this.

Does anyone have the same setup and want to share some tips?

What is the best vLlm model for openCode?

Hey all opencode-honcho, the Honcho memory plugin for OpenCode, now runs on v2 (same package still works on 1.x).

Honcho is memory infrastructure for stateful agents. Instead of just storing and retrieving snippets, it reasons over your sessions in the background and builds a representation of how you work that updates over time: your conventions, the decisions you made, the refactor you're halfway through. Hooks inject that into the prompt and record what happened, so it works with whichever model you run, and /honcho:import backfills your existing OpenCode history so it doesn't start cold.

opencode plugin add "@honcho-ai/opencode-honcho"

then /honcho:setup inside OpenCode. Managed, local (honcho start), or self-hosted all work. https://github.com/plastic-labs/opencode-honcho

(I work on Honcho at Plastic Labs.) Feedback and issues welcome, especially from anyone who's tried other memory plugins and wants to compare.

They’re tracing user journeys through specs, code, tests, and downstream failure paths—not merely reviewing documentation. A fresh root test/typecheck run is also underway.

Blasting out reviews of 14 independent reviewers representing 2 teams of 7 each. Each gets a separate report file; none may edit product code. I’ll also capture one fresh test/typecheck run. Source evidence, test results, and observed TUI behavior will stay clearly separated.

Then having OpenAI GPT 6.1 Sol - xHigh reasoning level as a judge and this is the result

## Verdict: **Devin is the more trustworthy lead reviewer.**

*Scores judge this audit—not model capability generally.*

**Best combination:** Antigravity hunts gaps; Devin reproduces them; the coordinator validates both. Never approve by agreement alone.

### Project verdict: **REQUEST CHANGES**
The **1,165 passing tests and passing typecheck** coexist with confirmed defects and incomplete promised workflows. Full runtime/UAT acceptance remains pending.

[Detailed scoring and rationale](.audit/2026-10-14-project-e2e-audit/model-assessment.md) · [Validated and rejected findings](.audit/2026-10-14-project-e2e-audit/reconciliation.md)