같은 통과율에 39% 싼 하네스, 그 이득은 대기 비중에 비례한다

같은 모델, 같은 통과율(57.9%)인데 비용이 $2,350에서 $1,428로 떨어졌다. Unreal Agent가 아낀 것은 모델값이 아니다. 도구가 끝나기를 기다리는 동안 쌓이던 토큰이다.

그런데 이 절감률이 벤치마크마다 39% / 28% / 16% 로 크게 갈린다. 그 편차가 이 기법의 적용 범위를 말해준다 — 내 에이전트가 얼마나 기다리는지에 비례한다.

확인된 것

동작 방식. 도구를 부르면 결과를 기다리지 않는다.

Every time Unreal Agent issues a tool call, we immediately append an event-log record that the tool has returned in the "in-progress" state, while continuing its execution in the background.

실제로 끝나면 그때 결과를 세션 로그에 붙이고 모델을 다시 호출한다. 모델은 대기·폴링·하트비트를 관리하지 않는다.
측정 수치. 전부 GPT-6 Astra(xhigh reasoning) 한 모델에서만 나왔다.

| 벤치마크 | Unreal Agent | Codex | Pi | |---|---|---|---| | Terminal-Bench 4.0 | 57.9% / $1,428 | 57.9% / $2,350 | 55.0% / $1,827 | | SWE-Atlas Codebase QnA | 65.8% / $936 | 63.3% / $1,303 | 64.0% / $1,033 | | DeepSWE 1.1 | 72.4% / $1,367 | 69.0% / $1,633 | 69.6% / $1,584 |
저장소는 MIT, Go. 2026-09-21 생성이니 엿새 됐고, 별 1,965개, 마지막 푸시 9/23. Go 라이브러리 + 실행 파일 + Harbor 호환 벤치 러너를 같이 냈다.
저자가 밝힌 한계.

The use of two tool-call result items (one in progress, one final) in a single context is underspecified in the Responses API documentation

그리고 일부 추론 제공자가 이 패턴을 일관성 없이 거부한다고 적는다.

동기 하네스에서 도구가 몇 분 걸리면 모델은 기다리거나 폴링한다. 폴링 한 번마다 컨텍스트가 통째로 다시 올라간다. 환경 구축 하나 돌리는 동안 그 왕복이 반복되면 비용은 작업이 아니라 기다림에 붙는다.

Unreal Agent는 그 왕복을 없앤다. 저자들이 든 예가 정확하다 — 개발 환경 구축이 몇 분 도는 동안 코드 탐색과 웹 검색을 병렬로 하되 추가 토큰세는 없다.

→ 내 시스템에 얼마나 해당하는지는 재볼 수 있다. 에이전트 한 실행에서 가장 오래 걸린 도구 호출 하나를 찾고, 그 시간 동안 모델 호출이 몇 번 더 갔는지 센다. 그 수가 크면 이 설계의 이득이 크다.

벤더는 "Codex 대비 최대 40%"라고 썼다. '최대'라고 쓴 건 정직하다. 실제로 Terminal-Bench에서 39%, QnA에서 28%, DeepSWE에서 16%다.

편차의 방향이 말이 된다. 긴 환경 구축과 긴 테스트가 끼는 작업일수록 아낄 대기가 많고, 짧은 조회 위주 작업은 아낄 게 적다.

→ 그러니 판단 순서는 이렇다. 먼저 내 에이전트가 어느 쪽인지 보고, 그 다음에 하네스를 고민한다. 도구 호출이 전부 몇백 밀리초짜리인 에이전트를 16% 때문에 갈아엎을 이유는 없다. 반대로 CI·빌드·컨테이너 기동이 끼어 있으면 39% 쪽에 가깝다.

나흘 전 GPU 커널 글에서 쓴 것과 같은 모양이다. 개선율은 상수가 아니라 작업 구성의 함수다.

세 벤치마크 전부 만든 쪽이 잰 수치다. 보통 여기서 신뢰도를 깎는다. 그런데 Harbor 호환 벤치 러너를 함께 공개했으므로 내 환경에서 다시 돌려볼 수 있다.

어제 쓴 기준 그대로 적용한다. 숫자만 낸 자기측정과, 측정기를 같이 낸 자기측정은 다른 물건이다.

다만 깎을 지점은 남는다. 모델이 하나뿐이다. GPT-6 Astra xhigh에서만 쟀고, 다른 모델·다른 추론 난이도에서 같은 비율이 나오는지는 확인되지 않았다.

한 컨텍스트에 도구 결과가 두 개(진행 중 하나, 최종 하나) 들어가는 형태는 Responses API 문서에 명세되어 있지 않다. 일부 제공자는 이걸 거부하고, 그 거부가 일관적이지도 않다.

이게 왜 중요한가. 이 하네스의 핵심 이득은 API 스펙의 회색지대 위에 서 있다. 스펙이 정리되는 방향에 따라 공짜로 안정화될 수도 있고, 어느 날 제공자 업데이트에 깨질 수도 있다.

→ 채택한다면 제공자를 바꾸거나 올릴 때 가장 먼저 깨질 지점으로 표시해둔다. 엿새 된 저장소라는 점도 같이 본다 — MIT에 Go 라이브러리로 나왔으니 읽고 일부만 가져다 쓰는 선택지도 있다.

재현하지 않았다. 벤치 러너를 돌려보지 않았고, 표의 수치는 저자 발표를 읽은 것이다.
모델 한 종에서만 측정됐다. 다른 모델에서 절감률이 유지되는지 모른다.
비용 집계에 무엇이 포함됐는지 — 입력/출력 단가 구분, 캐시 히트 처리 — 를 글에서 찾지 못했다.
실패 모드를 다루지 않는다. 백그라운드 도구가 실패하면, 또는 모델이 in-progress 상태를 보고 잘못된 가정을 하고 진행하면 어떻게 되는지 공개 글에 없다. 비동기 설계에서 제일 궁금한 부분인데 비어 있다.
어느 추론 제공자가 두 결과 항목 패턴을 거부하는지 목록이 없다.
실사용 후기가 아직 없다. 공개 엿새째다.