hermes - 💡(How to fix) Fix [Feature Request]: Support vision/image input for kimi-k2.6 via Kimi Code CLI endpoint or Moonshot Open Platform

Problem

Hermes Agent currently hardcodes kimi-coding provider as vision-disabled in vision_tools.py:

_PROVIDERS_WITHOUT_VISION = frozenset({"kimi-coding", "kimi-coding-cn"})

This prevents users from using image input even when the underlying model (kimi-k2.6) supports vision capabilities.

Context

Kimi Code CLI officially supports capabilities = ["image_in"] in its model configuration (docs):

[models.kimi-for-coding]
provider = "kimi-for-coding"
model = "kimi-for-coding"
max_context_size = 262144
capabilities = ["thinking", "image_in"]

However, the Kimi Code API endpoint (https://api.kimi.com/coding/v1) does not expose image input through the API — this is a client-side feature for the CLI's interactive terminal mode only.

The Moonshot Open Platform (https://api.moonshot.cn/v1) does support vision/multimodal input, as confirmed by the official platform comparison:

Current Behavior

When a user sends an image to Hermes with model.provider: kimi-coding, the agent responds:

"vision 工具未配置" / "No LLM provider configured for task=vision"

Desired Behavior

Option A (preferred): Allow kimi-coding provider to support vision by querying the model's actual capabilities dynamically, rather than hardcoding it as disabled. If the endpoint doesn't support it, fall back gracefully.

Option B: Add native support for Moonshot Open Platform (moonshot provider) with vision enabled, so users can configure it as either:

• Primary provider (replace kimi-coding)
• Auxiliary vision provider (auxiliary.vision.provider: moonshot)

Environment

• Hermes version: latest
• Provider: kimi-coding
• Model: kimi-k2.6
• OS: macOS

Additional Notes

• The models_dev_cache.json currently marks all kimi-for-coding models with attachment=False
• Users who only have a Kimi Code CLI API Key cannot access vision capabilities without applying for a separate Moonshot Open Platform Key
• This creates friction for users who expect the same model (kimi-k2.6) to have consistent capabilities across different endpoints

Would love to see this addressed in a future release. Happy to provide more details or test beta builds.