Bug Report: kimi-k2.6:cloud fails with TypeError: unhashable type: 'list'

Hermes Version: v2.6.x (git: 39c41d0f2) Provider: Ollama Cloud and Ollama local proxy (127.0.0.1:11434/v1) Model: kimi-k2.6:cloud (Moonshot AI Kimi K2.6, 1T parameters, INT4) Python OpenAI SDK: 2.24.0 Related: #28291

Problem

Every API call to kimi-k2.6:cloud immediately fails with:

TypeError: unhashable type: 'list'

This triggers fallback on every single request, making kimi-k2.6:cloud completely unusable.

Investigation

1. Direct Ollama API works fine

curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k2.6:cloud","messages":[{"role":"user","content":"say hello"}],"max_tokens":16384,"stream":true}'

Returns valid SSE chunks with no errors. Non-streaming calls also succeed.

2. OpenAI SDK streaming works for basic calls (no extra_body)

client = openai.OpenAI(base_url='http://127.0.0.1:11434/v1', api_key='ollama')
stream = client.chat.completions.create(
    model='kimi-k2.6:cloud',
    messages=[{"role": "user", "content": "say hello"}],
    tools=[{"type": "function", "function": {"name": "test_tool", ...}}],
    max_tokens=16384,
    stream=True,
)
# SUCCESS — receives all chunks correctly

3. Ollama model metadata

{
  "details": {
    "parent_model": "kimi-k2.6",
    "family": "kimi-k2",
    "families": null,
    "parameter_size": "1042000000000",
    "quantization_level": "INT4"
  },
  "capabilities": ["vision", "thinking", "completion", "tools"]
}

5. Response structure differs from other models

The kimi-k2.6 response includes a top-level reasoning field alongside content and role:

{"role": "assistant", "content": "Hello! How can I help you today?", "reasoning": "The user wants me to say hello..."}

This reasoning field is model-specific and not present in other responses (e.g. glm-5.1, qwen3-coder), which explains why those models work fine.

Root Cause Analysis

The kimi-k2.6 model returns response fields (specifically the reasoning field as a top-level message property) that the OpenAI SDK (v2.24.0) cannot properly deserialize/hash. When the SDK encounters the response, it attempts to construct hashable objects from the response data, and the reasoning field (or another model-specific field) causes a TypeError: unhashable type: 'list' in the SDK's internal processing.

Other models work fine through identical provider configurations because they don't return these problematic fields.

Expected Behavior

kimi-k2.6:cloud should work as model via Ollama providers.

Additional Analysis: Kimi Provider Pathway Processes Differently

The dedicated kimi-coding provider profile (KimiProfile in plugins/model-providers/kimi-coding/__init__.py) handles kimi models completely differently from the generic Ollama/custom path.

What the Kimi Profile Path Does (api.moonshot.ai)

# KimiProfile.build_api_kwargs_extras() adds:
extra_body["thinking"] = {"type": "enabled"}     # Kimi's official param name
top_level["reasoning_effort"] = "medium"            # Top-level param

# Plus is_moonshot_model() triggers sanitize_moonshot_tools()
# which cleans tool schemas for Kimi's stricter JSON Schema subset

What the Generic/Ollama Path Does (127.0.0.1:11434)

Because _is_kimi = False (base URL doesn't match api.kimi.com / moonshot.ai / moonshot.cn):

1. Wrong param name: Sends extra_body = {"reasoning": {"enabled": True, "effort": "medium"}} instead of thinking — a completely different field name that Ollama/Kimi doesn't expect via this route
2. No tool schema sanitization: is_moonshot_model() matches kimi-k2.6:cloud by name, but sanitize_moonshot_tools() only runs inside the KimiProfile profile path (line 438 of chat_completions.py). The legacy code path at line 337 also checks _is_kimi but this flag is False for local Ollama, so the sanitization is skipped.
3. No reasoning_effort top-level param: The Kimi profile adds this; the legacy path doesn't.
4. Response deserialization mismatch: The kimi-k2.6 response includes a top-level reasoning field at the message level that the OpenAI SDK's generic deserializer can't handle, causing TypeError: unhashable type: 'list'. The Kimi profile pathway presumably handles this field correctly.

Why Direct Cloud Also Fails

Even bypassing Ollama and hitting Kimi's cloud directly, the model identification still resolves to provider=custom (not kimi-coding), so the same legacy code path runs. The KimiProfile only activates when the provider is explicitly configured as kimi-coding in Hermes config — it's not triggered by model name alone.

Suggested Fix

The cleanest fix would be model-name-based profile resolution: when a model name matches is_moonshot_model(), route it through the KimiProfile regardless of which provider/base_url is configured. This would ensure:

• Correct thinking param (not reasoning)
• Tool schema sanitization for Kimi's stricter requirements
• Proper reasoning_effort top-level param
• Correct response deserialization for the reasoning field

This aligns with the existing pattern where sanitize_moonshot_tools() is already called by model name in the profile path (line 438) — it just needs to extend to the response handling layer as well.

Workaround

Use a different model, which doesn't trigger this error.

Environment

• OS: Linux (Debian 13)
• Ollama: v0.9.x (local, port 11434)
• Model: kimi-k2.6:cloud (Moonshot AI, 1T params, INT4 quantization)
• Hermes config: provider ollama-launch with custom_providers entry pointing to http://127.0.0.1:11434/v1
• Also confirmed failing on direct cloud (no Ollama proxy)