클로드 코드(Claude Code) 쿼터, 왜 이렇게 빨리 닳을까?
클로드 코드(Claude Code) Pro Max 5x 플랜에서 쿼터 소진 속도가 예상보다 훨씬 빠름을 지적
캐시된 토큰(Cached Tokens)이 쿼터 계산에 제대로 반영되지 않아 캐싱의 효과가 미미하다는 분석
백그라운드 세션(Background Sessions) 및 자동 압축(Auto-compact) 기능이 예상치 못한 쿼터 소모를 유발
사용량 측정 도구 부재로 인해 사용자들은 정확한 쿼터 소비량 파악에 어려움을 겪고 있음
캐시된 토큰(Cached Tokens)의 쿼터 계산 문제
문제 제기자는 캐시된 토큰(Cached Tokens)이 쿼터 계산 시 1/10 비율로 계산되어야 하지만, 실제로는 전체 토큰으로 계산되어 쿼터 소진 속도를 가속화한다고 주장한다. 이는 1M 컨텍스트 윈도우(Context Window)에서 API 호출당 100k~960k 토큰을 소모하게 만들어, 캐싱의 비용 절감 효과를 무력화시킨다. 특히, 200회 이상의 API 호출이 발생하는 경우 쿼터가 빠르게 소진될 수 있다.
백그라운드 세션(Background Sessions)의 쿼터 소모
커뮤니티에서는 사용자가 활발히 사용하지 않는 백그라운드 세션(Background Sessions)이 쿼터를 소모하는 문제를 지적한다. 이러한 세션은 자동 압축(Auto-compact) 및 기타 프로세스를 통해 API 호출을 지속적으로 발생시키며, 이는 예상치 못한 쿼터 소모의 주요 원인으로 작용한다. 특히, 여러 세션을 동시에 사용하는 경우 쿼터 소진 속도가 더욱 빨라질 수 있다.
자동 압축(Auto-compact)으로 인한 쿼터 스파이크(Quota Spikes)
자동 압축(Auto-compact) 기능은 컨텍스트 크기가 임계값에 도달하면 전체 컨텍스트를 포함하는 API 호출을 발생시켜 과도한 쿼터 소모를 유발한다. 이로 인해 사용자는 별도의 조치 없이도 가장 많은 토큰을 소모하는 API 호출을 경험하게 된다. 이러한 동작은 1M 컨텍스트 윈도우(Context Window)를 사용하는 경우 쿼터 소진 속도를 더욱 가속화한다.
사용량 측정 도구 부재 및 투명성 부족
사용자들은 쿼터 소비량에 대한 투명성 부족을 문제로 제기하며, 정확한 사용량 측정을 위한 도구 부재를 지적한다. 현재 제공되는 /stats 명령어가 실제 사용량을 정확하게 반영하지 못하며, 이는 구독 플랜의 가치를 평가하는 데 어려움을 초래한다. 사용자들은 캐시된 토큰(Cached Tokens)과 같은 세부적인 사용량 정보를 확인할 수 있는 기능을 요구한다.
커뮤니티의 불만과 대안 모색
커뮤니티에서는 클로드 코드(Claude Code)의 성능 저하와 쿼터 문제에 대한 불만이 제기되며, 다양한 대안이 모색되고 있다. 일부 사용자는 코덱스(Codex), 깃허브 코파일럿(GitHub Copilot)과 같은 다른 AI 기반 코딩 도구로 전환하거나, 로컬 LLM(Local LLMs)을 활용하는 방안을 모색한다. 또한, 토큰 효율성을 높이는 코딩 에이전트(Coding Agent)를 자체 개발하는 사례도 보고되었다.