Kimi K2.6 API, K2.5, K2 Thinking: 코드에는 어떤 모델 ID를 써야 할까

새로운 공식 Kimi API 연동을 만든다면 model에는 먼저 kimi-k2.6을 넣는 것이 가장 안전합니다. kimi-k2.5는 K2.5 동작을 보존해야 하는 호환성 테스트, 기존 벤치마크, provider별 이전 경로가 있을 때만 남깁니다. kimi-k2-thinking은 별도의 오래된 전용 thinking 모델 ID로 보아야 하며, K2.6에 thinking을 켠다는 의미의 임의 별칭이 아닙니다. OpenAI 호환 SDK 예제, provider 경로, 무료 API 안내, kimi-k2.6-thinking 같은 표기는 유용한 단서일 수 있지만 공식 Kimi/Moonshot 모델 계약을 대신하지 않습니다.

이 주제의 핵심은 “어떤 모델이 가장 좋나”가 아니라 “내 코드와 문서의 책임자가 누구인가”입니다. 공식 API의 모델 ID는 Kimi/Moonshot이 책임지고, provider alias는 해당 provider가 책임지며, thinking 동작은 요청 설정과 응답 처리의 문제입니다. 세 층을 섞으면 샘플은 돌아가도 production runbook, 비용표, 장애 대응 문서가 틀어집니다.

Kimi 모델 ID 라우팅 표. K2.6 기본 경로, K2.5 호환 경로, K2 Thinking, 오래된 K2 문자열 점검을 구분한다

실제 필요	먼저 사용할 값	이유	production 전 확인
새 공식 Kimi API 연동	`kimi-k2.6`	공식 K2.6 quickstart의 현재 모델 ID	모델 목록, 가격, context, 계정 제한
K2.5 비교나 호환성 유지	`kimi-k2.5`	K2.6 오타가 아니라 별도 모델	테스트가 실제로 K2.5 동작을 요구하는지
전용 thinking 모델 호출	`kimi-k2-thinking`	K2.6 alias가 아닌 독립 모델 ID	reasoning 출력, tool-call 처리, max tokens
provider 또는 무료 API 경로	provider 고유 alias	해당 provider 경로만 증명	가격, 제한, 모델 동일성, 데이터 정책, 무료 조건

첫 결정은 모델 ID입니다

Kimi K2 계열 이름은 서로 너무 가까워서 쉽게 섞입니다. K2.6은 최신 공식 API처럼 보이고, K2.5는 이전 버전처럼 보이며, K2 Thinking은 reasoning 모드처럼 들립니다. 그러나 API 요청은 계열 이름을 받지 않습니다. 정확한 model 문자열, base URL, 인증, 파라미터, 응답 스키마를 받습니다.

새 공식 연동의 기본값은 kimi-k2.6입니다. 공식 K2.6 quickstart는 OpenAI 호환 클라이언트 형태를 사용하며 base URL은 https://api.moonshot.ai/v1입니다. 이 말은 기존 저장소의 K2 문자열을 모두 자동 치환하라는 뜻이 아닙니다. 새 기능이 “현재 공식 Kimi 모델을 쓰겠다”는 요구라면 오래된 model string에서 시작하지 말라는 뜻입니다.

kimi-k2.5는 아직 의미가 있습니다. 기존 평가 결과와 비교해야 하거나, K2.5에 맞춰진 테스트를 보존해야 하거나, 특정 provider가 아직 K2.6 경로를 제공하지 않는다면 남겨 둘 수 있습니다. 다만 그 이유를 config 주석, runbook 또는 평가 문서에 기록해야 합니다. 이유가 없으면 다음 개발자는 이것이 의도된 호환성인지 낡은 default인지 알 수 없습니다.

kimi-k2-thinking은 더 좁은 경로입니다. 이것은 독립 모델 ID입니다. K2.6이나 K2.5에서 thinking behavior를 다루려면 request settings, reasoning fields, tool-call continuity를 확인해야 합니다. provider 문서에 kimi-k2.6-thinking처럼 보이는 문자열이 있어도, 공식 모델 목록에서 확인되지 않으면 공식 ID로 쓰면 안 됩니다.

공식 API 경로가 모델 정체성을 책임집니다

모델 ID, 가격, context window, parameter behavior, retirement note는 공식 Kimi/Moonshot API가 가장 강한 출처입니다. provider 페이지는 빠른 진입점을 줄 수 있지만, 공식 모델 목록의 대체물이 아닙니다. SDK 사용법과 endpoint가 먼저 눈에 들어오더라도, 코드가 어느 route owner를 따르는지 문서에 드러내야 합니다.

최소 호출은 경로를 숨기지 않아야 합니다.

hljs ts
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.KIMI_API_KEY,
  baseURL: "https://api.moonshot.ai/v1",
});

const response = await client.chat.completions.create({
  model: "kimi-k2.6",
  messages: [
    { role: "user", content: "Summarize the routing risk in this Kimi setup." },
  ],
});

console.log(response.choices[0]?.message);

처음에는 이 정도가 좋습니다. 계정, API key, base URL, model string이 공식 경로에서 작동하는지 확인한 뒤 tool calls, streaming, multimodal input, 긴 context, provider proxy, retry layer를 추가합니다. 공식 호출은 성공하지만 provider 경로가 실패한다면, 문제는 Kimi의 모델 계약이 아니라 provider alias, billing, rate limit, capability wrapper, data policy일 가능성이 큽니다.

2026년 5월 8일 기준 공식 platform은 K2.6과 K2.5를 256K context multimodal models로 표시했고, K2.6 가격은 cache hit $0.16/MTok, input $0.95/MTok, output $4.00/MTok, K2.5 가격은 cache hit $0.10/MTok, input $0.60/MTok, output $3.00/MTok로 표시했습니다. 이는 날짜가 붙은 사실입니다. 예산, 고객 문서, 내부 pricing note에 쓰기 전에는 현재 공식 페이지에서 다시 확인해야 합니다.

K2 Thinking과 thinking 동작을 구분해야 합니다

Kimi thinking 요청 흐름. 모델 선택, thinking 설정, reasoning content, tool calls, max token 확인을 보여준다

“thinking”이라는 단어는 두 층에서 쓰입니다. 하나는 kimi-k2-thinking이라는 전용 모델 ID입니다. 다른 하나는 K2.6 또는 K2.5 경로에서 reasoning output과 tool calls를 어떻게 처리하느냐입니다. 두 층을 하나로 취급하면 모델 선택도 잘못되고 응답 처리도 깨질 수 있습니다.

층	의미	코드 영향
`kimi-k2-thinking`	오래된 전용 K2 thinking 모델 ID	필요할 때만 `model` 필드에 직접 지정
K2.6/K2.5의 thinking behavior	현재 모델 경로의 요청 및 응답 처리	reasoning fields와 tool-call continuity를 보존

thinking guide가 중요한 이유는 marketing 문구 때문이 아닙니다. 응답에는 reasoning_content가 포함될 수 있고, tool-call workflow는 reasoning content를 다음 메시지로 이어 가야 할 수 있습니다. streaming, temperature, max token 설정도 결과 안정성에 영향을 줍니다. wrapper가 비표준 필드를 버리거나 중간 메시지를 요약하거나 tool-call replay를 바꾸면, 모델 성능 문제가 아니라 통합 문제가 됩니다.

따라서 production 문서에는 다섯 가지를 적는 편이 낫습니다. 정확한 model ID, thinking 상태, reasoning_content 보존 여부, tool-call message replay 방식, max token 예산입니다. 이렇게 하면 “K2 Thinking이 좋은가”가 아니라 “우리 호출 경로가 의도한 reasoning 동작을 보존하는가”를 점검할 수 있습니다.

오래된 K2 문자열은 마이그레이션 규칙으로 처리합니다

공식 모델 목록에는 오래된 kimi-k2 계열에 대한 retirement note가 있었습니다. 이것은 K2.5와 K2.6이 사라졌다는 뜻이 아닙니다. 기존 config, wrapper, 예제, provider alias, 평가 스크립트를 정확히 스캔해야 한다는 뜻입니다.

점검 위치	볼 것	조치
환경 변수	`KIMI_MODEL`, `MODEL_ID`, provider alias	route owner를 정한 뒤 변경
SDK wrapper	default model string, hidden fallback	default를 명시하고 selected model을 로그에 기록
평가 스크립트	K2.5 label, K2 Thinking baseline	비교에 필요하면 이유와 함께 유지
provider config	hosted alias, platform model path	공식 ID와 별도 mapping으로 관리
문서	“latest K2”, “K2 API” 같은 모호한 표현	정확한 model string과 checked date로 교체

안전한 규칙은 간단합니다. 새 공식 연동은 K2.6을 기본값으로 둡니다. 기존 테스트는 의도가 있을 때만 보존합니다. 오래된 K2 문자열은 route owner를 확인한 뒤 바꿉니다. 전역 치환은 빠르지만 benchmark를 망칠 수 있고, 아무것도 하지 않으면 stale default가 남습니다.

provider와 무료 API 주장은 경로별로 검증합니다

Kimi API provider 경로 검증 체크리스트. alias, billing, limits, tool support, data policy, free claims를 확인한다

provider 경로는 실제로 유용할 수 있습니다. 특정 클라우드 런타임, worker platform, 통합 결제, OpenAI 호환 endpoint, regional route, 낮은 진입 장벽이 필요할 수 있습니다. 그러나 provider가 제공하는 것은 그 provider의 계약입니다. 공식 Kimi 모델 목록을 대체하지 않습니다.

의존하기 전에 다음 층을 확인합니다.

주장	확인할 곳	이유
모델 동일성	provider docs와 공식 Kimi docs	provider alias가 공식 model ID와 다를 수 있음
가격과 결제	provider pricing page	단가, 무료 크레딧, minimum, billing owner가 다름
context와 limits	provider model card 또는 dashboard	hosted route의 practical limit이 다를 수 있음
tool, vision, JSON, streaming	provider capability docs	기능 wrapper가 일부만 지원할 수 있음
data policy	provider terms와 product docs	공식 모델 이름만으로 데이터 처리를 설명할 수 없음
무료 API	현재 route owner 페이지	free, unlimited, no-ban, guarantee claims는 빨리 바뀜

무료 Kimi K2.6 API라는 제목은 검증할 단서로만 읽어야 합니다. 작은 실험에는 도움이 될 수 있습니다. 그러나 production code, 고객 문서, 비용 약속, 안정성 주장에는 route owner의 현재 증거가 필요합니다. 증거가 없다면 무료, 무제한, 차단 없음, 환불, 안정성, 실패 보장 같은 표현은 쓰지 않습니다.

Kimi가 Claude를 대체할 수 있는지는 다른 평가입니다

일부 독자는 K2.6을 Claude Code나 Opus workflow 대체 후보로 봅니다. 그 비교는 중요하지만 모델 ID 선택과 다른 문제입니다. Kimi route 결정은 kimi-k2.6, kimi-k2.5, kimi-k2-thinking, 공식 base URL, provider alias, thinking handling을 정리하는 일입니다.

Claude 대체 여부는 같은 repository task, coding reliability, tool use, agent loop, latency, cost, failure recovery, human review까지 비교해야 합니다. benchmark 흥미만으로 config의 모델 문자열을 바꾸면, 모델 비교가 아니라 라우팅 오류가 됩니다.

경계는 이렇게 잡으면 됩니다.

Kimi model string을 고를 때는 route table을 사용합니다.
Claude workflow 대체 가능성을 보려면 같은 작업으로 별도 benchmark를 실행합니다.
provider를 쓸 때는 모델 비교 전에 provider route를 확인합니다.
production docs에는 official model ID와 route owner를 함께 씁니다.

production 전 체크리스트를 남기세요

최종 설정은 저장소나 runbook에 남아 있어야 합니다.

필드	좋은 기록
공식 target	`kimi-k2.6`, `kimi-k2.5`, `kimi-k2-thinking`과 선택 이유
API owner	Kimi/Moonshot official API 또는 특정 provider route
Base URL	`https://api.moonshot.ai/v1` 또는 provider endpoint
Checked date	모델 목록, 가격, context, limits를 확인한 날짜
Thinking behavior	off, on, default, dedicated model route
Reasoning handling	client가 `reasoning_content`를 보존하는지
Provider caveat	alias, billing, limits, capabilities, data policy
Stop rule	owner proof 없이 free, unlimited, no-ban, guarantee를 쓰지 않음

이 표는 단순하지만 운영에 강합니다. 몇 주 뒤 누군가 모델을 바꿔야 할 때, 그 문자열이 공식 추천인지, K2.5 호환성인지, provider 제한인지, 복사된 예제인지 바로 확인할 수 있습니다.

FAQ

새 Kimi API 프로젝트는 `kimi-k2.6`을 쓰면 되나요?

공식 Kimi API를 사용하고 K2.5 호환성, 전용 kimi-k2-thinking, provider alias 이유가 없다면 그렇습니다. 먼저 kimi-k2.6을 쓰고 현재 모델 목록, 가격, context, limits를 재확인합니다.

`kimi-k2-thinking`은 K2.6 thinking mode와 같은가요?

아닙니다. kimi-k2-thinking은 별도 모델 ID입니다. K2.6이나 K2.5의 thinking behavior는 request settings와 response handling의 문제입니다.

Kimi K2.5를 아직 테스트할 이유가 있나요?

있습니다. K2.5 behavior, 기존 benchmark, provider compatibility가 필요하다면 유지할 수 있습니다. 하지만 새 공식 API 연동의 default로 둘 때는 이유를 문서화해야 합니다.

무료 Kimi K2.6 API를 production에 써도 되나요?

route owner가 무료 범위, 제한, data terms, 모델 동일성, 가용성을 현재 증명할 때만 낮은 위험의 실험으로 검토할 수 있습니다. 증거 없이 무료, 무제한, 차단 없음, 환불, 안정성, 보장을 전제로 삼지 마세요.

오래된 `kimi-k2` 설정은 어떻게 처리하나요?

config, wrapper, example, provider settings를 확인합니다. 새 공식 route는 K2.6으로, K2.5 평가는 이유와 함께 유지하고, kimi-k2-thinking은 전용 모델로만 유지하며, provider alias는 별도 mapping으로 관리합니다.