opencode: --model in agentArgsOverride fails (not passed via HTTP API)

[pythoninthegrass]

Bug: --model in agentArgsOverride for opencode does not work

Problem

When using agentArgsOverride to pass --model to the opencode agent, gnhf fails immediately on every iteration with a 400 error from the opencode serve API. The TUI shows "waiting (backoff)..." with 0 in / 0 out tokens.

There are two separate issues:

1. opencode serve does not accept --model — gnhf passes all extraArgs directly to opencode serve, but --model / -m is only a valid flag on the main opencode command (TUI/run modes), not on serve. Depending on the opencode version, this either causes the server to print help and exit, or silently ignores the flag.

2. The opencode HTTP API expects model as an object, not a string — The POST /session/:id/prompt_async endpoint expects the model field as { "providerID": "...", "modelID": "..." }, not a bare string like "fireworks-ai/accounts/fireworks/models/qwen3p6-plus". Passing a string returns HTTP 400 with: "Invalid input: expected object, received string".

Steps to reproduce

1. Configure ~/.gnhf/config.yml:

   agent: opencode
   agentArgsOverride:
     opencode:
       - --model
       - fireworks-ai/accounts/fireworks/models/qwen3p6-plus

2. Run gnhf "any prompt" in a git repo
3. Observe "waiting (backoff)..." with 0 tokens processed

Expected behavior

gnhf should extract --model from the extra args, parse the provider/model string into { providerID, modelID }, and pass it in the prompt_async request body rather than on the opencode serve CLI.

Proposed fix

In OpenCodeAgent:

• Extract --model/-m from extraArgs before spawning the server
• Split the provider/model string on the first / into { providerID, modelID }
• Pass the model object in the prompt_async request body (which the opencode API supports)
• Continue passing all other extra args to opencode serve as before

I've got this working locally with the fix applied — gnhf successfully runs opencode with a fireworks-ai model, and all existing tests pass.

Environment

• gnhf: 0.1.24
• opencode: 1.14.21
• macOS: 15.7.1 (24G231)
• Node.js: v24.12.0

[kunchenguid]

Thanks for the detailed writeup and the PR - the reproduction plus the API-format detail made the right shape of this much easier to see.

Going to close #84 and keep this issue open. I don't want to land the "intercept --model inside agentArgsOverride" approach, because it conflates two things:

1. agentArgsOverride is defined as "argv passed straight to the agent CLI". Silently extracting --model, reshaping provider/model into {providerID, modelID}, and moving it into an HTTP body breaks that contract. Once we special-case one flag, the next request (temperature, reasoning effort, tools...) becomes another one, and the config gets hard to reason about.
2. "Set the model" is a universal user task even though the name format is per-agent. claude / codex accept --model at spawn; rovodev and opencode are long-running servers where the model belongs in the HTTP request, not on serve. Same intent, different plumbing.

The direction I'd rather take is a first-class model option:

```yaml
agentModel:
claude: sonnet
codex: gpt-5.4
opencode: fireworks-ai/accounts/fireworks/models/qwen3p6-plus
rovodev: ...
```

plus a `--model` CLI flag that maps to `agentModel[config.agent]`. Each agent is responsible for plumbing the string where it belongs: spawn arg for claude/codex, request body for opencode (with the string → `{providerID, modelID}` split you already wrote) and rovodev. `--model`/`-m` inside `agentArgsOverride.opencode` becomes a hard error pointing at the new option, so users don't silently land in the wrong place.

Really appreciate the work here. Happy to collaborate on a follow-up PR in this shape if you're up for it.

[pythoninthegrass]

No worries @kunchenguid ! I'll circle back later this week and try for round two 🥳