Add opencode as a provider

[stgreenb]

Problem

Opencode has already been added as a target (thank you), but not as an LLM provider, and it would be convenient if it was. I did not submit the fork below as a formal PR (but could) as it was low effort coded, but it is is a working example of using the opencode cli as the LLM provider similar to other sources already included in caliber.

Proposed solution

https://github.com/stgreenb/ai-setup

Changes

• New provider: src/llm/opencode.ts - CLI-based LLM provider using opencode run --format json
• Types: Added 'opencode' to ProviderType in src/llm/types.ts
• Registration: Provider registered in src/llm/index.ts
• Config: Default model + CALIBER_USE_OPENCODE env var support in src/llm/config.ts
• Model recovery: Added opencode to known models in src/llm/model-recovery.ts
• Interactive setup: Added OpenCode option to src/commands/interactive-provider-setup.ts
• Tests: Unit tests in src/llm/__tests__/opencode.test.ts (4 tests)

Alternatives considered

No response

[alonp98]

hey @stgreenb, appreciate you taking the time to build this out and sharing the fork. the core approach is right, opencode run --format json is exactly how we'd want to integrate it

took a look at the fork and the provider structure follows our patterns well. a few things we'd want to tighten up before it can land:

needs to be added:

• trackUsage() calls, without these the token usage summary is blank when using opencode
• message history support (options.messages), the current impl only concatenates system + prompt, which breaks multi-turn refinement in caliber init
• parseSeatBasedError() integration for friendly error messages on auth/rate-limit failures

needs hardening:

• parseJsonOutput() has a few fragile fallbacks (arbitrary line length threshold, regex for {...} extraction). would be good to rely on the structured JSON events from --format json more directly
• streaming should use --format json instead of --format default, the code parses lines as JSON but the flag says otherwise
• the console.error on stderr should go through debug logging, not raw console output

test coverage:

• the 4 tests are a good start but we'd need coverage for the actual call()/stream() behavior, output parsing, timeout handling, and error cases. claude-cli.test.ts is a good reference for the level we aim for

one note on the fork: it includes some unrelated changes (config priority reversal, model downgrades, login check removals) that we'd want to keep separate. if you want to submit a PR, ideally just the opencode provider files isolated from those

would you be up for cleaning this up into a PR with those fixes? happy to do a detailed review on it. alternatively we can implement it on our side using your fork as reference, either way works

[stgreenb]

PR submitted with the above changes.