Qwen3.8-Flash-Next as a coding agent in OpenCode

The agent gets a repository at the state before the fix and the issue verbatim, plus one sentence: resolve the issue, you may run commands and the existing tests, stop when you are done. It does not get the tests used for scoring, nor any hint at them. Dependencies are installed; it has no network access. Only the model server is reachable.

The six tasks come from SWE-bench Verified. Only tasks were taken that two published runs of other models both solved, that are pure Python and that the dataset rates at 15 minutes to an hour of human work. The tasks are therefore known to be solvable. What is measured is whether Flash-Next solves them on these servers, how long it takes and how reliably across three passes.

Scoring follows SWE-bench: the patch the agent leaves in the working tree is applied to a fresh checkout together with the task's tests. A task is solved when the tests for the bug pass (FAIL_TO_PASS) and no previously passing test fails (PASS_TO_PASS). Scoring runs without Docker in a Python environment modelled on the SWE-bench harness, version 4.1.0.

All three arms use the same settings: context up to 262,144 tokens, temperature 1.0, top_p 0.95, reasoning effort xhigh, automatic compaction on, prompt cache on. Both servers use their multi-token prediction (MTP). Each machine works through the 18 passes one after another in the same order; nothing else runs.

On the HP ZBook the agent solves all 18 passes, on each Mac 17. Both failures are the same pass of the same task, the second pass of M3, on the MacBook and on the Mac Studio, with the same incomplete fix: the agent filters duplicate locations in Catalog.add by file, line and an identifier (uid). The duplicates from the issue carry different identifiers and therefore remain. The test for the bug fails, all others pass.

Whether sushi is weaker on M3 or whether one failure in three passes is chance cannot be read from this measurement.

One pass ended at the time limit: the third pass of G1 on the MacBook, after 120 minutes. The patch the agent had written by then passes all tests and therefore counts as solved, as in SWE-bench. The 150-step limit never applied.

Every agent step is one request to the server: it reads the new part of the history, usually the output of the last tool, and writes thinking and the next tool call. The MacBook reads at a median of 309 tokens per second and outputs 30.7, the Mac Studio 521 and 43.7, the ZBook 1,220 and 58.3. As the context grows, speed changes little on all three machines.

Both Macs run the same server and the same weights. The Mac Studio with 64 GPU cores reads 1.7 times as fast as the MacBook with 32 and writes 1.4 times as fast. Between the ZBook and the Macs, platform, server and weights all differ; the figures say how fast it goes on each machine.

Where the time goes follows from the logs: reading and output are recorded per request, the rest of the wall time belongs to the tools, mainly the tests the agent runs itself, and to OpenCode. On the Macs most of it is output, on the ZBook the rest. That includes an hour in which the agent waited for itself in G2 (chapter 04).

Per step the agent writes about the same on all three machines, between 549 and 592 tokens. On the MacBook it needed more steps, 1,426 against 1,107 on the Mac Studio and 771 on the ZBook. Wall time contains both, the speed per step and the number of steps, which varies from pass to pass.

How deep the context goes is up to the agent. The deepest session reached 217,152 tokens on the MacBook, at most 163,340 on the Mac Studio and 111,553 on the ZBook. No session reached the threshold at which OpenCode summarises the history; there was no compaction.

Of 3,571 tool calls, 18 failed (MacBook 6, Mac Studio 6, ZBook 6).

One pass shows how an agent can hold itself up: in G2 on the ZBook it waited for its test run with while pgrep -f "runtests.py --parallel 1". The search pattern is part of the waiting loop's own command line, so it always finds itself. It ended only at the one-hour timeout the agent had given the command. Afterwards it solved the task, after 72.8 minutes.

In 40 of 54 passes the agent tried to reach the network. It used curl to fetch files from raw.githubusercontent.com and api.github.com, in some cases the very pull request for the issue, ran pip download for newer releases of the package, queried the upstream repository with git ls-remote and called fetch() in OpenCode's JavaScript tool. No attempt received data: on all three machines the operating system's sandbox blocked every one of these connections. Every output was checked in the session exports.

With an open network Flash-Next would therefore regularly fetch the published fix for SWE-bench tasks. Such a measurement then shows how well the agent searches, not how well it repairs.

Passing tests do not show whether a patch addresses the root cause or only the tested case. All 52 solved patches were therefore judged, task by task, by a reviewer who did not know which machine they came from: a language model (Claude Haiku 5.5) given the issue, the maintainers' reference fix and the patches in random order, with paths blacked out. It answered three questions per patch with fixed values.

No patch merely works around the symptom; all address the root cause fully or for the reported case. The clearest difference is in the clutter: helper scripts, log files and output the agent left in the repository were found by the reviewer in 4 of 17 patches from the MacBook and in none from the other two machines.

When comparing with the reference fix the reviewer separates little: in 3 of the six tasks (M1, M2, M3) it gave every patch the same value. This question therefore says little about differences between machines.