MyIP

추론 토큰

생각하는 모델의 토큰은 어떻게 세고 얼마인가

일부 모델은 눈에 보이는 답을 내놓기 전에 내부적으로 "생각하는" 토큰을 먼저 생성합니다. 이런 토큰을 추론 토큰(reasoning tokens) 이라 부르고, API 는 완성 토큰이 어디에 쓰였는지 알 수 있도록 그 개수를 별도로 알려줍니다.

추론 토큰은 어떻게 청구되는가

completion_tokens_details.reasoning_tokens 로 개수가 보고되지만, 추론 토큰이 별도 항목으로 청구되지는 않습니다. 이미 completion_tokens 안에 포함되어 있고, 다른 출력 토큰과 같은 완성 단가로 청구됩니다.

cost = billable_prompt × 프롬프트 단가
     + cached_tokens    × 캐시 읽기 단가
     + completion_tokens × 완성 단가     ← 추론 토큰이 이미 여기 포함되어 있다

요금 계산 방식 을 보세요. 별도의 "추론 단가"는 없습니다 — GET /models 는 OpenAI 형상과 맞추려고 internal_reasoning 가격 필드를 돌려주지만, 우리는 항상 "0" 입니다.

정산이 끝나면 이 개수는 GET /generation 의 native_tokens_reasoning 으로도 조회할 수 있습니다.

reasoning 요청 파라미터

reasoning 은 우리 라우팅 키가 아니므로, 보내면 temperature 나 tools 처럼 받은 그대로 업스트림에 전달됩니다.

json
{
  "model": "google/gemma-4-26b-a4b",
  "messages": [{ "role": "user", "content": "..." }],
  "reasoning": { "effort": "high" }
}

우리 두 모델 다 이 파라미터를 구현하지 않으므로, 둘 중 하나가 벌어지며 그 결정은 전적으로 서빙 엔진 몫입니다 — 필드가 조용히 무시되거나, 요청이 오류로 끝납니다. 우리는 reasoning.effort / reasoning.max_tokens 를 다른 무언가로 변환하지 않고, 검증도 하지 않습니다. 추론 강도를 조절할 수 있는 게이트웨이에서 코드를 옮겨오는 중이라면, 여기서는 이 파라미터가 요란하게 오류를 내기보다 아무 효과 없이 무시될 가능성이 높다고 생각하세요 — 의존하기 전에 아래처럼 GET /models 로 확인하세요.

모델별 지원 여부 확인하기

GET /models 는 지원하는 모델에 한해 reasoning 객체를 노출합니다.

json
{
  "id": "some/future-reasoning-model",
  "reasoning": {
    "mandatory": false,
    "supported_efforts": ["high", "medium", "low"],
    "default_effort": "medium"
  }
}

추론 능력이 없는 모델은 — 지금 우리 둘 다 그렇습니다 — reasoning 이 null 입니다.

bash
curl -s "https://openrouter.myip.co.kr/api/v1/models" | jq '.data[] | {id, reasoning}'
json
{ "id": "google/gemma-4-26b-a4b", "reasoning": null }
{ "id": "lgai/exaone-4.0-32b", "reasoning": null }

reasoning: null 은 기본 동작을 추측할 근거가 아니라 "이 모델에는 reasoning 파라미터를 보내지 말라"는 뜻으로 받아들이세요.

응답에서 추론 내용 제외하기

나중에 카탈로그에 추가되는 모델이 응답에 추론 내용을 실제로 담아 보낸다면(보통 메시지의 content 옆에 reasoning 필드로), 요청에 reasoning.exclude: true 를 넣는 것이 그 내용을 응답에서 빼되 사용한 토큰은 그대로 세고 청구하도록 요청하는 관례적인 방법입니다. 이 필드 역시 검증 없이 그대로 전달되며, 실제로 지켜지는지는 그 엔진의 구현에 달려 있습니다.

추론 모델이 없는데도 이 문서가 있는 이유

두 가지입니다.

  1. 과금 경로는 이미 올바르게 처리하고 있습니다. reasoning_tokens 는 normalizeUsage() 를 거쳐, 어떤 모델이 만들었든 상관없이 가격 계산에서 completion_tokens 로 합쳐집니다 — 추론 가능한 모델이 카탈로그에 추가되는 순간에도 과금 코드는 바뀔 필요가 없습니다.
  2. 이미 reasoning 을 보내고 있을 수 있습니다. 클라이언트 코드가 여러 게이트웨이를 동시에 대상으로 하거나, openrouter.ai 문서에서 요청 본문을 그대로 가져왔다면 이미 reasoning 블록이 들어 있을 가능성이 높습니다. 그게 여기서는 아무 효과가 없다는 걸 미리 아는 것이, 요청 비용이 조용히 잘못 계산되는 것보다 낫습니다.

관련 문서

마지막 수정 2026. 9. 5.