feat: add priority service tier controls

[kassieclaire]

Related Issue

Related to #1674

Related to #568

Problem

Some providers offer a priority service tier with provider-dependent pricing, latency, and reliability, but Kimi Code could not request it. Main-agent and subagent requests also need independent control: a subagent may intentionally use a different tier even when it inherits the main model, and priority must remain disabled by default.

What changed

• Add a /priority choice dialog with four states: main agent and subagents, main agent only, subagents only, and neither.
• Configure main-agent and subagent priority independently, including when no separate subagent model is set, and apply changes to already-running subagents.
• Thread service_tier: "priority" through both agent engines and the Kimi, OpenAI Chat Completions, and OpenAI Responses provider paths.
• Show priority after the model and thinking effort in the v1/v2 footer and /status, and in single-subagent cards and swarm headers according to each subagent's own tier.
• Expose priority through the SDK session status/control surface and verbose request metadata.
• Document the command and status display in English and Chinese, add focused coverage, regenerate v2 manifests, and add a CLI minor changeset.

v1 engine demo

v2 engine demo

Both demos were captured from the locally built source override with verbose logging enabled. I inspected the picker and final status-line frames, then downloaded both hosted GIFs and verified that their SHA-256 hashes exactly match the local captures.

Live provider verification

Built the CLI from this branch, replaced the local kimi launcher with that build, and ran llmgateway/kimi-k3 with verbose logging enabled.

• A priority request logged serviceTier=priority; the response reported service_tier=priority and model=fireworks/kimi-k3, confirming the expected Fireworks route.
• A priority follow-up remained on Fireworks and reported 15,360 cached tokens out of 15,455 prompt tokens, including the cached-input cost signal.
• Turning priority off before the next follow-up preserved the client session/cache identifiers, but the gateway selected Moonshot instead of Fireworks. Provider stickiness across a tier change is therefore gateway behavior; this client continues the same session while sending the tier selected for each request.

Automated verification

• pnpm run typecheck — passed across all packages and applications on Node 24.15.0 / pnpm 10.33.0.
• pnpm run lint — passed with 0 errors and 2,703 warnings.
• pnpm --filter @moonshot-ai/agent-core-v2 lint:imports — passed for 1,042 files.
• Focused status-display and event-propagation suites — 288 tests passed across the TUI, SDK, and both agent engines.
• Targeted provider and original feature suites — 182 tests passed.
• Status, generated-manifest, and swarm regression rerun — 194 tests passed.
• Plugin and telemetry failure rerun after installing the suite's missing zip dependency — 54 of 55 tests passed; the sole residual failure is the unrelated packages/minidb/test/server-extra.test.ts oversized-request socket timeout, which also reproduces when run alone.
• pnpm exec changeset status --since main — validated the CLI minor changeset.
• pnpm --dir docs run build — passed with existing ES2024 and chunk-size warnings.
• pnpm --dir apps/kimi-code run build — passed and supplied the executable used for both demos.

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue, or explained the problem above.
• I have added tests that prove my feature works.
• Ran gen-changesets skill, or this PR needs no changeset.
• Ran gen-docs skill, or this PR needs no doc update.

[changeset-bot]

🦋 Changeset detected

Latest commit: b8aecc8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@moonshot-ai/kimi-code	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR