Draft: GitHub Issue / PR — Re-enable vision for Kimi Coding provider

Summary

PR #17451 (commit ff687c0, merged ~3 days ago) added kimi-coding to _PROVIDERS_WITHOUT_VISION in agent/auxiliary_client.py based on Kimi documentation stating that api.kimi.com/coding does not accept image input (issue #17076).

Direct API testing shows this is no longer true. Both Kimi Coding endpoints (/v1/messages and /v1/chat/completions) now successfully process image input. The hardcoded deny-list introduced by #17451 now causes a regression: users with kimi-coding as their main provider and no fallback vision backend get:

No LLM provider configured for task=vision provider=auto. Run: hermes setup

instead of functional native vision.

Background: what #17451 fixed and why it's now stale

The #17451 fix was correct at the time based on Kimi's documented behavior. However, Kimi has since enabled multimodal input on the /coding endpoint. The deny-list now blocks a working provider instead of a broken one.

Affected users

Anyone using kimi-coding as their only configured provider with auxiliary.vision.provider: auto (default). Users who configured OpenRouter/Anthropic/Nous as fallback are unaffected.

Steps to reproduce

1. Configure Hermes with only kimi-coding provider (no OpenRouter, Anthropic, Nous).
2. Ensure auxiliary.vision.provider is auto (default).
3. Enable vision toolset: hermes tools enable vision
4. Start fresh session and attach an image:

   /image ~/some-photo.jpg

5. Observe: No LLM provider configured for task=vision provider=auto

Expected behavior

auto resolution should route vision through kimi-coding when it is the main provider and the API accepts image input.

Actual behavior

resolve_vision_provider_client() hits the _PROVIDERS_WITHOUT_VISION guard introduced by #17451, skips kimi-coding, falls through to unavailable aggregators, and returns None.

Verification via direct API calls

Test 1 — Messages API (Anthropic wire, /v1/messages)

curl -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "kimi-for-coding",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": "iVBORw0KGgo..."}},
        {"type": "text", "text": "What color is this?"}
      ]
    }],
    "max_tokens": 100
  }' \
  https://api.kimi.com/coding/v1/messages

Result: HTTP 200, correct image analysis returned.

Test 2 — Chat Completions (OpenAI wire, /v1/chat/completions)

curl -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "User-Agent: claude-code/0.1.0" \
  -d '{
    "model": "kimi-for-coding",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}},
        {"type": "text", "text": "What color is this?"}
      ]
    }],
    "max_tokens": 100
  }' \
  https://api.kimi.com/coding/v1/chat/completions

Result: HTTP 200, image analysis + reasoning_content returned.

Note: Hermes auxiliary client already injects User-Agent: claude-code/0.1.0 for api.kimi.com endpoints (agent/auxiliary_client.py:1108–1109 and :1921–1922), so the Chat Completions path is already correctly configured.

Proposed fix

Remove kimi-coding and kimi-coding-cn from _PROVIDERS_WITHOUT_VISION and update the comment to reflect current API reality.

Patch

--- a/agent/auxiliary_client.py
+++ b/agent/auxiliary_client.py
@@ -250,13 +250,12 @@ _PROVIDER_VISION_MODELS: Dict[str, str] = {
 # it must skip straight to the aggregator chain instead of returning a client
 # that will 404 on every vision request.
 #
-# kimi-coding / kimi-coding-cn: the Kimi Coding Plan routes through
-# api.kimi.com/coding (Anthropic Messages wire) which Kimi's own docs
-# describe as having no image_in capability. Vision lives on the separate
-# Kimi Platform (api.moonshot.ai, OpenAI-wire, pay-as-you-go).  See #17076.
+# NOTE: Previously included kimi-coding / kimi-coding-cn based on outdated
+# documentation. Direct API testing (2026-05-03) confirms both the Kimi Coding
+# Messages API (/v1/messages) and Chat Completions (/v1/chat/completions)
+# endpoints accept image input with proper User-Agent. The auxiliary client
+# already sends `User-Agent: claude-code/0.1.0` for api.kimi.com requests.
 _PROVIDERS_WITHOUT_VISION: frozenset = frozenset({
-    "kimi-coding",
-    "kimi-coding-cn",
 })

Risk assessment

• Zero regression risk for non-Kimi users — only removes entries from a static deny-list; no other code paths touched.
• No risk for Kimi users — verified live that the API accepts multimodal input; the auxiliary client already sets the required User-Agent header.
• Reverts an outdated guard from #17451 — restores the pre-#17451 behavior, which is now correct again because the upstream API has changed.

Related

• Issue #17076 — original bug report (404 on vision with kimi-coding)
• PR #17451 (ff687c0) — added the deny-list (correct at the time, now stale)

Suggested issue title

fix: remove kimi-coding from _PROVIDERS_WITHOUT_VISION — vision now supported upstream

Suggested labels

type/bug, comp/cli, provider/kimi, regression

Checklist for PR

• Patch applied to agent/auxiliary_client.py
• No new tests required (removal from static deny-list)
• Existing vision auto-detection tests pass
• Verified with live kimi-for-coding API key (both Messages and Chat Completions endpoints)