It looks like an OpenCode issue than an NVFP4 or Blackwell issue.

If BLACKWELL_NATIVE_FP4 = 1 appears in the log and tokens are generating faster, then the native FP4 path is probably working.

I’d test it that way:

In OpenCode, make sure the configured context limit is not higher than the llama-server context. For example, if llama-server uses --ctx-size 32768, set OpenCode context to 32768 or lower.

Try disabling auto-compaction temporarily:

"compaction": {
  "auto": false,
  "prune": true,
  "reserved": 12000
}

Also try clearing the OpenCode session/cache, because it may keep reusing a broken/compacted conversation state.

So my guess is OpenCode is getting confused by context size, compaction, or the chat/tool template. Direct llama.cpp testing should confirm that quickly.This sounds more like an OpenCode/context/template issue than an NVFP4 or Blackwell issue.If BLACKWELL_NATIVE_FP4 = 1 appears in the llama.cpp log and tokens are generating faster, then the native FP4 path is probably working.I’d test it in this order:Try the model directly with llama.cpp, without OpenCode:

curl http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"messages": [
{"role": "user", "content": "Say hello in one short sentence."}
],
"max_tokens": 64,
"temperature": 0.2
}'
If this works normally, the model/llama.cpp/NVFP4 side is likely fine.Start llama-server with a larger context and the built-in chat template
In OpenCode, make sure the configured context limit is not higher than the llama-server context. For example, if llama-server uses --ctx-size 32768, set OpenCode context to 32768 or lower (just as an example).

Try disabling auto-compaction temporarily:"compaction": {
"auto": false,
"prune": true,
"reserved": 12000
}
Also try clearing the OpenCode session/cache, because it may keep reusing a broken/compacted conversation state.