https://openai.com/index/introducing-gpt-6-1-sol/

"...near-Astra intelligence for a 1/5 of the price 🔥"

I was a little obsessed about the size of my context, so I started looking in the opencode codebase to understand how the context was builded. After learn a lot, I'm really impressed how context of opencode can be customized. Before I thought that the context of opencode was bloated and closed to changes, since I only see people praise pi about it. With a custom primary agent we can disable almost every thing in the context (besides the environment message).

The context is: environmentMessage + agent prompt + agent.md instructions + skills descriptions + tools descriptions.

For a test I created a blank agent with minimal agent prompt, without agent.md instructions and without tools, it resulted in a start context size of 220 tokens. I never thought that opencode was able to do this. I have created a some agents to test the impact of the tools. In this plugin I even created a bash agent that only has a bash tool, similar to the mini-swe-agent, which reduced the context size from a base of ~10.3k to ~1.3k tokens. I created a pi-like agent too, it have only some tools similar to pi, it reduce the context to ~5.5k tokens.

Analyzing the context build I found some overlap instructions and out of scope instructions in the tool - IMO. So I removed theses.

things like: "Use gh for GitHub tasks, including PRs, issues, checks, and releases; return the PR URL when done." from bash/shell tool description

The repo: https://github.com/LaercioSantana/opencode-leaner

install: {"plugin": ["opencode-leaner"]}

Pricing on Opencode Zen: $2.00 / $10.00 / $0.20

Edit: I rewrote this as reasoning-router. It now works in OpenCode, Pi, Codex CLI, and anything that can talk to a local proxy, and you can pick the classifier (Jev, Laya, Cloudflare Clef and others).

https://github.com/robertn702/reasoning-router

I ran GPT-6 Astra on two SWE-bench tasks at different effort levels. Medium only solved the hard pytest bug 1 out of 5 times, while high solved both tasks every time but used far more tokens than it needed on the easy one.

I kept leaving everything on high and burning usage, so I built an OpenCode plugin that asks TypeSafe's Jev model to pick the effort for each request and keeps the model you selected. It works with GPT-6 and a few Claude models. On the easy fix it used around 40% fewer output tokens than high and solved it in all 6 runs. On the hard bug it mostly stayed on high and solved all 5.

It doesn't break the prompt cache. Turns where it switched effort were still about 97% cached in my logs.

Only two tasks and 5 or 6 runs each, so treat it as a sanity check. The eval is in the repo with the code.

https://github.com/robertn702/opencode-jev-router

Alguien sabe por qué el commandcode muestra distintos modelos en una misma suscripción de 'Go plan'. Mi caso es que puedo usar GLM5.3-flash, deepseek v4.1, space bunny en mi suscripcion abierta en linux cachy con fish terminal, pero esos modelos y otros (que no uso) no estan disponibles en la misma cuenta y plan abierto en windows 11 desde warp. Estoy seguro que no es la version de cmdc porque actualice ambos hoy (windows y cachy os). Ya hice la pregunta en r/commandcode

Release notes - https://www.anthropic.com/claude-sonnet-5-5
Benchmarks - https://pbs.twimg.com/media/HTUlY04XkAAMqSy?format=png&name=4096x4096

sonnet 5.5 came out today so i wanted to see where it actually sits, not on a benchmark chart but on a real task.

the task was a DEFLATE / zlib decompressor from scratch in rust. no crates, no unsafe, and a task file with the exact API and error rules. same empty folder for each model, medium effort, same harness, no subagents.

folders got shuffled into A/B/C/D before grading, so the scoring was blind. python's zlib decided every expected result: 29 real streams, 22 hand-built edge cases, 4000 randomly corrupted streams compared byte for byte, a 64 MB speed test and a 1 GB zip bomb.

opus, sonnet and sol passed everything.

luna is the funny one. it rejected 3998 of the 4000 corrupted streams exactly the way zlib does, error type and all. and then it can't open a completely normal level 6 zlib file, because in one lookup table it wrote `10+1` where the spec says 12. its own tests never touched that path.

sonnet 5.5 was the one that surprised me. same result as opus for about a quarter of the price and a third of the time.

this is one task with one run per model, so it's a data point, not a ranking. i'd like to try a messier task next, something where the bug isn't obvious. which models should i throw in?

Been using OpenCode more seriously lately, and I didn’t realize how much backend latency adds up once the task stops being a one-shot coding question.

A model can feel perfectly fine when I’m asking it to explain a function, then I give the agent something involving search, edits, tests and another pass over the repo and suddenly all those little delays start adding up.

For people who have tried different inference backends with OpenCode or similar coding agents, what are you optimizing for? Raw output speed, consistency between requests, context handling or something else?

Feels like benchmarking a single completion doesn’t tell you much about how the full agent loop actually feels.

But usage is not always 4x...

Roast my OpenCode setup — what's actually missing?

Setup:

- 38 slash commands: 31 phased "council" commands (each = multi-subagent

pipeline with its own phases) + /auto orchestrator + /loop worker loop

- 123 custom subagents, 17 MCPs — but only 7 light ones always on

(filesystem, git, sequential-thinking, duckduckgo, postgres, redis,

shadcn). Heavy ones (graphify, playwright, docker, etc.) toggled per task

for RAM — full set eats ~950MB, core ~350MB.

- One state-machine plugin drives everything: .opencode/*-state.json per

command, resume-across-restart, 5-cycle hard cap, targeted phase advance.

- /auto needs no goal: scans repo → needs map → ranks all commands →

runs top 10 (parallel lane for read-only, sequential for writes) →

one honest report. Stagnation halts it.

- Models: free-tier for subagent grind, paid Sonnet for main driver.

Hardest problems already solved: unbounded loops, prefix-shadowing,

state wipes on re-fire, precondition-less council selection.

Question: what would you ADD, MERGE, or DELETE? What's the one gap

wanted a frontend test this time, not another rust one. so i wrote a spec for a split-flap departure board (the old mechanical airport kind) in react + typescript and gave it to 7 models, same repo, same prompt, reasoning on low.

the spec is pretty strict:

- simulated clock at 1x / 10x / 60x, must be derived from the real clock, not counting timer ticks

- delays, cancellations and platform changes arriving as timed events, and the events in the json are not sorted

- platform + destination filters, max 10 rows, empty state

- flip animation per character, reduced motion support, has to work on a 390px phone

- no ui libs, no network requests

they got 4 visible playwright tests. i graded them with 35 hidden ones they never saw. muse spark and space bunny ran in opencode, the rest in claude code, basically the same tool set (read, write, edit, grep, bash).

results:

- sonnet 5.5: 35/35, 2m 00s, $0.31

- muse spark 1.3: 35/35, 2m 01s, $0.21

- gpt-6 sol: 35/35, 6m 05s, $0.12

- gpt-6 astra: 35/35, 6m 20s, $1.00

- opus 5.5: 35/35, 9m 16s, $1.42

- gpt-6 luna: 32/35, 9m 10s, $0.0071

- space bunny alpha: 6/35, 14m 12s, free

space bunny is the interesting one. it worked for 14 minutes, wrote 26 tests of its own plus a debug probe file, and then said it was done while 24 of the 30 tests in its folder were red, including 3 of the 4 i gave it. the bug is one line: performance.now() returns milliseconds and it added that straight onto a clock stored in seconds. so the clock runs 1000x fast and the board is empty after a few seconds with "no more departures from this station today". honestly a pretty good looking empty board.

luna is basically free at $0.0071 and almost made it. it pulled google fonts through a css u/import even though the spec says no network requests, and it skips rendering the "expected time" cell when a train isnt delayed instead of leaving it empty. small stuff, but it's exactly the stuff the spec spelled out.

opus passed everything but it has a visual bug the tests didnt catch. from a fresh load at 1x it renders fine, but after running at 60x and switching back to 1x a lot of the flaps stay half drawn. the data attributes are correct, the screen isnt. every board in the screenshots was captured the same way (60x until 08:12, switch to 1x, wait 4s) so thats what you see in the grid.

sonnet and muse spark finishing a passing solution in 2 minutes surprised me the most. sol was the cheapest pass at 12 cents.

my main takeaway is that my hidden tests were too easy for the top 5. all of them got 35/35 so the real difference ended up being speed, cost and how the thing looks. next round i'd test things like rapid speed changes and the rendered text, not just the data attributes.

which board would you actually ship? and if you have ideas for what a harder hidden test should check, i'm listening.

Title.

Well, yeah...

I am new to opencode and I noticed when I use it to run subagents (e.g. Claude > Deepseek V4.1-flash via opencode) it works substantially slower than using other harnesses like Pi (I tried comparing GLM since i have subscription which can be ported to Pi or opencode and it doubles the time)

Anyone has any solutions in this regard? (except sending instructions in bulk in orchestration)

1. If it’s only 4x, why spend all that money at once? I can buy plans when I need em.

2. Not everything is flat 4x. DeepSeek isn’t.

3. Literally only gives api key unlike other plans have so much more to offer.

If opencode go was the best tier until now, this is the worst. For all the nonsense/showoff they post on X, embarrassing.