Follow-up to #22 (Anthropic-compatible API support / Kimi). Two gaps to harden before treating Kimi as fully supported. Both are additive fixes; existing providers are unaffected.
1. generate() assumes the first content block is text
anthropic_compat_client.py extracts the reply with body["content"][0]["text"]. The Anthropic Messages API can return a non-text block first (notably an extended-thinking block). If Kimi's coding endpoint leads with such a block, every call raises LLMError: unexpected response format and Kimi becomes unusable.
Fix: scan body["content"] for the first item with type == "text" and use its text; only error if none exists.
2. Setup wizard probes anthropic_compat providers with OpenAICompatClient
cli.py:967–983 hard-codes OpenAICompatClient for every non-Ollama provider. For kimi the connection test therefore hits …/coding/models with Authorization: Bearer … (wrong endpoint + wrong auth), producing a false "Cannot reach … continuing anyway" warning and an empty model list even with valid credentials. The runtime path (build_client) is correct, so the pipeline works — only synto setup UX is degraded.
Fix: route the wizard's temp client through the same anthropic_compat branch (or through build_client) so the probe matches the runtime client.
3. No live verification yet
Every test in #22 is mocked. The real endpoint URL, headers, and response shape are unconfirmed against Kimi. The JSON-fallback path (no JSON mode → structured_output.py regex/retry) is the riskiest area, so smoke-test ingest+compile, not just query:
KIMI_API_KEY=... PROVIDER=kimi FAST_MODEL=<kimi-model> HEAVY_MODEL=<kimi-model> synto ingest && synto compile
A test covering the multi-content-block case (item 1) should be added alongside the fix.
Follow-up to #22 (Anthropic-compatible API support / Kimi). Two gaps to harden before treating Kimi as fully supported. Both are additive fixes; existing providers are unaffected.
1.
generate()assumes the first content block is textanthropic_compat_client.pyextracts the reply withbody["content"][0]["text"]. The Anthropic Messages API can return a non-text block first (notably an extended-thinking block). If Kimi's coding endpoint leads with such a block, every call raisesLLMError: unexpected response formatand Kimi becomes unusable.Fix: scan
body["content"]for the first item withtype == "text"and use itstext; only error if none exists.2. Setup wizard probes
anthropic_compatproviders withOpenAICompatClientcli.py:967–983hard-codesOpenAICompatClientfor every non-Ollama provider. Forkimithe connection test therefore hits…/coding/modelswithAuthorization: Bearer …(wrong endpoint + wrong auth), producing a false "Cannot reach … continuing anyway" warning and an empty model list even with valid credentials. The runtime path (build_client) is correct, so the pipeline works — onlysynto setupUX is degraded.Fix: route the wizard's temp client through the same
anthropic_compatbranch (or throughbuild_client) so the probe matches the runtime client.3. No live verification yet
Every test in #22 is mocked. The real endpoint URL, headers, and response shape are unconfirmed against Kimi. The JSON-fallback path (no JSON mode →
structured_output.pyregex/retry) is the riskiest area, so smoke-test ingest+compile, not just query:A test covering the multi-content-block case (item 1) should be added alongside the fix.