GPT-5.5 Codex, 추론 토큰이 516에 몰리는 이상 패턴 논란

이상한 숫자 하나가 Codex 품질 논란으로 번짐

• 한 사용자가 Codex의 token_count metadata를 까봤더니, GPT-5.5 응답이 reasoning_output_tokens 정확히 516에서 비정상적으로 자주 멈추는 패턴을 발견했다고 올림

  • 분석 대상은 2026년 2월 1일부터 6월 27일까지의 응답 단위 토큰 기록 390,195건
  • 세션 수로는 865개가 포함됐고, 정확히 516 추론 토큰에서 끝난 이벤트는 3,363건
  • 작성자는 “숨겨진 사고 과정이 잘렸다는 걸 증명한다”는 주장까지는 안 감
  • 대신 “GPT-5.5에만 유독 고정 토큰 경계가 보이고, 이게 추론 예산 임계값처럼 보인다”는 좁은 주장을 하고 있음

• 제일 눈에 띄는 건 GPT-5.5의 비중이 너무 크다는 점임

  • GPT-5.5는 전체 응답의 19.3%밖에 안 되는데, 정확히 516 토큰 이벤트의 82.0%를 차지함
  • GPT-5.5에서 516 이상 쓴 응답 중 정확히 516에 걸린 비율은 44.0%
  • 반면 GPT-5.5가 아닌 모델들의 같은 비율은 1.3%라서, 대략 33.6배 차이가 남

모델별로 보면 더 수상함

• 모델별 exact 516 비율을 보면 GPT-5.5만 유독 튀는 그림임

  • GPT-5.5는 응답 75,401건에서 516 이상 응답 중 exact 516 비율이 44.0%
  • GPT-5.4는 응답 25,214건에서 19.8%
  • GPT-5.2는 응답 247,575건에서 0.34%
  • GPT-5.3-codex와 GPT-5.3-codex-spark는 둘 다 0.0%

• 작성자가 보기엔 516 하나만 문제가 아니라 1034, 1552 근처의 스파이크도 같이 보인다고 함

  • 516, 1034, 1552는 자연스럽게 퍼지는 분포라기보단 반복되는 임계값처럼 보인다는 주장
  • 그래서 reasoning budget, routing, truncation, fallback, scheduler 같은 내부 동작 가능성을 열어두고 있음

시간 흐름도 꽤 이상함

• 월별로 보면 5월부터 exact 516 클러스터링이 확 튀었음

  • 2월은 516 이상 응답 중 exact 516 비율이 0.11%
  • 3월은 2.45%, 4월은 4.25%
  • 5월은 갑자기 53.30%까지 올라감
  • 6월도 35.84%로 여전히 높음

• 그런데 같은 기간 전체 추론 토큰 강도는 줄어드는 방향이었음

  • 평균 추론 토큰은 2월 268.1개, 3월 256.8개, 4월 228.7개였음
  • 5월에는 106.9개까지 내려갔고, 6월에는 168.5개
  • 90퍼센타일도 2월 772개에서 5월 344개, 6월 515개로 낮아짐

• 이 조합이 묘함

  • 모델이 전체적으로 더 많이 생각해서 특정 값이 자주 나온 게 아님
  • 오히려 덜 생각하는 추세 속에서, 특정 숫자에 응답이 걸리는 현상이 강해진 셈
  • 복잡한 Codex 작업에서 “왜 갑자기 여기서 멈춘 것 같지?”라는 체감과 맞물릴 수 있는 지점임

그래서 뭘 확인해달라는 건가

• 작성자의 요청은 Codex 팀이 GPT-5.5 쪽 내부 동작을 확인해달라는 것임

  • 516, 1034, 1552 근처에서 응답이 끝나는 reasoning budget이 있는지
  • 특정 라우팅이나 fallback 경로가 이 토큰 경계와 연결되는지
  • 스케줄러나 degraded tier 같은 실행 환경 차이가 있는지
  • exact 516이 정상 종료인지, 예산 캡인지, 성능 저하 계층인지 설명 가능한지

• 이게 중요한 이유는 Codex 작업이 일반 챗봇 답변보다 실패 비용이 크기 때문임

  • 코드 수정, 리팩터링, 테스트 추론, 긴 디버깅은 중간 추론이 빈약하면 바로 잘못된 패치로 이어짐
  • 특히 high-stakes 작업에서 “답은 그럴듯한데 틀림”이 제일 골치 아픔
  • 관련 이슈에서는 GPT-5.5 실행이 정확히 516 reasoning tokens에서 끝나고 wrong final_answer를 반환한 재현 사례도 있었다고 언급됨

---

기술 맥락

• 여기서 중요한 선택지는 “모델이 얼마나 오래 추론하게 둘 것인가”예요. 추론형 모델은 답변 토큰만 보는 게 아니라, 답을 만들기 전에 내부적으로 쓰는 reasoning token 예산이 품질에 직접 영향을 줄 수 있거든요.

• Codex처럼 코드 작업을 맡는 에이전트에선 이 예산이 더 민감해요. 단순 질의응답이면 조금 덜 생각해도 티가 덜 날 수 있지만, 복잡한 코드베이스에서 원인 분석하고 패치까지 만들려면 중간 추론이 끊기는 순간 엉뚱한 파일을 고치거나 테스트 조건을 놓칠 수 있어요.

• 작성자가 516이라는 숫자에 집착하는 이유는 분포가 자연스럽지 않기 때문이에요. 작업 난이도가 제각각이면 추론 토큰도 넓게 퍼지는 게 보통인데, 특정 모델에서만 516, 1034, 1552 같은 경계가 반복되면 내부 예산 캡이나 라우팅 조건을 의심할 만해요.

• 다만 이 데이터만으로 “추론이 잘렸다”고 단정할 수는 없어요. token_count metadata는 현상을 보여주는 지표이지, 내부 스케줄러나 모델 런타임의 원인을 직접 보여주진 않거든요. 그래서 이 이슈의 포인트는 결론보다 검증 요청에 가까워요.