OpenCode (Desktop and CLI) *extremely* slow

[derekrodgers]

mtplx doctor --json

Setup: M3 Pro, 36 GB, macOS 15.7.5

MTPLX works perfectly in the web chat interface, at the expected speed.

However, when I try to use OpenCode (either desktop or CLI), it shows Thinking... and sits there for many, many minutes before outputting anything.

Sample prompt:

write a hello world app in python

This took more than 7 minutes to complete in opencode but only seconds in the web chat UI. I'm sorry that I can't offer additional tests / diagnostics; I'm not sure where to begin with this one.

I'm thinking the system prompt overhead, etc does not account for a disparity this large.

Thank you for this very exciting project! The speeds are impressive!

Exact command

mtplx start

Model path or repo id

Youssofal--Qwen3.6-27B-MTPLX-Optimized-Speed

Chip, RAM, macOS version

M3 Pro, 36 GB, macOS 15.7.5 (24G624)

[youssofal]

Thanks for reporting this clearly. This is fixed in v0.3.5.

Root cause: OpenCode tool-result turns were not reusing the stable SessionBank prefix, so after the first tool step MTPLX could cold-prefill the full OpenCode prompt/history again. In local validation, the first OpenCode CLI turn was cold at about 10.6K prompt tokens, and the follow-up reused 10,655 cached tokens with TTFT under 1s.

Please upgrade with:

brew update && brew upgrade mtplx

or, for PyPI installs:

python3 -m pip install -U mtplx==0.3.5

If you still see multi-minute "Thinking..." after upgrading, reopen or comment with the new /metrics latest block and I’ll dig in.

[derekrodgers]

Hi! Thank you for the quick response! I've updated to the latest version as suggested, but I'm still experiencing the issue.

Could you explain what this part means?

or comment with the new /metrics latest block and I’ll dig in.

I ran some quick head-to-head tests with the prompt write a python hello world script. do not run it.:

LM Studio
- 3m46s
oMLX
- 40s
MTPLX
- 2m36s

In all three cases I ensured the model was fully loaded into memory before sending the prompt. And of course, because the prompt was so simple, the entire delta between the three was due to TTFT/Thinking. (In all three cases, once it got started, it finished in 8s or so.)

I think the performance improvement of oMLX over LM Studio makes sense to me. But I'm hoping there's a way to get the initial Thinking... stage of MTPLX down to something like what oMLX's looks like. Is this technically feasible? Your TPS speed improvement is huge, but the utility is degraded a lot by this extended TTFT/Thinking process (I'm not sure which of the two is the issue, tbh.) Once again, this is only an issue in OpenCode. Token emission begins immediately in the chat interface. Obviously there's a system prompt to process with OpenCode, but oMLX just does it so much quicker.

If there's any other information I can provide for diagnostic purposes, please let me know. Thanks again!

(I don't have permission to reopen the issue.)

[daitamu]

Same kind of "OpenCode hang on first request" symptom hit on a Mac Studio M3 Ultra 96GB / macOS 26.4 / MTPLX 0.3.7 with the same model (Youssofal/Qwen3.6-27B-MTPLX-Optimized-Speed). After bisecting our LaunchDaemon args we found a complete workaround: don't pass the reasoning-related CLI flags explicitly — leave them at default.

Repro

v1 (broken) — mtplx quickstart with reasoning flags explicit:

mtplx quickstart --host 0.0.0.0 --port 18116 --api-key <K> \
  --model Youssofal/Qwen3.6-27B-MTPLX-Optimized-Speed \
  --profile sustained --download --yes \
  --mtp --depth 3 \
  --default-temperature 0.6 --default-top-p 0.95 \
  --model-id mtplx-qwen36-27b-direct \
  --reasoning on \
  --reasoning-parser qwen3 \
  --preserve-thinking on

v2 (works) — same command without the last three lines (let defaults apply):

mtplx quickstart --host 0.0.0.0 --port 18116 --api-key <K> \
  --model Youssofal/Qwen3.6-27B-MTPLX-Optimized-Speed \
  --profile sustained --download --yes \
  --mtp --depth 3 \
  --default-temperature 0.6 --default-top-p 0.95 \
  --model-id mtplx-qwen36-27b-direct

Measurements (OpenCode CLI, same LRU-Cache 3-file task)

variant	wall	write tool calls	files produced
v1 explicit reasoning flags	117.9 s	0	0 (mkdir only)
v2 default reasoning flags	132 s	3	3 (unittest 6/6 PASS)
v2 N=3 reproducibility	avg 138 s	100% fire rate	3-file: 33%, 1-file: 67%
(baseline: mlx_lm.server raw)	239 s	3	3

So with the workaround we get the agentic loop back and about 1.8× faster wall vs the mlx_lm.server baseline.

Puzzling part

The v1 flags should be functionally identical to defaults:

• --reasoning on is documented as the default
• --reasoning-parser qwen3 is the only option that makes sense for the Qwen3.6 family
• --preserve-thinking auto (default) is documented to preserve it for reasoning-capable templates anyway

But explicitly passing them reproducibly breaks OpenAI-compatible tool-call streaming inside the agentic loop (the model emits long reasoning_content / thinking but never the actual write tool call), while leaving them off works.

Possible interaction with #53 (--chat-template-kwargs preserve_thinking=true) and #54 (SessionBank reasoning_content / prefix_divergence) — looks like the explicit flags trigger a slightly different chat-template / SSE-streaming path than the implicit defaults.

Happy to share full SSE traces / /metrics blocks / response.json dumps if useful for triaging — just let me know what format would be easiest to consume.

Note for other readers

If you hit "OpenCode hangs / never produces tool calls" on a current MTPLX, try removing --reasoning / --reasoning-parser / --preserve-thinking from your CLI entirely before tweaking anything else. It costs nothing and was a 0% → 100% tool-call fix for us.