Repository navigation
Moonshot/Kimi K2.6 rejects tool schemas with nesting depth > 10, breaking all tool calls #25495
Description
Bug description
Moonshot/Kimi K2.6 models enforce a strict JSON schema depth limit of 10 levels. When using tools with deeply nested schemas (e.g., Klaviyo API campaign message definitions with 11-12 levels of nested anyOf / properties), the model rejects the request with:
Invalid request: tools.function.parameters is not a valid moonshot flavored json schema, details: schema depth exceeds maximum limit of 10
This means all tool calls fail on Kimi K2.6 when any tool defines a schema with depth > 10. The error is not per-tool — it's per-request, so one deeply nested tool breaks the entire tool-use capability.
Steps to reproduce
- Configure model to
kimi-k2-6or any Moonshot model - Use a tool with deeply nested schema (e.g., Klaviyo
create_campaignwith mobile_push badge configuration) - Any prompt that triggers tool use will fail with schema depth error
Expected behavior
Tool schemas should be automatically flattened/limited to comply with Moonshot's depth constraint, allowing tool calls to succeed.
Actual behavior
All tool calls fail with schema depth exceeds maximum limit of 10.
Environment
- Opencode version: latest dev
- Model: kimi-k2-6 (Moonshot)
- Affected tools: Any with deeply nested anyOf/properties (Klaviyo, complex API tools)
Related
PR #23667 addressed related Moonshot/Kimi schema handling ( resolution, error exposure), but did not implement depth limiting.
Activity
olafgeibig commentedon Jun 24, 2026
please merge it
wax911 commentedon Jul 13, 2026
Currently experience something similar with kimi 2.7:
petterssonjonas commentedon Jul 17, 2026
I'm experiencing the same issue with the Kimi Code API. 37496
github-actions commentedon Sep 17, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
3xOGssavage commentedon Sep 19, 2026
Same enforcement now blocks Muse Spark 1.3 (Meta's model served via OpenCode's own gateways:
opencode/muse-spark-1.3*on Zen/Console andopencode-go/muse-spark-1.3*on Console Go). Every request fails, even a plain "hi" in a fresh chat, with:Reproduction data (2026-09-19, current stable, Windows):
https://mcp.vercel.com, 212 tools) + Muse Spark 1.3 → fails on every message — the check is per-request, so one deep tool disables all tool use.mcp.vercel.comusing the MCP SDK: 12 tools nest 10–15 levels deep —create_flag(15),update_flag(14),update_flag_segment(13),create_sandboxes_v2/v3/v4+update_sandbox(12),put_firewall_config/update_project/update_session_network_policy(11),create_connector/update_firewall_config(10).permissiondeny (e.g."vercel_create_flag": "deny"inopencode.json) removes the tool registration entirely so its schema is never sent (ToolRegistry.materialize), after which Muse Spark 1.3 works with the remaining 200 vercel tools (verified incl. a live read call from the model).Request: could OpenCode flatten/depth-cap tool schemas per provider at request time (or expose a per-tool exclusion for depth-capped models)? That would restore the withheld tools without user-side config. Happy to share more measurements if useful.
p30arena commentedon Oct 16, 2026
I disabled MCPs, and the issue is gone