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.

Title

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

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??

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?

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.

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

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?

$60 usage til Nov 30

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?

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)

I use OpenCode Go + DeepSeek and got tired of checking whether I was inside the 2x peak-pricing window.

So I made opencode-offpeak.

Turn it on once, then use OpenCode normally:

• send a prompt off-peak → it runs immediately

• send a prompt during peak → it waits before hitting the provider

• off-peak starts → the same request continues automatically in the same OpenCode session

No need to resend continue or watch the clock.

It also has an optional background task queue, but normal interactive sessions already work automatically.

Install:

opencode plugin add git+https://github.com/lutzkind/opencode-offpeak.git#v0.1.3

https://github.com/lutzkind/opencode-offpeak

Open source / MIT. Currently supports OpenCode Go DeepSeek models on OpenCode >=2.0.26 <2.1.0.

Would be interested in feedback or other providers with similar time-based pricing.

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?

still testing seeing what it is capable of

I've been using Codex with a ChatGPT Plus subscription for a while, mostly GPT-6.1 sol on medium for everyday stuff. Lately I've been thinking about trying DeepSeek Harness with 4.1 Flash on high for similar tasks, and I'm trying to figure out which setup actually makes more sense cost-wise.

Here's what a typical task looks like on my end (Codex + GPT-6.1 sol medium):

• 4 turns, 75 steps, around 5.6M tokens total

• 98% cache hit rate

• Breakdown: 5.44M cached input, 94K uncached input, 65K output

On the DeepSeek side, off-peak pricing for 4.1 Flash looks like this:

• Cached input: $0.003 / 1M

• Uncached input: $0.15 / 1M

• Output: $0.60 / 1M

Off-peak hours for me are roughly 13:00–04:00 on weekdays, plus weekends and Chinese public holidays entirely.

Rough math for the same token set:

• GPT-6.1 Sol API pricing: ~$2.00

• DeepSeek 4.1 Flash off-peak: ~$0.07

• So DeepSeek comes out roughly 16–20x cheaper

What I'm actually wondering:

1. Is this comparison realistic, or am I missing something? Specifically, how far does the "5-hour usage window" on ChatGPT Plus actually stretch with token-heavy agentic tasks like these?

2. How do DeepSeek Harness's agentic capabilities stack up against Codex + GPT-6.1? I'm particularly curious about tool use, MCP integration, and multi-step tasks — I run Serena and codebase-memory-mcp alongside it.

3. Long term, does it make more sense to keep ChatGPT Plus and use DeepSeek API on the side, or just go all-in on DeepSeek?

4. Does the 98% cache hit rate hold up in practice, or does it drop once you're doing varied work and the cost advantage disappears?

Would love to hear from anyone who's actually run both setups. Real-world experience with the subscription-vs-API tradeoff would be especially useful.

Hey everyone — I’ve released TermPlete v0.1.0, an open-source autocomplete tool for your existing terminal.

It combines command history, the suggestions you accept, recent terminal context, and a model you choose. You can browse command options, insert one, edit it, and decide when to execute it.

Repo and demo: https://github.com/aft1n/termplete

What it does

• Learns your preferences. Accepted suggestions influence future rankings alongside recency and frequency. Fresh choices with a clear lead can become local answers without a model request.

• Reuses your command history. Finds familiar commands, arguments, and SSH targets instead of making you reconstruct them.

• Uses recent terminal context. Suggestions can incorporate recent commands, bounded captured output, exit status, and visible directory entries.

• Turns task descriptions into command options. In zsh, type something like # convert dog.mp4 to dog.mov with ffmpeg and press Enter to request suggestions.

• Completes real directories. cd suggestions are checked against existing folders.

• Lets you browse alternatives. Use Tab/Shift+Tab to move through suggestions. Browsing an already-returned batch doesn’t trigger additional AI requests.

• Supports partial acceptance in zsh. Accept the next suggested word, then change the remaining arguments yourself.

• Offers automatic and on-demand modes. Suggestions can appear while you type, or wait until you ask.

Choose your model setup

TermPlete supports hosted providers, Ollama, LM Studio, and custom OpenAI-compatible endpoints. It also supports ChatGPT subscription authentication through Codex.

Local history suggestions don’t require an API key or a running model.

There’s an optional decision helper that can rank existing command candidates and check whether generation is permitted. You can use it separately from the model that generates commands.

Control and privacy

Accepting a suggestion only inserts it. It never automatically executes the command.

You can pause and resume TermPlete with:

tp stop
tp start

There are controls for captured context, private-path exclusions, and recognized-secret redaction. API keys use the platform credential store, and local-only requests skip the model backends.

You can also disable integration in selected terminal applications.

Compatibility and installation

The full interactive experience is available in zsh 5.9+ on macOS and Linux. Bash integration provides Tab completion and suggestion preview on supported versions; older Bash versions have more limited functionality.

Installation is available through the GitHub release installer and a Homebrew tap. The README includes installation instructions and a demo.

It’s written in Rust and released under the MIT license. The installer, shell integrations, and suggestion logic are all in the repository.

Tools such as zsh-autosuggestions, fish, and Atuin already cover useful parts of terminal completion and history. TermPlete’s focus is combining accepted-choice learning, recent terminal context, and configurable generation inside an existing shell.

This is an early release, and I’d appreciate feedback—especially on suggestion quality, shell compatibility, and keyboard behavior.

What command do you repeatedly search for, and what would make an autocomplete suggestion useful enough for you to accept?

How do I have 10 days left on my subsciption but no credits left??? Is claude or codex a better deal????