GPT-6.1 Sol의 76배 브라우저 에이전트 결과: Asana가 실제로 측정한 것

Asana는 2026년 10월 8일 브라우저 에이전트 비용 연구를 발표했고, GPT-6.1 Sol의 개발자는 다음 날 "Asana가 브라우저 테스트에서 모델 비용을 76배 절감하는 데 사용한 GPT-6.1 Sol."이라는 제목으로 기사를 썼다. 76배는 누군가 측정했다는 점에서는 실재하지만, GPT-6.1 Sol의 가격에 관한 사실은 아니다. 그것은 브라우저 에이전트에서 망가진 프롬프트 캐시를 고친 뒤 그 뒤에 있는 모델을 교체하면 무슨 일이 일어나는지에 관한 사실이다. Asana가 이미 프로덕션에서 사용하던 모델 — Asana가 Model B라고 부르는 모델 — 에서 같은 최적화를 실행하자 그 자체로 비용이 29배 절감되었다. GPT-6.1 Sol이 나머지 2.6배를 제공했다. 실험은 Codex에서 작업한 GPT-6 Astra가 수행했고, 기준선 뒤의 모델은 Asana가 Model B라고 부르는 경쟁사의 모델이다. 따라서 같은 공급업체의 두 티어와 이름이 밝혀지지 않은 경쟁사 하나가 모두 이 이야기에 등장한다. 이어지는 내용은 월요일에 그대로 복사할 수 있는 결과의 부분과 Asana의 특정 스택에 속하는 부분을 구분한다.

정확하게 진술된 그 비교

Asana가 이를 위해 사용하는 스택은 Asana가 인수한 워크플로 자동화 플랫폼인 StackAI로, 코드 없이 웹사이트를 탐색하고 양식을 작성하며 정보를 수집하는 브라우저 에이전트를 실행한다. 테스트 작업은 좁고 구체적이었다: 공개 데모 카탈로그에서 32권의 책 각각에 대해 여섯 개 필드를 수집하는 것. 이는 일부 고객이 실행하는 작업을 대표하며, 144회 실행 연구가 일주일 안에 들어갈 만큼 규모도 작다.

실험 설계는 두 가지 히스토리 예산에서 여섯 가지 캐싱 및 스크린샷 정책을, 조건당 세 번 실행, 네 개 모델에 걸쳐 — 144회 실행, 그리고 12회 실행의 후속 실험으로 구성되었다. 비용은 각 제공자의 자체 토큰 카운터에서 계산되었고, 모든 답변은 독립적으로 준비된 참조에 대해 채점되었다. 네 모델은 세 개의 익명 프런티어 모델(모델 A, B, C)과 GPT-6.1 Sol이었다. 모델 A는 다른 연구소에서 2025년 가을에 출시한 더 작고 저렴한 모델로, GPT-6.1 Sol의 절반 가격이다. 모델 B는 실제 프로덕션에 사용된 모델로, A와 같은 연구소에서 2026년 여름에 출시되었으며 GPT-6.1 Sol과 같은 가격이다. 모델 C는 모델 B의 최신 버전으로, 2026년 가을에 출시되었으며 역시 GPT-6.1 Sol과 같은 가격이다. 세 모델은 두 보고서 모두에서 익명이므로, 독자가 이 비교를 재현할 수 없다 — 29배를 다른 누군가의 모델에 관한 숫자로 취급하기 전에 알아둘 가치가 있다. 이는 Asana와 OpenAI가 발표한 수치이며, 독립적으로 감사된 수치가 아니다.

결과의 사다리, 모두 Asana 자체 수치입니다:

• Model B의 베이스라인 프로덕션 — 실행당 최소 $36.21, 실행당 최소 22.5분. 일부 베이스라인 실행은 완료되기 전에 스텝 제한에 도달하므로, 평균은 실제 평균이라기보다 하한값입니다.

• Model B, 최적화된 에이전트 — 실행당 $1.24, 베이스라인보다 4배 빠르고 비용은 29배 절감.

• GPT-6.1 Sol, 동일한 최적화된 에이전트 — 실행당 $0.47, 약 4분, 76배 비용 절감 및 5배 더 빠름.

• GPT-6.1 Sol, 수정 전과 후 — 실행당 $1.97에서 $0.47로, 캐시와 정리 변경만으로 4배 절감.

기준선이 하한값이므로 76배 자체가 최저치다. 정직하게 읽으면 "76배"가 아니라 "최소 76배"다.

실제로 무엇이 바뀌었으며, 왜 그것이 모델 기능이 아닌가

그 메커니즘은 프롬프트 캐시의 작동 방식이며, 어떤 모델에서 실행하든 모든 에이전트에 그대로 적용되므로 이해해 둘 가치가 있다. 브라우저 에이전트는 모델을 호출할 때마다 자신의 도구, 시스템 프롬프트, 그리고 점점 늘어나는 페이지 텍스트와 스크린샷 기록을 다시 보낸다. 프롬프트 캐싱은 반복되는 부분의 비용을 깎아주지만, 변경되지 않은 가장 긴 접두사에만 해당한다. 요청 중간의 무엇 하나라도 바뀌는 순간, 그 지점부터 재사용이 깨진다.

Asana의 프로덕션 에이전트에는 서로 겹치며 악화된 두 가지 결함이 있었다. 그것은 고정된 지침과 도구 정의는 캐시했지만 탐색 기록은 캐시하지 않았다. 그리고 거의 모든 단계에서 그 기록을 편집했다. 매번 이전 스크린샷을 버리고, 기록 예산에 맞추기 위해 오래된 텍스트를 잘라냈다. 모든 편집이 프리픽스를 무효화했기 때문에, 캐싱이 켜져 있었더라도 거의 쓸모가 없었을 것이다. Asana의 글에 따르면, 테스트된 모델에서 캐시 읽기 비용은 표준 입력 가격의 0.05배에서 0.1배였다. 따라서 얻을 수 있는 이득은 컸는데, 에이전트는 체계적으로 그것을 거부하고 있었다.

이 수정은 두 부분으로 나뉩니다. 첫째, 기록도 캐시하되 최신 도구 결과에 캐시 마커를 붙입니다. 둘째, 매 호출마다 기록을 편집하지 않습니다. 스크린샷을 유지하고 20대 1 비율로 일괄 정리하여, 에이전트가 최대 20개를 보관하다가 가장 최근 것만 남기고 줄입니다. 그러면 약 19번의 연속 호출이 변경되지 않은 접두사를 재사용합니다. 기록 예산을 120,000자에서 480,000자로 늘려 오래된 텍스트가 잘리지 않게 하면 계산이 맞아떨어집니다. GPT-6.1 Sol에서는 입력의 89%가 캐시에서 왔기 때문에 각 호출 비용이 대략 3분의 1로 줄었습니다.

여기서 가장 중요한 발견은 부정적인 것입니다. 배치 프루닝 없이 이력을 캐싱하는 것은, 더 큰 예산에서, 더 많은 비용이 들었습니다 — 네 모델 중 세 모델에서 전혀 캐싱하지 않는 것보다 말입니다. 캐시는 계속 다시 쓰였고 거의 읽히지 않았습니다. append-only 이력 규율 없이 켜 놓은 캐시 인프라는 아무것도 얻지 못한 채 쓰기 프리미엄을 지불하는 방법입니다. 그 실패 모드는 모델과 무관하며, 바로 그 때문에 동일한 수정이 Model B를 29배나 움직였습니다.

모델 선택이 실제로 빛을 발한 곳

워크플로 수정을 빼고 같은 조건끼리 비교하자: 동일한 최적화 에이전트에서, 동일한 정가 기준으로 GPT-6.1 Sol은 Model B보다 2.6배 더 저렴하게 실행됐다. 추가 요인은 요율표가 아니라 캐시 적중 동작이다. Sol은 입력의 89%를 캐시에서 읽었다. Asana는 Model B에 대한 동등한 비율을 공개하지 않으므로, 2.6배는 공개된 분해 없이 측정된 결과다. 이것은 이 모델이 이 워크로드에서 캐시를 더 잘 활용했다는 의미로 보아야 하며, 우리가 이름을 밝힐 수 없는 모델에 대한 일반적인 2.6배 우위로 보아서는 안 된다.

런타임 측면은 명확하다. 기준선보다 5배 빠르며, 최적화된 Sol 워크플로는 약 4분으로 최소 22.5분인 기준선과 대비된다. 토큰 단위로 과금하는 에이전트에서 속도는 비용에 직결된다. 왜냐하면 느린 모델이 루프를 돌면 그 루프에 대한 비용을 치르기 때문이다.

비용을 계산해 보려는 분들을 위해 정리하면: GPT-6.1 Sol의 표준 API 요금은 입력 토큰 100만 개당 $2.00, 캐시된 입력 토큰 100만 개당 $0.10, 출력 토큰 100만 개당 $10.00이며, 캐시 읽기 할인은 입력 요금의 0.05배입니다 — OpenAI의 현재 요금표에서 가장 깊은 할인입니다. Codex에서 엔지니어링 작업을 수행한 모델인 GPT-6 Astra는 입력 $10.00, 출력 $50.00으로, OpenAI가 출시 당시 강조한 5배 격차에 해당합니다. 이 연구가 $2짜리 실행이 아니라 $0.47짜리 실행을 산출한 이유는 요금표 때문이 아니라, 매우 반복적인 요청의 89%가 입력 요금의 20분의 1로 청구되었기 때문입니다. 캐싱이 많은 에이전트에서는 할인 항목이 대표 가격보다 더 큰 역할을 하며, 우리 자체 카탈로그에서는 제공업체 정가가 0% 마크업, 따라서 벤더가 캐시 입력 계량기를 움직이면 같은 날 청구서에서도 그대로 움직입니다.

연구의 또 다른 숫자: 기록 예산이 에이전트가 응답을 하느냐 자체를 결정했다

실행당 비용은 누구나 인용하는 숫자이지만, 이 연구에서 더 유용한 결과는 신뢰성에 관한 것이며, 운영자가 가장 먼저 읽어야 할 바로 그것이다.

• 120,000자 예산에서 Model C는 18회 실행 중 어느 것에서도 답하지 않았고, GPT-6.1 Sol은 18회 중 3회 답했습니다 — 대부분의 실행은 답을 내놓지 못한 채 단계 한도에 도달했습니다.

• 480,000자에서 두 모델의 모든 실행이 응답했으며, 각각 정답을 제시했습니다.

• 더 새로운 모델들은 더 작은 예산을 더 빨리 소진했다: 모델 C는 호출 10에서 처음으로 기록을 잘라냈고, 모델 A는 호출 64에서 잘라냈다.

• 최적화된 워크플로에서는 모든 실행이 과제를 완료하고 정답을 반환했으며, 모든 모델에서 최상 조건으로 수행된 각 실행은 수집해야 했던 192개 사실을 모두 확인했습니다.

그것은 "더 저렴하다"와는 다른 논점이다. 유능한 모델에 너무 작은 히스토리 예산을 주면, 공간이 부족해 실패하는 에이전트가 만들어지고, 스텝 상한에 부딪혀 실패하는데, 이는 가장 비싼 실패 방식이다 — 전체 실행 비용을 다 지불하고 아무것도 얻지 못한다. 예산을 늘리면 호출당 비용은 올라가고 답변당 비용은 낮아졌는데, 그것이 프로덕션 운영자가 추적해야 할 유일한 수치다. 이런 에이전트에 검증되지 않은 모델을 평가하고 있다면, 위험을 낮추는 패턴은 프로덕션 경로는 신뢰하는 모델에 그대로 두고 새 모델은 페일오버나 분할 경로 뒤에 배치하는 것이며, 그러면 스텝 한도 실패가 장애가 아니라 라우팅상의 사실로 드러난다. 이 비교에 나온 모든 모델은 200개 이상의 모델을 위한 단일 API를 통해 접근할 수 있고, 제공업체의 리스트 가격이 그대로 전달되므로, 캐시 읽기 할인을 다섯 개의 대시보드가 아니라 같은 인보이스에서 벤더 간에 비교할 수 있게 해준다.

이것에서 얻어야 할 것, 순서대로

브라우저나 컴퓨터 사용 에이전트를 운영한다면, 요율표를 보기 전에 Asana 연구의 세 가지 레버를 살펴볼 가치가 있습니다:

• 요청 접두사는 추가 전용(append-only)으로 유지하세요. 히스토리 중간을 호출마다 수정하면 그 지점 이후로 캐시 재사용이 모두 사라집니다.

• 일괄적으로 프루닝하세요. Asana의 후속 조사에 따르면 모든 스크린샷을 유지하는 비용은 1.2배 덜 호출당 Model B와 GPT-6.1 Sol의 최상의 프루닝 조건보다 들었고, Model C에서는 약 5% 더 적었습니다. 프루닝은 여전히 긴 작업, 작은 컨텍스트 창, 비용이 많이 드는 캐시 읽기에서 중요합니다 — 하지만 20:1 배치 비율을 주장하는 근거는 스크린샷 자체가 아니라 캐시 안정성에 관한 것입니다.

• 모델별로 히스토리 예산을 설정하고, 그것이 스텝 상한에 맞는지 확인하세요. 한 모델에 맞는 예산이 다음 모델을 굶길 수도 있습니다.

이 연구에서 나온 두 가지 가드레일은 건너뛰기 쉽지만, 건너뛰어서는 안 된다. 480,000자 예산에 도달한 실행은 없었으므로 그 예산이 이 실행들을 제약한 적은 없었다 — 하지만 표류하는 에이전트는 자신의 컨텍스트 한도 쪽으로 커지고, 캐시가 깨지면 모든 호출이 전액을 지불한다. 나쁜 실행을 제한하는 것은 단계, 토큰, 실행당 비용에 대한 상한이다. 이와 별개로, 이 연구는 조건당 호출 수가 다양한 3~4회의 실행을 사용했는데, Asana 자체도 이 정도면 광범위한 패턴을 보여주기에는 충분하지만 몇 퍼센트 차이 나는 조건들을 구분하기에는 충분하지 않다고 말한다. 여기서 5% 차이를 읽어내어 그것에 맞춰 파이프라인을 재구축하지 마라.

진정으로 새로운 부분, 그리고 그렇지 않은 부분

설정에 관한 주의사항은 분명히 밝혀 둘 가치가 있다: 모델 네 개, 그중 셋은 이름이 공개되지 않았고, 범위가 좁은 32권짜리 과제 하나, Asana 자체의 계측 카운터, 그리고 결과를 실은 벤더 자체의 글. 여기 있는 내용 중 Asana 외부에서 재현된 것은 없다. 하지만 메커니즘은 완전히 명시되어 있다 — 추가 전용 이력, 마지막 도구 결과에 대한 캐시 마커, 배치 프루닝, 더 큰 예산, 제공자의 카운터로 캐시 읽기 측정 — 그리고 이는 잘못된 연구소에 귀속되어도 살아남는 종류의 발견이다. 76x는 Asana 워크로드에 대한 Asana 수치다. 이 글이 읽을 가치가 있는 이유는 오후 한나절이면 시험해 볼 수 있는 규칙을 보여 주기 때문이다: 매 단계마다 자신의 이력을 편집하는 에이전트는 이미 나눈 대화에 대해 전액을 치르고 있는 셈이다.