Kimi K3-256k

• Kimi Code 모델 구성: Kimi K3와 Kimi K2.7 Code를 4개 Model ID로 제공하며, 클라이언트나 서드파티 도구에서 ID를 지정해 전환 가능

  • k3-256k는 256k context에서 k3와 같은 결과를 내면서 quota 소비를 사실상 절감하는 일상용 모델로, Q&A·코드 완성·일반 기능 개발·단일 또는 소규모 파일 수정에 적합함

  • k3는 최대 1M context를 지원하지만 k3-256k보다 quota를 약 2배 소비하며, k3-256k는 video input 미지원

💓 알림 K3 (1M)에서 K3-256k로 전환: 현재 session의 context가 이미 256k를 넘었다면 Kimi Code CLI와 Claude Code 같은 일부 coding tool이 자체적으로 compact를 수행함 전환 권장 사항: (1) agent tool마다 처리 방식이 다르므로 전환 전에 compact를 한 번 직접 실행해 context를 256k 이내로 압축하는 편이 좋음. 과업의 핵심과 session을 유지하면서 전환 후 quota를 더 오래 사용 가능 (2) 대화 기록에 video file이 있으면 K3-256k가 video input을 지원하지 않아 직접 전환에 실패함. 먼저 compact한 뒤 전환 필요

• 모델별 핵심 차이:

• 더 높은 plan에서 모델·context window·속도가 추가로 열리며 plan 업그레이드 가능

  • k3-256k에서 256k 한도에 가까워졌을 때 compact로 인한 정보 손실을 피하려면 k3 (1M)로 바로 전환 가능하며, 현재 버전에서는 256k→1M 전환이 cache에 영향을 주지 않음

• 전환 시 소비량과 오류 조건: Model ID나 reasoning effort를 바꾸면 기존 context cache가 무효화돼 context를 다시 prefill하므로 직후 사용량이 늘어날 수 있음

  • 새 모델은 새 session에서 시작하고, 한 session 안에서는 task에 맞는 reasoning effort를 일관되게 유지하는 편이 소비량 절감에 유리

  • plan 권한을 넘는 요청은 401 반환: Moderato 미만은 k3·k3-256k 사용 불가, Moderato의 k3는 최대 256K이며 최대 1M은 Allegretto 이상에서 제공, HighSpeed도 Allegretto 이상 필요

  • 전체 오류와 처리 방법은 Error Reference에서 확인 가능

• HighSpeed 제한: 정확한 ID는 kimi-for-coding-highspeed이며, 잘못 입력하면 오류 없이 표준 kimi-for-coding으로 fallback돼 속도 향상이 사라짐

  • HighSpeed가 가속하는 범위는 model output뿐이며 파일 읽기·쓰기, command 실행 같은 tool call과 script 실행 속도에는 영향 없음

• 모델 전환 방법: 호출에는 version 이름이 아닌 k3, k3-256k, kimi-for-coding, kimi-for-coding-highspeed 중 하나의 Model ID를 사용해야 하며, Kimi K3나 K2.7 Code를 넣으면 호출 실패

  • K3 또는 K2.7에서 Thinking을 끄면 K2.6으로 routing되므로 Thinking 유지 필요

  • Kimi Code CLI는 /model로 전환하며 최신 모델이 없으면 /logout 후 /login, VS Code는 입력창 dropdown에서 선택하며 없으면 VS Code 재시작 또는 extension 재설치

  • 서드파티 도구는 Kimi Code Console에서 API Key 생성 후 Base URL과 Model ID 입력

    • OpenAI compatible: https://api.kimi.com/coding/v1

    • Anthropic compatible: https://api.kimi.com/coding/

• 서드파티 K3 설정: 일부 도구의 기본 context window가 1M보다 작으므로 최대 1M을 쓰려면 context-window를 1048576으로 직접 설정해야 함

  • K3의 reasoning effort는 low / high / max를 지원하며, 도구가 보내는 effort는 다음 규칙으로 mapping됨

# default
null / undefined → high
any other unknown → HTTP 400 error

# → max
ultra / max / xhigh → max

# → high (recommended)
high / medium → high

# → low
low / minimum / light → low

# → thinking disabled
none → thinking.type disabled

^{source https://www.kimi.com/code/docs/en/kimi-code/models}

HN에서는 256K가 일상적인 코딩에 충분한지, 장시간 이어지는 에이전트 작업에는 1M이 필요한지를 두고 평가가 갈렸다. 평소 컨텍스트를 100K~200K 이하로 관리하는 개발자들은 256K 안에서 같은 결과를 내면서 할당량을 절반가량만 쓰는 구성을 반겼다. 이들에게 1M은 상시 사용할 기본값이 아니라, 긴 작업에서만 꺼내는 선택지다.

평가는 작업 방식에 따라 달라졌다. 변경 범위를 잘게 나눠 패치 단위로 처리하면 256K로도 속도와 비용을 모두 잡을 수 있다. 반면 대규모 리팩터링이나 긴 설계 과정, 여러 하위 에이전트의 검토와 방대한 사전 조사까지 한 세션에 유지하면 이야기가 달라진다. 이 경우 잦은 압축으로 맥락을 잃을 수 있어 256K가 오히려 비효율적이라는 경험도 나왔다. 저장소 크기보다 한 세션에 얼마나 많은 이력과 근거를 계속 보존해야 하는지가 중요하다.

최대 컨텍스트를 낮추면 세션마다 확보할 메모리가 줄어 같은 하드웨어로 더 많은 요청을 처리할 수 있다는 설명도 설득력을 얻었다. 다만 이번 변경만으로 별도 양자화나 성능 저하를 단정할 근거는 없다. 공개된 정보가 확인해 주는 것은 컨텍스트 한도와 할당량 차이다.

실무적으로는 256K에서 시작해 한계에 가까워질 때 캐시를 유지한 채 1M으로 전환할 수 있다는 점이 핵심이다. 모델을 고를 때는 최대 수치만 볼 일이 아니다. 사용하는 도구가 컨텍스트를 얼마나 효율적으로 관리하는지, 압축 과정에서 핵심 정보가 보존되는지, 장기 세션이 실제 업무에서 얼마나 자주 필요한지를 함께 따져야 한다.