Drex Max, 의사결정 모델에 주목하다 — 모든 클릭에 0.06달러의 가격을 매기다

컴퓨터 사용 에이전트는 사실 하나의 결정이 아니다. 항공편 예약은 서른 개의 결정이다: 어느 필드를 클릭할지, 어떤 결과를 열지, 캘린더 위젯이 렌더링을 마쳤는지, 지금 보고 있는 운임이 원하는 운임인지. 각각은 스크린샷 왕복이며, 반대편 모델이 프런티어 채팅 모델이라면 각각에 몇 초와 프런티어 모델 요금이 든다. Drex Max는 Nace.AI가 2026년 10월 19일 일반 제공으로 출시한 것으로, 그 산술을 접어버리려는 시도다. 그것은 채팅 모델이 아니라 결정 모델이다 — 화면과 타입이 지정된 옵션 세트를 주면, 한 번의 순전파가 각 옵션에 대한 확률을 반환한다. Nace는 백만 입력 토큰당 0.06달러, 중앙값 지연 183ms, 그리고 출력 요금은 전혀 없다고 명시한다. 아무것도 쓰지 않기 때문이다. 이와 같은 출시 뒤에 있는 문서화된 AI 실패 및 에이전트 사건들은 OrcaRouter AI Incident Archive에 수집되어 있으며, 각 항목은 자체 출처, 심각도, 신뢰도 등급 및 이의 제기 플래그를 포함한다.

Nace가 그 옆에 나란히 놓은 비교 대상은 TypeSafe J​ev 1.14, 해당 카테고리의 요청 형태를 정의한 의사결정 모델, 그리고 오늘날 에이전트가 사용하는 범용 프런티어 모델들이다. Nace가 직접 공개한 표에 따르면, Claude Opus 5.5는 결정 1,000건당 $10.17, 결정당 약 3.5초인 반면, 동일한 243개의 스크린샷 질문에서 Drex Max는 $0.06, 174ms다. 벤더 측 수치이며 자체 실행이고 Nace 외부 누구도 감사하지 않았지만 — 핵심은 자릿수 차이이고, 이것이 이번 릴리스가 벤치마크 행보다 더 중요한 이유다.

실제로 출시된 것

Drex Max는 비전 인코더를 갖춘 Drex 라인의 첫 번째 모델입니다. Drex 2.0과 Drex 1.5는 텍스트를 입력받아 확률을 출력했지만, Max는 스크린샷, 스크린캐스트, 스캔한 문서, 차트, 사진, 동영상 프레임을 읽고 이전 모델들과 동일한 세 가지 유형의 질문에 답합니다.

• 모델 ID — drex-max, 고정됨. 공개 가중치 없음; Nace 자체 API를 통해 호스팅되며 다운로드 가능한 체크포인트는 없습니다.

• 입력 형태 — state 문자열과 questions 객체, 그리고 요청당 최대 8개의 이미지로 이루어진 images 배열입니다. 엔드포인트는 POST /v1/systemone이며, J​ev가 사용하는 것과 동일한 경로입니다.

• 질문 유형 — choice (이름이 지정된 옵션, 옵션별 확률 반환), noul (예/아니오 질문, P(true) 반환), score (순서가 있는 레벨, 기대 레벨과 분포 반환). 한 상태에 관한 여러 질문은 단일 패스를 공유합니다.

• 컨텍스트 — API 가이드에 따르면 이미지 토큰을 포함해 질문당 131,072토큰입니다. 출시 게시물에는 별도로 "262K 토큰 컨텍스트 윈도우"라고 나와 있습니다. 이 두 숫자는 일치하지 않으며, 스크린샷 버퍼 크기를 정하기 전에 가장 먼저 해결해야 할 문제입니다.

• 가격 — 입력 토큰 100만 개당 $0.06이며, 출력에는 요금이 부과되지 않습니다. Nace는 동일한 수치를 결정 1,000건당 $0.06이라고 언급하는데, 이는 호출당 약 1,000개의 토큰을 의미합니다.

• 전작 — Drex 2.0(총 35B, 활성 약 3B, Qwen3.6-35B-A3B 기반, 오픈 가중치)은 결정 1,000건당 $0.06이고, Drex 1.5(9B, 텍스트 전용)는 $0.04입니다.

• 배포 — Nace의 GPU에서 관리형으로, 전용으로, 고객의 AWS 또는 Azure 계정 내에서, 또는 에어갭 환경에서, 모두 동일한 요청 계약으로 제공됩니다. 가중치가 없다는 것은 자체 호스팅이 불가능하다는 뜻이지만, SaaS 전용이라는 뜻은 아닙니다.

인터페이스에는 이국적인 것이 없습니다. 이는 의도된 것입니다: Nace는 Drex Max가 TypeSafe의 J​ev SDK와 와이어 호환되도록 만들었기 때문에, @typesafe-ai/sdk는 기본 URL, 키, 기본 모델만 바꾸면 계속 작동합니다. 이 호환성은 경쟁사에 대한 예의가 아닙니다. 신규 진입자가 시도되는 방식이 바로 이것입니다 — 가장 저렴한 마이그레이션은 설정 값 하나로 끝나는 마이그레이션입니다.

정말로 다른 부분은 문장이 아니라 분포라는 점입니다

채팅 모델은 컴퓨터 사용 질문에 답을 글로 써 내려가는 방식으로 답합니다. "페이지를 보면 검색 결과가 로드된 것 같으니, 다음 동작은 두 번째 결과를 클릭하는 것이어야 합니다" — 그런 다음 하네스는 그 문장이나 JSON 덩어리를 파싱하며, 모델이 당신이 제시한 적 없는 옵션을 고르지 않았기를 바랍니다. 그 설계의 비용은 두 번 지불됩니다. 한 번은 출력 토큰으로, 또 한 번은 모델이 화면에 없는 버튼을 환각할 수 있기 때문에 유지해야 하는 파서로.

Drex Max는 그렇게 할 수 없습니다. Drex Max는 제공한 옵션에 대한 확률만 반환하고 그 외에는 아무것도 반환하지 않습니다. 클릭 가능한 후보 다섯 개를 제시하면 합이 1이 되는 다섯 개의 숫자를 얻게 됩니다. 이는 더 좁은 범위의 기능이며, 데모보다 프로덕션에서 더 중요하게 작용하는 세 가지 이유로 인해 루프에 훨씬 더 잘 맞습니다.

첫 번째는 임계값 설정입니다. 확률 분포가 있으면 실제로 원하는 규칙을 쓸 수 있습니다. 최상위 옵션이 0.9를 넘으면 실행하고, 그렇지 않으면 더 느린 모델이나 사람에게 넘기는 식입니다. 생성 모델은 문장 하나와 전혀 다른 의미를 지닌 신뢰도 필드를 내놓습니다. 보통 그 필드는 토큰 분포가 얼마나 뾰족했는지를 뜻할 뿐, 답이 맞을 가능성을 뜻하지는 않습니다.

두 번째는 실패 동작입니다. 선언된 옵션으로만 답할 수 있는 에이전트는 여섯 번째 버튼을 만들어낼 수 없습니다. 틀릴 수 있고, 보정이 잘못될 수도 있지만, 당신의 하네스가 실행하는 방법을 모르는 동작을 만들어낼 수는 없습니다.

세 번째는 경제성이다. 출력 토큰이 없기 때문에 열 개 옵션을 채점하는 비용은 두 개를 채점하는 비용과 같다. Nace의 설명에 따르면 이 덕분에 매 단계마다 호출할 만큼 비용이 저렴해지며, 호출 1,000회당 0.06달러라면 계산이 맞아떨어진다. 대충 만든 30단계 작업조차 의사결정 비용이 0.2센트 미만이다. Nace의 의사결정당 수치를 기준으로 같은 작업을 Opus 5.5에 대해 수행하면 약 30센트가 들 것이다. 치명적이진 않지만, 그것이 하고 있는 일의 30배 가격이다.

벤치마크 표, 그리고 이 수치들은 누구의 것인가

아래의 모든 수치는 Nace의 출시 게시물에서 가져온 것입니다. Decision Index 0.3.2는 의사결정형 벤치마크의 공개 리더보드이지만, 그에 대한 Drex Max 실행은 공식 키트를 사용한 Nace 자체의 실행이며, Nace 외부의 누구도 이를 재현하지 못했습니다. 이 보드의 "Full" 점수는 이번 실행에 포함되지 않은 비공개 테스트도 함께 반영합니다. 결과의 전체적인 형태는 참고 정보로, 소수점 자릿수는 마케팅으로 취급하세요.

헤드라인 수치는 공개 Decision Index 67.6으로, Drex 2.0의 61.3, Drex 1.5의 58.1, J​ev 1.14의 60.7, GPT-6 Luna Decisions의 47.8과 비교됩니다. 함께 제공되는 Vision Index에서 — 판매 포인트가 ‘보는 것’인 모델에 중요한 수치 — Drex Max는 Luna의 63.9에 맞서 74.5점을 기록합니다.

• Mind2Web — GPT-6 Luna Decisions의 81.2 대비 88.6으로, 브라우저 에이전트에 가장 직접적으로 관련된 항목입니다.

• OSWorld-Verified — GPT-6 Sol의 0.756, Claude Opus 5.5의 0.790과 비교해 0.780입니다. Drex Max는 첫 번째를 이기고 두 번째에는 근소하게 뒤집니다.

• OSWorld-V2 — Sol은 0.744, Opus 5.5는 0.761인 반면 0.737입니다. 같은 양상이지만 격차는 조금 더 큽니다.

• BFCL 도구 호출 — 98.2로 J​ev 1.14의 96.4와 Claude Opus 5.5의 97.3을 앞서며, GPT-6 Sol에만 뒤처집니다.

• DecideBench — 항목에서 98.5점, 쌍에서 97.0점으로 둘 다 Jev 1.14보다 앞섭니다.

• 비즈니스 의사결정 vs J​ev 1.14 — FinEntity 92.3 vs 81.9, BANKING77 90.0 vs 79.7, ContractNLI 75.9 vs 57.7.

OSWorld 관련 행에는 Nace의 표가 명시하지 않은 주의점이 필요합니다. 그 점수들은 전체 자동화 스택을 설명하며, Drex Max를 둘러싼 루프 중 얼마나 많은 부분이 Nace 자체의 하네스였는지는 문서화되어 있지 않습니다. 다음 행동을 잘 고르는 결정 모델이라도 스크린샷을 찍고, 렌더링을 기다리며, 작업이 언제 끝났는지 판단하는 무언가에 여전히 의존합니다. 0.780은 결정이 병목이 아니라는 증거로 읽어야 하며, 당신의 에이전트에 대한 약속으로 읽어서는 안 됩니다.

그것이 뒤지는 쪽, 즉 표에서 더 유용한 절반은 어느 쪽인가

손실은 묻혀 있지 않지만 쉽게 훑고 지나치기 쉬우며, 그중 두 가지는 반올림 오차가 아닌 실제 한계를 설명한다.

일반 지식과 고난도 추론에서 의사결정 모델은 프론티어 채팅 모델과 도저히 경쟁이 되지 않으며, Drex Max도 이를 바꾸지 못한다. MMLU-Pro는 72.5로 J​ev 1.14의 82.1, Sol의 93.0, Opus 5.5의 94.0에 뒤진다. HLE는 19.0으로 J​ev의 19.4에 맞서는데, 어느 쪽이든 범위의 최하단에서의 동률이다. 이는 주어진 화면에서 짧은 목록 중 하나를 고르는 것이 임무인 모델에게 예상되는 일이며, 의사결정 모델이 에이전트의 구성 요소이지 계획을 세우는 모델을 대체하는 것이 아닌 이유다.

더 흥미로운 점은 자사 전작 대비 성능 퇴행이다. 도구 호출이 과연 정당한지를 묻는 When2Call에서 Drex Max는 85.2점을 기록한 반면, Drex 2.0은 86.5점, 더 오래되고 저렴한 Drex 1.5는 89.7점을 받았다. 가장 최신이자 가장 비싼 Drex 모델은 행동하지 말아야 할 때를 아는 능력에서 세 모델 중 최악이다. 워크플로가 절제에 달려 있다면—환불 도구를 호출하기보다 침묵해야 하는 지원 에이전트처럼—비전 기능이 그것을 보장해 주지는 않으며, 더 저렴한 텍스트 모델이 여전히 올바른 선택일 수 있다.

반대 방향으로 가는 두 개의 비전 행에서도 같은 패턴이 나타난다. 스캔된 양식에서의 핵심 정보 추출인 KIE는 95.5로 Luna의 97.5에 맞선다. Hateful Memes 모더레이션은 70.6 대 71.2다. 두 격차 모두 크지 않고, 둘 다 Drex Max가 다른 영역에서 30포인트 차이로 앞서는 도메인에 속해 있다. 이는 비전 인코더가 인쇄된 양식이나 밈보다 화면 레이아웃과 차트 쪽으로 훈련되었음을 시사한다.

지연 시간도 퇴보했습니다. Drex Max의 중앙값 183ms는 Drex 2.0보다 32ms, Drex 1.5보다 38ms 느립니다. 작업당 30회 실행되는 루프에서는 작업당 약 1초가 추가되는 셈인데, 이는 프런티어 모델 대비 단계당 몇 초를 절약하는 것과 맞바꾼 결과입니다. 여전히 올바른 트레이드오프지만, 비전 인코더가 공짜가 아니라는 점은 알아둘 만합니다.

누군가 이 숫자를 인용해 말하기 전에, 분리해서 봐야 할 숫자가 하나 있습니다. 첫 문단의 174 ms는 Nace가 스크린샷만으로 측정한 값입니다. 이미지 질문 243개를 한 번에 하나씩 요청한 측정이며, 같은 세트에서 J​ev 1.14는 253 ms였습니다. 183 ms는 출시 표에 있는 전체 벤치마크 스위트의 중앙값입니다. 둘 다 Nace의 측정값이지만 서로 다른 측정이며, 보기 좋은 쪽이 더 좁은 범위의 측정입니다.

연결하기 전에 API에 있는 두 가지 함정

문서에는 대충 훑어보기만 하면 누군가 오후 한나절을 날리게 될 세부 사항이 하나 있습니다. drex-latest는 Drex Max를 가리키지 않습니다. 이는 고정된 체크포인트이며, 해당 별칭은 다른 대상으로 해석됩니다. 퀵스타트를 따라 키를 교체해 넣고 TYPESAFE_DEFAULT_MODEL=drex-latest를 설정하는 사람 — 바로 J​ev 호환성 지침이 하라고 안내하는 그대로 — 은 텍스트 전용 모델을 호출하게 되고, 자신의 스크린샷이 왜 무시되는지 궁금해하게 될 것입니다.

두 번째 함정은 크기입니다. API 가이드는 질문당 이미지 토큰을 포함해 131,072토큰, 이미지 8개로 요청을 제한합니다. 출시 게시물은 262K를 광고합니다. Nace가 두 수치를 조정할 때까지는 더 작은 수치를 기준으로 크기를 잡으세요. 이미지당 토큰 비용이 공개되어 있지 않아 상한을 미리 추론하기 어렵습니다. 전체 해상도 스크린샷은 고정된 토큰 수가 아니며, 문서에는 이미지가 어떻게 크기 조정되거나 타일링되는지 나와 있지 않습니다.

기존 제품보다 한 가지 더 쉬운 점: Drex Max는 어떤 크기의 스크린샷이든 받아들입니다. J​ev 1.14의 API는 한 변이 280px 미만이거나 1,568px를 초과하는 이미지를 거부하는데, 이런 제약은 새벽 2시의 재시도 루프에서 조용한 실패로 나타나기 마련입니다.

이것이 라우팅 결정에 미치는 영향

실질적인 질문은 Drex Max가 프런티어 모델보다 더 나은지가 아니다. 그렇지 않으며, 그럴 생각도 없다. 질문은 한 작업의 서른 가지 결정 중 어느 것에 프런티어 모델이 합당하고 어느 것에 174 ms 확률 분포가 합당한지이며, 이는 모델 문제이기 전에 라우팅 문제다.

Drex Max는 당사 경로 목록에 없습니다. OrcaRouter 카탈로그에도 실려 있지 않으며, 여기 어떤 내용도 당사의 가용성 주장으로 읽혀서는 안 됩니다 — Nace는 자체 API와 자체 콘솔을 통해 판매합니다. 당사가 실제로 제공하는 것은 이것이 비교 대상으로 삼는 기존 모델입니다. TypeSafe Jev 1.13은 입력 토큰 100만 개당 $0.042에 등록된 경로이며 65,536토큰 컨텍스트에 걸쳐, 동일한 POST /v1/systemone 본문을 통해 제공되므로, 의사결정 모델과 현재의 스크린샷→프런티어 루프 사이의 A/B는 재작성이 아니라 모델 문자열 하나로 끝납니다. 이를 해결하는 저렴한 방법은 텍스트 전용 의사결정 호출은 그대로 두고, 눈이 필요한 작업을 위해 그 옆에 화면 읽기 단계를 추가한 뒤, Nace의 140,178건 채점된 요청이 아니라 자체 로그를 기준으로 둘 다 측정하는 것입니다.

이런 종류의 분할은 조각들이 한 곳에서 접근 가능할 때만 작동합니다. 200개가 넘는 모델에 걸친 하나의 키, 토큰당 마크업 없이 그대로 전달되는 제공업체 목록 가격, 그리고 제공업체 전반에 걸친 자동 페일오버가 바로 설정한 사람이 팀을 옮긴 뒤에도 실험이 낡은 브랜치로 쇠퇴하지 않게 막아주는 것입니다. 여기에는 특정한 이유도 있습니다. Drex Max는 새롭고 감사되지 않았으며 API 전용이므로, 검증되지 않은 구성 요소를 도입하는 안전한 방법은 신뢰도가 떨어지거나 엔드포인트가 오작동할 때 알려진 모델로 폴백할 수 있는 무언가 뒤에 두는 것입니다. 확신 있는 결정은 저렴한 모델로 라우팅하고 나머지는 페일오버가 처리하게 하세요.

무엇이 이 읽기를 바꿀까요?

Decision Index를 독립적으로 실행해 보는 것이 가장 먼저입니다. 이 스위트는 공개되어 있고, Nace는 평가가 재현 가능하다고 말합니다. 그리고 회사 외부의 누군가가 Drex Max를 이 스위트에서 실행하기 전까지 67.6은 공급업체가 제시한 숫자일 뿐입니다. 그때 주목해야 할 셀은 서로 반대 방향을 가리키는 셀들입니다. Mind2Web에서 30포인트 앞서는 것과 When2Call에서의 성능 저하가 나란히 있는 것은 매끄러운 역량 곡선이 아니라, "이 중 어느 것이 다음 클릭인가"에는 강하게, "무언가를 클릭해야 하는가"에는 덜 강하게 훈련된 모델을 설명합니다. 그것이 입증된다면, 이는 Drex Max에 관한 운영상 가장 중요한 사실이며 하이라이트에는 들어 있지 않습니다.

두 번째는 동시성 환경에서의 프로덕션 지연 시간이다. Nace가 직접 제시한 처리량 수치, 즉 H100 레플리카 한 개에서 초당 약 25건의 요청이고 최대 64건이 동시에 처리 중일 때까지 오류가 없다는 수치는 Drex 전반에 해당하는 것이지, 특별히 Max에 대한 것은 아니다. 이 설계의 핵심 세일즈 포인트는 모든 단계에서 핫 패스에 자리한다는 점이며, 이 때문에 부하 상황의 p95가 183 ms 중앙값보다 훨씬 더 중요해지는데, 이를 다룬 공개 자료는 없다.

셋째, 가격 책정에는 이미지가 포함된 구체적인 예시가 필요합니다. 입력 토큰 100만 개당 $0.06이라는 가격은 스크린샷 하나에 토큰이 얼마나 드는지 알아야만 유용하며, 공개된 어떤 수치도 이를 알려주지 않습니다. 각 단계마다 1440p 화면을 사용하는 30단계 루프의 예산을 세우는 팀은 Nace가 이미지 원가 계산을 공개하거나 누군가 측정하기 전까지는 추측에 불과합니다.

그렇다고 해서 그 릴리스가 덜 흥미로운 것은 아니다. 보는 결정 모델은 스크린샷을 보라는 요청을 받는 채팅 모델과는 진정으로 다른 구성 요소이며, 가격 격차는 에이전트가 매 단계에서 감당할 수 있는 일을 바꿀 만큼 크다. 다만 그것은 아직 Nace 외부의 누구도 확인한 숫자가 아닐 뿐이며 — 실제 배포와 맞닥뜨려 살아남는 표의 일부는 아마도 아무도 인용하지 않는 부분일 것이다.