kimi-k3 (Moonshot) always fails with Upstream request failed - tool schemas containing $ref are rejected #39995

Describe the bug

When using kimi-k3 (Moonshot) via OpenCode Go, every conversation with tools enabled fails immediately with:

Error from provider (Console Go): Upstream request failed

The exact same configuration works fine with glm-5.2, grok-4.5, deepseek-*. This is not a config/auth/region issue — it is model-specific to Moonshot.

Root cause (confirmed by direct API testing against the provider gateway)

Moonshot's upstream API rejects tool definitions containing:

1. $ref — even a bare {"$ref": "#/components/schemas/Foo"} with no sibling keys is rejected
2. tuple-style items arrays — "items": ["string", "number"] is rejected

opencode's sanitizeMoonshot sanitizer (packages/opencode/src/session/transform.ts, ~line 1524-1540) removes sibling keys of $ref and converts tuple items to items[0], but keeps the $ref itself. After sanitization the tool schema still contains $ref, which Moonshot still rejects — so the sanitizer never actually fixes the request.

Other providers (Zhipu/GLM, xAI/Grok) accept the same tool schemas, which is why only Moonshot models break.

Reproduction

1. Configure a Moonshot-backed model (e.g. kimi-k3) through any OpenAI-compatible gateway
2. Start any conversation — the main agent always includes tool definitions
3. Every request fails with Upstream request failed

Direct API test (same key + baseURL, only the tool schema differs):

Expected behavior

kimi-k3 (and other Moonshot models) should work in tool-enabled conversations, like glm-5.2 / grok-4.5 do.

Suggested fix

sanitizeMoonshot must strip $ref entirely, not just its sibling keys — Moonshot rejects even a bare $ref. Either:

• resolve $ref to the actual schema before sending, or
• drop properties that are pure $ref references

Environment

• OS: Windows
• Provider: OpenCode Go (https://opencode.ai/zen/go/v1)
• Model: kimi-k3