[Zen] kimi-k2.7-code: ~50% of sessions get "[NOT_FOUND] Model not found" via provider (Console) — sharded by x-opencode-session, deterministic per session #46011

Summary

Since ~2026-08-28 09:00 UTC, Zen chat completions for kimi-k2.7-code fail on roughly half of all OpenCode sessions with:

Error from provider (Console): Upstream request failed: [NOT_FOUND] Model not found, inaccessible, and/or not deployed

(HTTP 400, error.param: "model", error.type: "server_error".)

The failure is sharded by the x-opencode-session header, which makes it look intermittent from the CLI but deterministic per session:

• Request without x-opencode-session: never fails (100+ probes, 0 failures — including large-context, streaming, and tool-calling payloads).
• Request with a random x-opencode-session: ~50% fail rate (fresh id each request).
• Request re-using a session id that failed once: fails every time — which means an affected OpenCode session dies on its first model call and every in-session retry hits the same broken replica, so retries never help.
• The model is present in GET /zen/v1/models, and the identical request body succeeds when the header is dropped, so this looks like a routing/replica issue behind Zen (the error text reads like an upstream Vertex-style 404 relayed verbatim), not a catalog or auth problem.

Only kimi-k2.7-code is affected. Under the same session-headered probes: kimi-k2.6, kimi-k2.5, kimi-k3 — 10/10 success each.

Observed from two unrelated egress networks (a hosted Linux box and a Daytona sandbox in Frankfurt), same behavior, so it is not source-IP dependent.

Repro

# 1) No session header — always succeeds:
curl -s https://opencode.ai/zen/v1/chat/completions \
  -H "Authorization: Bearer $OPENCODE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"hi"}],"max_tokens":5}'

# 2) With a session header, as the OpenCode client sends — run ~10x, about half fail:
for i in $(seq 1 10); do
  SES="ses_$(head -c16 /dev/urandom | xxd -p)"
  curl -s -o /dev/null -w "$SES %{http_code}\n" https://opencode.ai/zen/v1/chat/completions \
    -H "Authorization: Bearer $OPENCODE_API_KEY" \
    -H "Content-Type: application/json" \
    -H "x-opencode-client: cli" \
    -H "user-agent: opencode/1.18.18 ai-sdk/provider-utils/4.0.23 runtime/bun/1.3.14" \
    -H "x-opencode-session: $SES" \
    -d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"hi"}],"max_tokens":5}'
done

# 3) Take any session id that printed 400 above and repeat it — it fails 100% of the time.

End-to-end: opencode run "Reply with exactly: PONG" (opencode-ai 1.18.18) with "model": "opencode/kimi-k2.7-code" fails ~3/8 invocations with the error above; each failing invocation is one unlucky session.

Example failure rates measured today (fresh random session per request): 6/10, then 6/10 an hour later — stable around 50–60% all day.

Impact

Automated agents pinned to kimi-k2.7-code fail ~half of their sessions with no recovery path, since in-session retries are routed to the same replica. We have repointed our default to kimi-k2.6 as a workaround.

Environment

• opencode-ai 1.18.18 (also reproduced with plain curl, so client version is not the variable)
• First observed 2026-08-28 ~09:00 UTC; still occurring at time of filing