Kimi Code、日常開発向けに K3-256k を推奨モデルとして追加

導入

Kimi Code のモデル構成ページが更新され、Kimi K3 の 256k コンテキスト版である k3-256k が推奨モデルとして案内されています。これは、最大 1M コンテキストを扱う k3 に対し、より一般的な開発作業に合わせて消費を抑える選択肢です。公式説明では、256k の範囲内であれば K3 と同じ結果を提供し、1M 版と比べて使用量を大きく抑えられるとされています。

主なポイント

• 4つのモデル ID：現在の Kimi Code には k3、k3-256k、kimi-for-coding、kimi-for-coding-highspeed が用意されています。k3 は条件を満たすプランで最大 1M コンテキスト、k3-256k は固定で 256k です。
• 日常的なコーディングに最適化：k3-256k は日常の Q&A、コード補完、通常の機能開発、単一ファイルまたは小規模な複数ファイル編集に向いていると説明されています。ただし、対応するマルチモーダル入力は画像のみで、動画は使えません。
• 切り替え時は compact に注意：すでに 256k を超えるセッションを k3 から k3-256k に切り替える場合、CLI や一部ツール側で compact が実行される可能性があります。重要情報を残すため、手動で compact してから切り替えることが推奨されています。
• キャッシュ無効化による消費増：モデル ID や reasoning effort を変えると、既存のコンテキストキャッシュが使えなくなります。そのため、切り替え直後は再プリフィルにより使用量が増えたように見える場合があります。
• 権限と設定ミスも要因：K3 や 1M、HighSpeed の利用はプランに依存します。また、API や外部ツールではモデル名ではなく正しいモデル ID を指定する必要があります。

意味と影響

今回の更新は、単なるモデル追加ではありません。長大な 1M コンテキストと、日常開発で必要な 256k コンテキストを明確に分ける動きです。大規模リポジトリの把握や長い会話履歴には 1M が有効ですが、多くのコーディング支援ではそこまでの長さを必要としません。

開発者にとっては、普段は k3-256k を使い、必要な場面だけ k3 に切り替える運用が現実的です。同時に、セッションの作り直し、compact、reasoning effort の固定、動画入力の有無、外部ツールのコンテキスト設定といった細部が、コストと安定性を左右することになります。

出典：Hacker News