Claude Opus 4.6 / Sonnet 4.6의 1M context window GA 출시 — 추가 요금 없음

Who Should Read

Claude API로 대규모 코드베이스 분석, 긴 문서 처리, 장시간 에이전트 세션을 돌리는 개발자. 특히 Claude Code로 작업하면서 컨텍스트 압축(compaction)에 불만이 있었던 사람.

Core Mechanics

• Opus 4.6($5/$25 per M tokens)과 Sonnet 4.6($3/$15 per M tokens) 모두 1M 컨텍스트 윈도우가 GA됐다. 핵심은 long-context premium이 사라졌다는 것 — 900K 토큰 요청이든 9K 토큰 요청이든 토큰당 단가가 동일하다.
• 요청당 이미지/PDF 페이지 수 제한이 100장에서 600장으로 6배 늘었다. 대형 계약서 세트나 기술 문서 묶음을 한번에 넣을 수 있게 됐다.
• Claude Platform, Microsoft Azure Foundry, Google Cloud Vertex AI에서 모두 사용 가능하고, 베타 헤더 없이 200K 넘는 요청이 자동으로 처리된다. 기존에 베타 헤더 쓰던 코드도 변경 불필요.
• Claude Code에서도 Max/Team/Enterprise 플랜 사용자는 Opus 4.6 세션에서 1M 컨텍스트를 자동으로 쓸 수 있다. 컨텍스트 압축(compaction) 빈도가 줄어들어 긴 대화에서 정보 손실이 적어진다.
• MRCR v2(장문맥 검색 벤치마크)에서 Opus 4.6이 78.3%로 프론티어 모델 중 최고 점수를 기록했다. 1M 토큰을 넣어도 정확도가 유지된다는 것이 핵심 셀링 포인트.
• 실제 사용 사례로, Cognition의 Devin Review 에이전트는 대형 diff를 200K에 못 넣어서 청크를 나눠야 했는데, 1M 컨텍스트로 전체 diff를 한번에 넣으니 크로스파일 의존성 파악이 좋아지고 리뷰 품질이 올라갔다고 한다.
• 한 사용자의 실무 경험에 따르면 compaction 이벤트가 15% 감소했고, 에이전트가 수시간 동안 초반에 읽은 내용을 잊지 않고 작업할 수 있게 됐다.
• 경쟁 맥락에서 GPT-5.4도 1M 윈도우를 제공하지만 추가 요금이 붙는다. Anthropic이 표준 가격으로 제공하는 것은 KV 캐시 경제성을 확보했다는 신호로 읽힌다.

Evidence

• 600~700K 토큰 부근에서 instruction following이 급격히 저하되는 'cliff'가 있다는 프로덕션 테스트 경험이 공유됐다. 검색(retrieval) 자체는 되지만 먼 컨텍스트의 가중치 반영이 약해진다는 것. 1M을 '넣을 수 있는 것'과 '잘 쓸 수 있는 것'은 다르다는 지적이 많았다.
• 한 개발자는 코드맵 전략(파일별 summary + public API 정리)과 자동 컨텍스트 선별로 실제 요청은 30K~80K에서 해결하고 있으며, 1M이 정말 필요한 유스케이스가 뭔지 궁금하다고 했다. 입력 정밀도를 높이면 출력 정밀도도 올라간다는 경험.
• Claude Code 사용자 중 compaction 때 모델이 핵심 맥락을 잊고 같은 실수를 반복하는 것이 고통스러웠다는 의견이 많았고, 이번 변경으로 다시 Claude를 메인 도구로 쓰겠다는 반응이 나왔다. GPT-5.4/Codex가 compaction을 더 잘 처리해서 갈아탔다가 돌아온다는 사례도.
• 추가 요금 없이 제공한다는 점 자체가 KV 캐시 최적화를 해결했다는 의미라 기술적으로 더 흥미롭다는 분석이 있었다. 윈도우 크기보다 경제성이 더 어려운 문제라는 것.
• 임베디드/하드웨어 쪽 코드에서는 Opus도 여전히 주니어 수준이라는 경험이 공유됐다. Python 같은 고수준 언어에서는 뛰어나지만 C/C++ 임베디드는 학습 데이터 부족 때문인지 한계가 있다는 의견.

How to Apply

• Claude Code로 대형 모노레포 작업 시, 기존에 수동으로 컨텍스트를 줄이거나 /compact를 자주 쓰던 워크플로우를 재검토하라. Max/Team/Enterprise 플랜이면 Opus 4.6에서 자동으로 1M이 적용되므로 compaction 없이 긴 세션을 유지할 수 있다.
• API로 대량 문서 분석(계약서, 기술 문서, 코드 리뷰)을 하는 경우, 청크를 나눠서 여러 번 호출하던 파이프라인을 단일 1M 요청으로 단순화하라. 특히 크로스레퍼런스가 필요한 작업에서 품질이 올라간다.
• 다만 600K+ 토큰 영역에서 coherence 저하 가능성이 보고되고 있으므로, 프로덕션 파이프라인에 적용하기 전에 자체 벤치마크(instruction following 테스트, needle-in-a-haystack)를 돌려서 품질 cliff를 확인하라.
• 비용 최적화 관점에서, 코드맵 + 자동 컨텍스트 선별 전략(파일별 summary 생성 → 관련 파일만 선별)을 병행하면 불필요하게 큰 컨텍스트를 쓰지 않으면서도 품질을 유지할 수 있다. 무조건 1M을 채우는 것이 최선은 아니다.

Terminology

관련 논문

• Claude Code는 프롬프트 읽기 전에 33k 토큰을 전송한다; OpenCode는 7k

  동일한 모델과 작업 환경에서 Claude Code와 OpenCode의 실제 토큰 사용량을 API 레벨에서 측정한 결과, Claude Code가 시스템 프롬프트 오버헤드만으로 OpenCode 대비 4.7배 더 많은 토큰을 소비한다는 것을 확인했다.

• Mesh LLM: iroh 기반 분산 AI 컴퓨팅

  사무실, 집, 클라우드에 흩어진 GPU들을 하나의 OpenAI 호환 API로 묶어주는 분산 LLM 실행 시스템으로, 비싼 API 비용 없이 큰 모델을 직접 운영할 수 있다.

• Frugon – LLM API 호출 로그를 분석해서 더 싼 모델로 대체 가능한 구간을 찾아주는 로컬 도구

  내 LLM API 비용이 어디서 새는지 로컬에서 분석해주는 오픈소스 CLI 도구로, 비싼 모델 대신 저렴한 모델로 전환 가능한 호출을 골라낸다.

• 로컬에서 SOTA LLM 실행하기 완전 가이드 (하드웨어부터 설정까지)

  2천 달러짜리 RTX 3090 한 장부터 4만 달러짜리 RTX PRO 6000 4장 셋업까지, 로컬에서 최신 LLM을 직접 돌리는 방법을 하드웨어 선택·구성·실행 설정까지 통째로 정리한 실전 가이드다.

• Manticore Search에서 ONNX 경로를 재설계해 임베딩 속도를 14배 높인 방법

  Manticore Search가 기존 SentenceTransformers/Candle 백엔드를 ONNX Runtime으로 교체해 텍스트 임베딩 생성 속도를 평균 14배 향상시켰다. 별도 모델 서비스 없이 DB 내부에서 직접 임베딩을 처리하는 구조에서 INSERT 속도가 곧 임베딩 속도이기 때문에 이 개선은 실질적인 ingest 처리량 향상으로 직결된다.

• Asymmetric Quantization: 97% 스토리지 절감으로 Late Interaction 검색 품질 유지하기

  멀티벡터 검색 모델의 문서 벡터를 1비트 이진값으로 압축하고 쿼리 벡터만 int8로 유지하는 비대칭 양자화 기법으로, 스토리지를 97% 줄이면서 검색 품질 손실을 0.61점(NDCG@10 기준)에 그치게 만든 실제 프로덕션 적용 사례다.

Related Resources

• https://claude.com/blog/1m-context-ga