Anthropic은 11월 2일 Claude Platform에서 message threads 공개 베타를 시작했다. 개발자는 Messages API 요청에 thread 매개변수를 추가하고, 첫 턴에 전체 대화를 보낸 뒤 이후에는 새로 추가된 메시지와 직전 응답의 ID만 보내면 된다. 서버가 대화를 다시 이어 붙인다.
Anthropic이 제시한 수치는 Claude Code에서 나온 것이다. 이 기능은 이미 대부분의 Claude Code 사용자에게 기본으로 켜져 있으며, 50만~100만 토큰 요청에서 첫 토큰이 나오기까지의 시간 중앙값이 약 35% 줄었다. 다른 길이 구간의 효과는 블로그에 나와 있지 않다.
공개 베타 대상은 Claude API, Claude Platform on AWS, Microsoft Foundry, 그리고 Google Cloud에서 Anthropic이 호스팅하는 Claude다. 문서에 나열된 지원 모델은 Sonnet 4.5와 Opus 4.5부터 Fable 5.1, Mythos 5.1까지 이어진다.
줄어드는 것은 검증과 토큰화
스레드가 없으면 에이전트는 한 턴을 돌릴 때마다 전체 대화를 다시 업로드해야 하고, API도 매번 검증과 토큰화를 처음부터 다시 한다. 세션이 길수록 이 준비 작업에 시간이 더 걸리며, 특히 컴퓨터 조작 에이전트는 과거 스크린샷을 매 턴 다시 보내야 해서 더 불리하다.
스레드는 이런 내용을 서버 메모리에 먼저 올려 두기 때문에, 처리 대상은 사실상 새로 추가된 한 턴만 남는다.
Claude는 매 턴 전체 대화를 읽기 때문에 모델 쪽 토큰 수는 줄지 않으며, 과금과 사용량 제한도 기존 규칙을 따른다. 대략 계산해 보면 이렇다. 80만 토큰짜리 세션에서 턴마다 2,000토큰이 추가된다면, 스레드를 쓸 때 요청에 실어 보내는 분량은 기존의 약 400분의 1이지만 청구서의 입력 토큰은 여전히 80만 개를 넘는다. 비용을 줄이려면 여전히 프롬프트 캐싱이 필요하며, 이는 별도의 스위치다. 스레드 요청은 최상위에 cache_control을 붙일 수 있고, 붙이지 않으면 새 메시지만 보내더라도 캐시되는 내용은 없다.
도입할 때는 퇴로를 남겨야
문서는 스레드를 "최선 노력(best effort)" 방식으로 정의하며, 이것이 연동 방식을 좌우한다.
- 만료: 스레드는 마지막 요청 후 5분이 지나면 만료된다. 응답이 저장될 때마다 타이머가 다시 시작되며, 마지막 사용 후 늦어도 1시간 뒤에는 삭제된다.
- 무효화: 이어 보내는 요청이 404를 반환하면 전체 대화를 다시 보내 새 스레드를 열어야 한다. 해당 턴이 제대로 저장됐는지는 응답으로 알 수 없고, 다음 요청을 이어 보내 봐야 알 수 있다.
- 사본: 대화의 정본은 여전히 애플리케이션 쪽에 있다. 공식 SDK의 도우미는 메모리에 사본을 두고 자동으로 재전송하지만 프로세스가 끝나면 사라지므로, 프로세스를 넘나들어야 한다면 직접 저장해야 한다.
- 고정 필드:
system과tools는 생성할 때만 보낼 수 있으며, 이어 보내는 요청에 null이라도 포함하면 400 오류가 난다.model,thinking,tool_choice,mcp_servers등은 매 턴 그대로 다시 보내야 하고, 바꾸면thread_fingerprint_mismatch가 반환된다. 시스템 프롬프트나 도구를 바꾸려면 새 스레드를 열 수밖에 없다.
규정 준수 측면의 제약도 있다. 스레드 내용은 메모리에서 암호화되어 보관되고 영구 저장소에는 기록되지 않지만, 이 기능은 제로 데이터 보존(ZDR) 조건을 충족하지 않는다. ZDR 계약을 맺은 기업도 다른 기능은 영향을 받지 않지만, 스레드만큼은 쓸 수 없다.
개발자는 Claude Managed Agents에도 session threads가 있으며 이번 message threads와는 별개라는 점도 구분해야 한다.
비어 있던 한 조각
OpenAI의 Responses API에는 오래전부터 previous_response_id가 있어, ID 하나를 넘기면 앞선 맥락을 이어 갈 수 있다. Anthropic은 오랫동안 클라이언트가 매 턴 전체 기록을 보내도록 요구해 왔다. 무상태이고 구현이 단순하다는 장점이 있지만, 대화가 길어지면 지연이 커지는 대가를 치른다. 이번 방식은 그 절충안이다. 상태는 서버에 잠시만 머물고, 사라지면 다시 보내면 되며, 클라이언트 쪽 사본은 하나도 빼놓을 수 없다.
공식이 제시한 적용 사례를 보면 주요 대상은 장시간 실행되는 코딩 에이전트, 컴퓨터 조작 에이전트, 문서와 이미지가 많은 워크플로다. Anthropic 역시 자사의 Claude Code에서 먼저 기본값으로 켠 다음 API 사용자에게 개방했다.
수십만 토큰 미만의 일반 대화에서 얼마나 개선되는지는 공식이 수치를 내놓지 않았다. 문서에는 스레드가 긴 에이전트 루프에서 가장 도움이 된다고만 적혀 있다. 에이전트를 직접 구축하는 팀이라면 먼저 자사 세션 길이 분포로 한 차례 측정해 본 뒤, 이 404 재전송 경로를 위해 코드를 한 겹 더 쓸 가치가 있는지 판단하는 편이 좋겠다.
참고 출처: Claude 공식 블로그, CocoLoop, Claude Platform 개발자 문서. 지연 감소폭은 공식이 공개한 Claude Code 중앙값 기준이며, 대략적인 계산 부분은 편집부 추산이다.