TL;DR: opencode's OpenRouter integration silently drops completions for several non-default FOSS models. The same model + same prompt works cleanly via direct OpenRouter HTTP API, so it's specifically opencode's adapter layer dropping the response.

Reproduction

opencode-ai 1.14.40 (current at time of report). FOSS-only deployment driven by Agor (agor-live 0.17.3) which spawns opencode sessions with explicit modelConfig.

Affected models (verified silently failing through opencode):

• moonshotai/kimi-k2.6
• deepseek/deepseek-r1
• meta-llama/llama-3.3-70b-instruct
• openai/gpt-oss-120b (intermittent)

Working model (control):

• qwen/qwen3-coder-30b-a3b-instruct — produces clean output reliably

Failure shape

Spawned session reaches terminal status idle with 0 assistant messages. The user prompt is sent (sometimes twice — opencode-side retry), but the model produces no response that opencode persists.

opencode-serve.log shows:

[Executor 019e03fe] [opencode] Using worktree directory: ...
  model: 'moonshotai/kimi-k2.6',
[OpenCodeTool] Using model: moonshotai/kimi-k2.6
[Executor 019e03fe] [OpenCodeTool] Sending prompt with model: {"providerID":"openrouter","modelID":"moonshotai/kimi-k2.6"}
  ...file content loaded into prompt...

After that — nothing. No completion event, no error log, just silence. Compare to working qwen30 cell which logs the full message stream + tool-use cycle.

Direct API works fine for the same models

I bypassed opencode and called OpenRouter's /api/v1/chat/completions directly from Python with the same model + prompt + tool spec:

Same OpenRouter endpoint, same key, same prompt, same tools parameter — direct API works for Kimi K2.6; opencode silently drops it.

Hypothesis (untested)

Likely candidates:

1. opencode's per-provider response parser hits a format edge case on Kimi K2.6's stream (different SSE shape or tool_call shape).
2. Tool-use schema mismatch — opencode may send a tool-use spec the model doesn't recognize, model returns content-only, opencode discards as malformed.
3. Streaming-vs-non-streaming protocol mismatch on the reply side.

The fact that qwen30 works through opencode and Kimi K2.6 works direct rules out auth, network, or model-level capability.

Why this matters

For multi-agent orchestration use cases (we're building one over Agor), opencode is the only FOSS-friendly agentic_tool available. When non-default FOSS models silently fail, the entire stack effectively becomes single-model (qwen30-only). That's a real ceiling for the FOSS path.

Workaround

We've built a direct-API specialist runtime that bypasses opencode for FOSS models (Python harness with file-edit tool-use mediated client-side). Works reliably across qwen30, Kimi K2.6, etc. But this is unfortunate — opencode would be the natural home for this if the adapter held up.

Happy to share repro scripts (Python, ~150 LoC) if useful for diagnosis.

Environment

• opencode-ai 1.14.40
• Linux x64 (Guix), Node v22.14.0
• OpenRouter API
• Agor 0.17.3 as the spawning layer (uses POST /sessions { agentic_tool: \"opencode\", model_config: {...} })