나는 북마크 바에 OpenAI Codex 릴리스 노트(release notes)를 담은 작은 폴더를 보관하고 있는데, 이번 주에 거의 놓칠 뻔한 조용한 소식을 발견했다. sayan-oai에 의해 7월 18일 release/0.144 브랜치에 병합된 PR 33972는 번들링된 모델 메타데이터(model metadata)의 컨텍스트 윈도우(context-window) 수치를 372,000 토큰에서 272,000 토큰으로 낮추었다. 이는 Codex 내부의 gpt-5.6-sol에 대해 광고된 용량이 약 27% 감소했음을 의미한다. 해당 PR의 제목은 "Backport refreshed bundled model metadata to 0.144"로 지루하게 들리며, 변경 사항(diff)은 단일 JSON 메타데이터 파일에 대해 64개의 추가와 54개의 삭제가 이루어졌다. 공정하게 말하자면, JSON은 번들링된 설정(bundled-config) 수치이지 서버 측 강제 제어 노브(enforcement knob)가 아니므로 이 27%라는 수치를 액면 그대로 믿기에는 주의가 필요하지만, 실질적인 해석은 372k를 윈도우로 여전히 주장하는 모든 하네스(harness)가 이제 틀렸다는 것이며, 0.144.6 버전에 대한 OpenAI 자체의 Codex 릴리스 노트 또한 제한이 272k로 돌아갔음을 확인해 준다.

내가 주목했고 이곳에 기록하고자 하는 관점은, Codex 외부의 하네스들이 여전히 이전의 372k 수치로 설정되어 있는 동시에 이러한 축소가 일어나고 있다는 점이다. Kun Chen의 7월 13일 자 X 포스트는 이 문제를 직접적으로 지적했다: "gpt 5.6을 사용 중이지만 Codex를 통하지 않는 경우를 위한 중요한 팁입니다. OpenAI는 방금 272k 토큰을 초과하는 요청에 대해 과다 청구된다는 점을 시사했습니다. 현재 많은 하네스가 gpt 5.6의 컨텍스트 윈도우를 372k로 설정하고 있어, 예상보다 더 빠르게 할당량(quota)을 소진하게 될 것입니다". 그의 구체적인 해결책은 Pi에게 gpt-5.6 컨텍스트 윈도우를 272k로 변경하라고 말하는 것이었다. Reddit의 r/codex 스레드에서도 같은 날 90개의 추천과 83개의 댓글과 함께 이 소식이 다뤄졌으며, 대부분의 엔지니어들은 하네스의 기본값이 여전히 372k라는 사실을 전혀 몰랐다고 말했다. 동일한 채널에서의 OpenAI의 답변은 "너프(nerfing)는 없습니다, 좋은 소식뿐입니다!"라고 표현하며, Sol 구독에 적용되는 추론 최적화(inference optimizations)를 통해 사용량이 10% 증가했다는 내용을 덧붙였다. 내 직감으로는 두 가지 모두 동시에 사실일 수 있다고 본다. 즉, 추론 비용 절감은 실제이며, 오래된 하네스들은 372k 안에 들어간다고 생각하지만 실제로는 그렇지 않은 요청들에 대해 여전히 과다 청구하고 있다는 것이다.

제가 이 내용을 기록하려는 이유는 이번 분기에 출시할 프로젝트들을 위해 gpt-5.6-sol을 Codex와 몇몇 비-Codex (non-Codex) 하네스(harnesses)를 통해 모두 실행하고 있기 때문입니다. 6월 말에 읽었던 피킹 라운드업(picking roundups)들이 여전히 Sol의 헤드라인 수치로 372k를 인용하고 있었기에, 저는 제 컨텍스트 윈도우 (context-window) 설정이 올바르다고 가정해 왔습니다. IDE 워크플로우와 코드 생성 능력을 S/A/B/D 등급과 10점 만점에 9.6점 식의 소수점 점수로 순위를 매기는 피킹 라운드업 (picking-roundup) 프레임워크에는 마케팅된 윈도우 대비 실제 설정된 윈도우를 나타내는 열(column)이 없습니다. 또한 Gemini Pro를 월 19.99달러, ChatGPT Plus를 20달러, Claude Pro를 20달러로 책정하는 가격 가이드 (pricing-guide) 프레임워크에는 gpt-5.6의 과다 청구 차액 (over-charge delta)을 나타내는 행(row)이 없습니다. 제가 이달 초에 작성했던 포맷 대 포맷 드리프트 (format-vs-format drift) 현상이, 이제는 포맷이 윈도우 크기가 아닌 등급(tier)과 가격($)을 기준으로 분류하기 때문에, 해당 포맷이 측정할 수 없는 토큰 과금 (token-billing) 변경 사항과 같은 주에 나타나고 있습니다.

제가 기록하고자 하는 실질적인 교훈은, 오늘 아침 제 하네스들을 직접 점검해 본 결과 여전히 372k로 설정된 Pi 구성 하나와 프롬프트에서 여전히 이전 윈도우를 주장하고 있는 Cursor 측 에이전트 루프 (agent loop) 하나를 발견했으며, 두 가지 모두 272k로 변경했다는 점입니다. 솔직히 말해서, 대부분의 엔지니어들이 피킹 스코어카드 (picking scorecards)를 통해 이러한 변화를 알아차릴 수 있을지에 대해서는 다소 회의적입니다. 왜냐하면 스코어카드는 설정된 윈도우가 아니라 채팅 품질과 가격 등급을 측정하며, 과다 청구는 눈에 보이는 오류라기보다는 할당량 소모 (quota burn)가 약간 더 빨라지는 형태로 나타나기 때문입니다. 만약 gpt-5.6-sol을 Codex 자체가 아닌 다른 것을 통해 실행하고 있다면, 동반된 PR 34009와 릴리스 태그 (release tag) rust-v0.144.6을 북마크해 둘 가치가 있습니다.

저는 3개월 후에 다시 평가할 것입니다. 현재로서는 제가 다루는 모든 gpt-5.6-sol 하네스(harness)를 272k로 설정해 두었으며, 각 하네스가 어떤 윈도우 번호(window number)로 구성되어 있는지에 대한 하네스별 로그를 기록하기 시작했습니다. 왜냐하면 피킹 라운드업(picking roundups)에서는 이 내용이 드러나지 않을 것이기 때문입니다. 6개월 정도 지나면, 피킹 라운드업에 구성된 윈도우(configured-window) 컬럼이 추가되거나, Codex가 방금 한 것처럼 하네스 벤더들이 272k를 기본값으로 고정(pinning)하기 시작할 것으로 예상합니다. 그중 무엇이 먼저 일어나느냐에 따라, 마케팅된 윈도우(marketed window)와 구성된 윈도우(configured window)가 성적표(scorecard)에서 아무도 알아채지 못한 채 단일 분기 내에서 어긋날 수 있다는 사실을 해당 포맷이 마침내 인지했는지 여부를 알 수 있을 것입니다.