Batch API는 한 에이전트엔 부적합하지만, 여러 에이전트엔 유용할 수 있다

Anthropic의 Batch API는 토큰을 50% 할인하지만, 처리까지 최대 24시간이 걸리는 비동기 경로다.

실험용 하네스 batching-harness는 모든 턴을 1개짜리 배치로 감싸고, 완료될 때까지 폴링한 뒤 도구 루프를 이어간다. rich 기반 터미널 UI와 sandbox-runtime, 그리고 배치와 동기 경로의 비용을 비교하는 /stats 패널까지 붙여 실제 체감을 확인했다.

parallel=1 환경에서는 배치의 장점이 거의 사라졌다. 매 턴마다 90~120초를 기다려야 해서 5턴짜리 에이전트 루프가 10분 안팎으로 늘었고, 대화형 에이전트에는 너무 느렸다.

관찰 결과도 예상 밖이었다.

• Haiku 배치가 Sonnet이나 Opus보다 더 오래 걸리는 경향이 있었다.
• 가설상 Haiku는 동기 경로가 너무 빨라 배치 스케줄러가 끼어들 유휴 시간이 적을 수 있다.
• 그래서 배치 경로는 오히려 크고 느린 모델에 붙이는 편이 낫다.

배치가 실제로 먹히는 경우는 따로 있다.

• 야간 eval이나 예약 감사처럼 지연을 신경 쓰지 않는 작업
• 여러 서브에이전트를 동시에 돌리는 경우
• 여러 하네스의 요청을 모아 실제 N-wide batch로 묶는 경우

이때는 배치 할인과 prompt caching이 함께 작동하고, 1시간 캐시 창을 활용하면 비동기 워크로드에서 효과가 더 커질 수 있다.

다음 단계는 로컬 프록시 LunaRoute에 배치 인식을 넣는 것이다. ANTHROPIC_BASE_URL만 바꾸면 Claude Code나 Codex 같은 기존 하네스는 배치 여부를 몰라도 되고, 프록시가 요청별로 동기 경로와 배치 경로를 골라 같은 인터페이스로 응답을 돌려준다. 결론은 단순하다. 배치의 단위는 한 사용자의 한 턴이 아니라, 프록시가 묶어 보낼 수 있는 여러 에이전트의 요청이다.