후속 요청은 새 메시지만…클로드 API 스레드 베타 문서화

앤트로픽(Anthropic)은 메시지 API 문서에서 대화 상태를 서버에 보관하는 메시지 스레드 베타 기능을 안내했다. 이 기능을 쓰면 후속 요청에서 이전 대화 전체를 다시 보내지 않고 새 메시지와 이전 응답 ID로 대화를 이어갈 수 있다.

앤트로픽의 API 문서는 thread를 선택 매개변수로 정의한다. 처음 요청에 create를 지정하면 응답 ID와 연결된 대화 상태가 저장되고, 후속 요청에 continue와 previous_message_id를 넣으면 그 상태에서 대화가 이어진다.

기존 메시지 API에서는 대화를 이어갈 때 앞선 사용자와 클로드의 메시지를 messages 배열에 함께 넣는다. 메시지 스레드는 이 과정을 대신하는 선택 기능으로, 사용하지 않는 요청은 기존 배열 방식으로 처리할 수 있다.

후속 요청에서 과거 메시지를 생략하면 요청 본문을 줄일 수 있다. 다만 이는 모델이 처리하는 문맥이나 추론 시간까지 줄어든다는 뜻은 아니다. 공식 문서에는 응답 첫 토큰까지 걸리는 시간(TTFT)의 개선 폭을 보여주는 벤치마크가 제시되지 않았다.

기능을 지정하는 베타 식별자는 message-threads-2026-08-12다. 개발자는 API 요청의 anthropic-beta 헤더에 이 값을 넣어 기능을 요청한다.

베타는 정식 API에 편입되기 전의 실험 기능이다. 조직에 접근 권한이 없으면 요청이 400 오류를 반환할 수 있고, 지역에 따라 제공 여부와 요금·호출 제한이 달라질 수 있다.

10월 16일 깃허브(GitHub)의 클로드 코드(Claude Code) 이슈 작성자는 270초 뒤 요청은 이어졌지만 360초 뒤 continue 요청은 HTTP 404 thread_not_found를 반환했다고 보고했다. 작성자는 클로드 코드가 이후 대화 전체를 다시 보내는 create 요청으로 재시도해 추가 왕복이 발생했다고 적었다.

작성자는 7.9k 토큰 시스템 접두부의 프롬프트 캐시 TTL을 1시간으로 설정한 조건에서도 360초 뒤 같은 오류가 났다고 설명했다. 이는 한 사용자의 재현 사례로, 앤트로픽이 공지한 공통 만료 기준은 아니다.

다른 깃허브 이슈 작성자는 메시지 스레드와 대화 중간의 시스템 메시지를 함께 넣은 $.model.fork 요청에서 프롬프트 캐시가 재사용되지 않았다고 보고했다. 두 조건 중 하나를 제외하면 같은 문제가 나타나지 않았으며, 작성자는 서버 측 원인을 확인하지 못했다고 밝혔다.

두 깃허브 이슈는 특정 조건에서 나온 사용자 보고다. 공식 안내가 모든 스레드 요청의 만료 시간이나 캐시 동작을 정한 것은 아니다.