# OpenAI, Codex 모델 컨텍스트 크기를 372k에서 272k로 축소 > Clean Markdown view of GeekNews topic #31611. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31611](https://news.hada.io/topic?id=31611) - GeekNews Markdown: [https://news.hada.io/topic/31611.md](https://news.hada.io/topic/31611.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-20T12:33:20+09:00 - Updated: 2026-07-20T12:33:20+09:00 - Original source: [github.com/openai](https://github.com/openai/codex/pull/33972/files) - Points: 1 - Comments: 1 ## Topic Body - OpenAI Codex의 **번들 모델 메타데이터**를 갱신하면서 모델 컨텍스트 크기를 372k에서 272k로 줄인 변경을 `release/0.144` 브랜치에 백포트함 - PR #33972는 `agent/hotfix-0.144-model-metadata` 브랜치에서 **Codex 0.144 릴리스**로 변경 사항을 옮김 - 변경 범위는 JSON 파일 1개이며, diff 통계는 **64줄 추가·54줄 삭제**임 - 별도 대화나 리뷰 내용 없이 1개 커밋과 **36개 검사**를 거쳐 병합됨 - 제공된 페이지에서는 파일 diff가 로드되지 않아 컨텍스트 축소 외의 구체적인 메타데이터 변경 사항은 확인할 수 없음 --- ### 변경 목적과 범위 - PR 제목은 **갱신된 번들 모델 메타데이터**를 Codex 0.144에 백포트하는 작업임 - Hacker News 제목에 따르면 모델 컨텍스트 크기가 **372k에서 272k**로 축소됨 - 대상 브랜치는 `openai:release/0.144`, 소스 브랜치는 `sayan-oai:agent/hotfix-0.144-model-metadata`임 ### 병합 결과 - PR #33972는 **1개 커밋** `b06f4fa`로 구성됨 - 커밋 제목은 `Backport refreshed bundled model metadata`임 - 2026년 7월 18일 병합됐으며, **36개 검사**와 파일 1개 변경이 표시됨 - 변경량은 64줄 추가와 54줄 삭제이고 파일 형식은 JSON임 ### 확인 가능한 한계 - 페이지의 파일 및 댓글 영역이 로드 오류를 보여 **실제 JSON diff**는 제공된 본문에서 확인할 수 없음 - 재현 절차, 변경 이유, 호환성 영향, 리뷰 피드백 등은 본문에 포함되지 않음 ## Comments ### Comment 62077 - Author: neo - Created: 2026-07-20T12:33:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48965850) - 압축하면 해결된다고들 하지만, 내가 하는 작업에서는 **압축으로 사라지는 세부 정보**가 지나치게 많음 계획이 단순하거나 아주 세세한 논의를 하지 않는다면 괜찮을 수 있지만, 긴 컨텍스트가 부족한 탓에 결국 Anthropic을 계속 사용하게 됨 여러 논문이나 크고 복잡한 자료를 온전히 기억해야 할 때는 컨텍스트가 늘 16%에 머무름. 5분쯤 대화하면 압축되고, 다시 자료를 읽혀 16%에 도달하는 과정이 반복됨 **372k 컨텍스트**도 완벽하지 않았지만 12~20%였던 여유를 약 40%로 늘려줘 큰 도움이 됐음 - **자동 압축을 끌 수 없고** 압축 전 대화 기록으로 돌아갈 수도 없어, 5천 줄이 넘는 코드베이스에서는 Codex를 쓸 수 없음 남은 컨텍스트가 10~20%일 때 무작위로 실행되므로 272k의 80%만 실질적으로 사용 가능함. 압축 뒤 환각이 심해져 처음부터 시작하는 것보다 못하고, 코드베이스를 다시 읽다가 또 압축되는 순환에 빠짐 - 내 설계 과정은 다름. 여러 차례 수정하는 **plan.md가 곧 메모리**이며, 세션을 재시작해 계획을 다시 읽고 검토하면 새로운 관점을 얻기 좋음 - 압축이 형편없어서 LLM이 컨텍스트 일부를 선택적으로 삭제하고 필요할 때 복원하게 해주는 도구를 만들었음. 자동 압축 한계에 자주 닿는다면 **context bonsai**를 써볼 만함 [https://github.com/Vibecodelicious/context-bonsai-agents]() - Anthropic 모델은 **100만 토큰 컨텍스트**를 제공함. 다음 달 OpenAI로 옮기려 했는데 아직 약 300k에 머물러 있다니, 새로운 현실에 적응해야 할 듯함 - 보통 에이전트가 가끔 `.md` 파일을 만들거나 갱신해 새로 나타난 중요 정보를 기억하게 하라고 권함. 하지만 무엇이 정말 중요한지 에이전트가 정확히 안다면 **`/compact`도 잘 작동해야 함** - 큰 컨텍스트 창 때문에 무엇을 넣을지 선별하지 않게 됐고, 압축은 전체에 **손실 압축**을 한꺼번에 적용해 필요한 세부 정보까지 잃게 만듦 매번 전체 대화를 재전송하는 것 자체가 근본적인 문제라고 봄. 내가 만든 메모리·컨텍스트 플러그인으로 매 차례 컨텍스트를 비우고 관련 정보만 다시 주입하니, 모델이 20만 토큰의 대화 기록 대신 선별된 수천 토큰의 상태만 읽게 되어 작은 컨텍스트가 문제 되지 않았음 코딩 에이전트에서는 아직 해결하지 못했지만, 작업 완료나 다음 작업에 필요한 것만 유지하고 나머지는 버리는 **보존 정책**이 진짜 해법이며 전용 LLM으로 구현할 수 있다고 봄 - LSTM과 GRU 등을 연구한 많은 자연어 처리 전문가도 전체 대화 재전송을 근본적인 문제로 봤지만, 실증적으로는 **Transformer가 승리**했음 미래 모델 구조가 이 문제를 다시 고려할지 흥미로움. 인간을 기준으로 보면 아직 부족한 것은 단기 기억에서 장기 기억으로 정보를 효율적으로 옮기는 능력이며, 미세 조정이 원리상 비슷한 일을 하지만 효율적이지 않음 - 이 변경의 이유인지는 모르겠지만, 애초에 이보다 큰 컨텍스트를 쓰는 것은 대체로 실수라고 봄 컨텍스트가 커질수록 모델의 성능이 얼마나 떨어지고 토큰 비용이 얼마나 늘어나는지 과소평가함. Claude는 300k 이상 쓰지 않고 압축하는 대신 작업을 나누며, 문서와 모듈식 코드베이스를 간결하게 유지함 일회성 작업에서는 큰 컨텍스트가 유용할 수 있지만 **300k를 상시 초과**한다면 많은 것을 잃고 있거나 코드베이스 설계가 좋지 않을 가능성이 큼 - 나도 **250k에서 압축하거나 재시작**함. 필요한 컨텍스트 크기가 프로젝트 규모와 비례하므로, 더 큰 창이 필요한 이들은 단지 더 큰 프로젝트를 다루는 듯함 - 내 체감도 같으며 경계는 오히려 **100~150k**로 잡겠음. 모델이 긴 컨텍스트를 지원하더라도 실제 성능은 좋지 않음 - 컨텍스트가 커진다고 모델이 눈에 띄게 멍청해진다는 부분은 내 체감과 다름. 느려지고 비싸지기는 하지만 복잡한 작업에는 감수해야 하는 비용임 주 에이전트가 하위 에이전트들로 필요한 사항을 조사하고 계획을 작성한 뒤, 다른 하위 에이전트들이 적대적으로 검토해 보강하게 함. 끝나면 **100만 토큰 창의 30~40%** 가 차며, 272k에서는 불가능한 흐름임 5.6 Sol에서는 이 과정을 크게 축소해야 했고, 결과가 더 나쁜 이유도 아마 여기에 있음 - 이 변경이 발생했을 때 Tibo가 설명을 함께 올렸음: [https://x.com/thsottiaux/status/2076543065045795309]() - 답글은 여기서 볼 수 있음: [https://xcancel.com/thsottiaux/status/2076543065045795309]() 링크된 트윗은 Tibo의 공식 정보에 대한 비공식 답변이며, Tibo가 답글에서 내용을 정정함 - 이 차트가 이해되지 않음. 압축하는데도 선이 계속 상승하는 이유가 무엇인지, 아니면 “**overall trajectory size**”에 모르는 의미가 숨어 있는지 궁금함 - 추론 강도가 다른데도 **전체 궤적 길이**가 같을 수 있는지 모르겠음. 추론 토큰을 궤적 길이에서 제외하더라도 가능해 보이지 않음 - 이들의 컨텍스트 압축을 좋아하지 않으며, 이제는 **최소 100만 토큰**을 제공해야 한다고 봄 GPT 5.5와 5.6은 압축될 때마다 제 속도를 찾기 전까지 버벅이고, 압축 컨텍스트에 남은 오래된 지시 메시지에 지나치게 집중하기도 함 - GPT-5.6-Sol은 Opus/Fable보다 토큰 효율이 약 2배라서 최대 **258k가 Claude의 약 516k**에 해당함 컨텍스트 부패는 여전히 문제고[1][2], 에이전트 작업에서는 압축이 긴 컨텍스트와 동등하거나 더 낫다는 근거도 있음[3]. 모델이 256k처럼 100만 컨텍스트에서도 추론하면 가장 좋겠지만 아직은 불가능함 [1] [https://arxiv.org/abs/2605.12366]() [2] Opus 4.8 System Card의 GraphWalks 256K와 1M F1 비교: [https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...]() [3] [https://context-folding.github.io/]() - 다른 코딩 도구와 달리 **자동 압축을 비활성화할 수 없어** 답답함. 남은 컨텍스트가 10~20%일 때 불규칙하게 실행되므로 보장되는 용량은 272k의 80%뿐임 큰 코드베이스에서 작업이 거의 끝나 2천 토큰 정도의 응답만 남았는데 20% 아래로 내려가면 한참 처리한 뒤 `Context compacted`가 나타남. 압축 전으로 돌아갈 수 없어 코드베이스를 재조사하다 다시 압축되고, 결국 토큰을 모두 소진함 - 토큰 축소가 사용량을 늘리려는 우회책이 아니라 주로 비용 절감 때문이길 바람. 회사에서도 비용 담당자들이 컨텍스트를 심하게 제한해 처음에는 쓸 만했던 내부 LLM을 거의 무용지물로 만들었음 경영진끼리 **최악의 관행**을 공유하는 모임이라도 있는 듯함 - 작업 메모리는 Markdown 파일에 저장하면 되며 큰 컨텍스트가 필요하지 않음. 컨텍스트가 늘면 어텐션이 분산되어 LLM의 성능이 떨어지므로 **작게 유지하는 편이 품질에 유리함** - 일상적으로 Opus를 쓰며 `/clear`를 자주 실행함. 100만 컨텍스트도 50%에 가까워지면 빠르게 성능이 저하되어 보통 **30~40%에서 초기화**하면 훨씬 나은 결과를 얻음 압축보다는 새로 시작해 필요한 컨텍스트를 처음부터 넣는 편이 더 잘 작동함. 기능별 Markdown 문서를 여러 기술 모음으로 정리해두고, 첫 로딩 때 작업 관련 정보를 어디서 찾을지 알려주는 방식이 효과적임 - Codex에서는 컨텍스트 크기가 문제라고 느낀 적이 없음. 압축 방식은 모르지만 **제한이 없는 것처럼 계속 진행**됨 - Codex를 최근에 쓰기 시작한 듯함. 초기에는 압축으로도 복구하지 못하는 **`model context size exceeded` 오류**가 심했고, 불과 몇 달 전부터 사라졌음 지금은 훨씬 나아졌지만 압축 후 `concise summary`에 무엇이 들어갔는지 보여주지 않아 중요한 내용이 보존됐는지 알기 어려움 Codex는 사용자에게 최대한 숨기는 방향으로 가는 듯하며, 최근 에이전트와 하위 에이전트 사이의 프롬프트를 암호화했듯 세션 로그 전체도 암호화할 수 있어 보임. 아쉽지만 지금까지 써본 것 중에는 여전히 최고의 도구·모델 조합임 - Codex는 압축이 발생하면 마지막 작업을 완료하는 것을 자주 잊으며, 특히 **압축 직전에 메시지를 보냈을 때** 심함 - 대부분의 문제는 분할 정복할 수 있어서 **300k와 400k의 차이**가 거의 문제 되지 않음. 코딩 에이전트는 무한 대화가 아님 - 압축이 아무리 좋아도 큰 프로젝트에서는 파일을 많이 읽어야 함. 처음 **20만 토큰은 매우 빠르게 소모**되지만 이후에는 속도가 느려짐 Fable 세션은 대부분 50만 토큰을 넘지 않아 압축이 필요 없지만, Codex에서는 한 세션에서 계속 압축해야 함 - 파일을 많이 읽어야 하는 이유는 `agents.md`가 부실하기 때문이라고 봄. 실제 작업 파일과 몇 개의 관련 파일만 읽으면 되고, 나머지는 **문서에 정리돼 있어야 함** - 내 작업에는 꽤 작은 크기임. 200k 아래로 유지하려 하지만 DeepSeek와 MiMo 세션에서 마지막 반복 작업을 밀어붙이면 **350k 토큰**까지 늘어난 뒤 압축하기도 함 OpenAI가 공개 논문에 나온 DeepSeek의 K/V 캐시 기술을 도입해 비용을 크게 낮출 수 없는지 궁금함 - **DeepSeek만큼 캐싱을 잘하는 곳**이 없으니 구현 차이가 커서 따라 하기 어려운 듯함 DeepSeek를 Reasonix와 함께 쓰면 캐시 구조에 맞춘 추가 전용 방식이라 긴 세션에서 토큰의 97~98%가 캐시됨. 이미 저렴한 모델이 더 저렴해짐 - llamacpp 기반 로컬 공개 모델에서는 에이전트가 지시해 **55k~85k 사이에서 압축**하며, 복잡한 로그 추적처럼 큰 컨텍스트가 꼭 필요하지 않다면 120k까지 가는 일은 드묾 llamacpp의 추론 예산과 메시지에 맞춰 에이전트가 하위 에이전트를 생성한 뒤 내용을 압축하도록 시스템 프롬프트도 조정했음. opencode의 동적 컨텍스트 가지치기를 사용해 부피를 키우지 않고 방향성만 유지하며, 여러 하위 구성 요소를 반복 개발하는 데 대체로 잘 작동함 - 지난 두 달 동안 내 용도에는 훨씬 나아서 Claude에서 **OpenAI로 전환**했음. 이번 변경으로 출력 품질 차이가 체감될지 궁금함