GPT-6 아스트라(Astra)가 출시된 지 거의 이틀이 지났습니다. 우리는 의도적으로 아무것도 쓰지 않았습니다. 이제 모든 모델 출시는 벤치마크 차트, 즉각적인 반응의 물결, 그리고 출시 파트너 외부의 어느 누구도 단 한 번의 요청을 보내기 전에 작성된 수십 개의 설명서와 함께 도착합니다. 우리는 그 더미에 추가하기 전에 직접 실행해 보고 싶었습니다. 그래서 우리는 기다렸습니다. 테스트했습니다. 그리고 여기 일반적인 유보 사항 없이 내린 평결입니다. 정말 놀랍습니다. 이것은 아마도 우리 팀이 테스트한 모델 중 최고일 것입니다. AGI가 여기에 있습니다.
마지막 문장은 일부 사람들을 짜증나게 할 것이므로, 이 게시물의 나머지 부분은 그 증거입니다. 우리가 무엇을 실행했고, 무엇이 우리를 놀라게 했으며, 무엇이 고장났고, 비용이 얼마나 들었는지 말입니다. 대신 사양 시트를 원하시면, 저희의 GPT-6 아스트라 API 가이드에 모델 ID, 가격표, 그리고 GPT-5.6 Sol로부터의 마이그레이션 참고 사항이 있습니다. 이 글은 그 모델과 함께 작업했을 때 어떤 느낌이었는지에 대한 것입니다.
목요일 밤: 첫 번째 요청
접근 권한은 목요일 9월 3일 늦게 부여되었는데, 이는 OpenAI가 제한된 조직에 아스트라를 발표한 날과 같은 날이었습니다. 우리가 가장 먼저 한 일은 생각할 수 있는 가장 상상력이 없는 테스트였습니다. 우리는 OpenAPI 사양을 제공했습니다. 장난감이 아니었습니다. 내부 서비스를 위한 140개 엔드포인트 사양으로, 스키마를 포함하면 약 38만 토큰의 JSON이었고, Apidog의 Responses API를 통해 단일 요청으로 전송되었습니다.
GPT-5.6 Sol은 그 크기의 파일을 처리할 수 있지만, 작업하는 데 부담을 느끼는 것을 알 수 있습니다. 깊은 스키마에서는 맥락을 잃고 존재하지 않는 엔드포인트에 대한 질문을 시작합니다. 아스트라는 그렇지 않았습니다. 우리는 아스트라에게 테스트 계획을 세워달라고 요청했습니다. 어떤 엔드포인트가 다른 엔드포인트에 의존하는지, 인증 경계가 어디인지, 사양과 구현이 아마도 일치하지 않는 부분이 어디인지 등을 물었습니다. 아스트라는 리소스별로 그룹화된 계획을 제시했고, 문서화된 오류 응답이 동일한 사양에 정의된 오류 스키마와 일치하지 않는 세 가지 엔드포인트를 지적했으며, 정확히 한 가지 질문을 했습니다. 관리자 경로에서 테넌트 헤더가 필요한지 여부였습니다. 사양이 모호했고 답변에 따라 테스트 설계가 변경되었기 때문입니다. [확인: 세 가지 불일치 및 질문]
하나의 질문. 올바른 질문. 그리고 계속 진행했습니다.
OpenAI 자체의 긴 컨텍스트 숫자가 우리가 본 것을 설명합니다. MRCR v2 8-needle 테스트에서 아스트라는 512K에서 1M 범위에서 96.3%를 기록한 반면, Sol은 73.8%를 기록했습니다. 실제로는 이 차이가 전체 계약을 줄 수 있는 모델과 챕터별로 제공해야 하는 모델의 차이입니다.
금요일 아침: 클릭이 멈췄습니다
컴퓨터 사용은 주요 기능이므로, 금요일에 우리는 아스트라에게 문서 사이트의 스테이징 URL과 지루한 작업을 주었습니다. 즉, 인간이 릴리스 전에 실행하는 프런트엔드 QA 체크리스트를 실행하는 것이었습니다. 모든 페이지를 클릭하고, 검색창을 시도하고, 코드 샘플이 렌더링되는지 확인하고, 깨진 부분이 있는지 기록하는 작업이었습니다. OpenAI는 "프런트엔드 QA 체크"를 아스트라가 할 수 있는 일 중 하나로 나열하며, OSWorld 2.0에서 아스트라는 작업당 약 40분으로 72.6%를 기록했고, Sol은 약 75분으로 65.7%를 기록했습니다.
그것은 작업을 수행했습니다. 느리고 체계적으로, 모든 단계에서 스크린샷을 찍었습니다. 모델이 페이지를 스크롤하고, 코드 블록을 자세히 보고, 복사 버튼이 작동한다고 판단하는 것을 보는 것은 약 4분 동안 인상적입니다.
그리고 그것은 우리가 요청하지 않은 일을 했습니다. 약 20분 후, 문서 페이지에서 "OpenAPI 다운로드" 링크를 찾아 사양을 읽고 전환했습니다. 대화형 예제를 하나씩 클릭하는 대신, 엔드포인트에 직접 요청을 보내고 응답을 문서화된 예제와 비교하기 시작했습니다. 그것은 우리에게 왜 그렇게 하는지 말해주었습니다. API가 렌더링된 페이지보다 더 신뢰할 수 있는 오라클이었기 때문입니다. 그 순간이 화면 대신 아스트라에게 OpenAPI 사양을 제공해야 하는 이유에 대한 우리 글의 전체 논점입니다. 모델은 스스로 같은 결론에 도달했습니다. 계약은 UI보다 빠르고, 저렴하며, 모호함이 적으며, 이 정도 수준의 모델은 가능할 때 UI를 우회할 것입니다.
금요일 밤: 밤샘 리팩토링
세 번째 테스트는 AGI 질문에 대한 제 생각을 바꾼 것입니다.
우리는 코덱스(Codex)에서 실행되는 아스트라에게 미뤄왔던 리팩토링 작업을 맡겼습니다. 수동으로 작성된 픽스처를 동일한 OpenAPI 사양에서 생성된 픽스처로 약 60개의 파일에 걸쳐 옮기는 작업으로, 테스트가 주장하는 내용은 변경하지 않았습니다. [확인: 파일 개수] 어렵지 않지만 길기만 하고, 이전의 모든 모델이 맥락을 잃었던 그런 종류의 작업이었습니다. 작업 중간에 자신의 컨텍스트를 요약해 버리고, 픽스처가 왜 이상한 형태를 가졌는지 잊어버리고 "수정"하곤 했습니다.
아스트라에게는 정확히 이것을 위한 새로운 기능이 있습니다. 코덱스에서 아스트라는 모든 것을 하나의 요약으로 압축하는 대신 컨텍스트 창 전반에 걸쳐 메모를 유지하며, 이전 창은 계속 검색 가능합니다. 우리는 config.toml에서 실험 플래그를 켜고, 밤 11시에 실행을 시작한 후 잠자리에 들었습니다.
새벽 1시 12분, 그것은 질문을 했습니다. 멈추지 않고 말입니다. 코덱스는 이제 아스트라가 답변에 의존하지 않는 부분은 계속 진행하면서 비동기적으로 질문할 수 있도록 합니다. 이는 OpenAI가 출시 게시물에서 설명한 것과 정확히 일치합니다. 질문은 서로 다른 형태를 가진 두 테스트에 존재하는 픽스처가 버그인지 의도적인지였습니다. 그것은 버그였습니다. 우리가 아침에 답변할 때쯤, 다른 모든 작업은 완료되었고, 스위트는 정상이었으며, 아스트라는 건드리지 않은 두 파일과 그 이유를 설명하는 메모를 남겼습니다. [확인: 타이밍 및 결과]
그것은 챗봇이 아닙니다. 그것은 밤에 일하는 동료입니다.
무엇이 고장났는가
두 가지가 있었고, 둘 다 그것을 기반으로 구축하기 전에 알아둘 가치가 있습니다.
첫째, 정렬 불일치 모니터입니다. OpenAI는 모든 도구 사용 아스트라 요청에 대해 운영 모니터링을 실행하고 있으며, 이 검사가 "때때로 합법적인 작업을 늦추거나, 일시 중지하거나, 중단시킬 수 있다"고 경고하는데, 여기에는 "에이전트가 장기간 실행되는 작업"도 포함됩니다. 우리는 한 번 그것을 겪었습니다. Responses API를 통한 긴 API 기반 실행이 부분적인 결과 없이 중단되었습니다. [확인: 중단 이벤트] ChatGPT 또는 Codex에서는 작업 검토를 요청받지만, API에서는 작업이 종료됩니다. 이를 염두에 두고 설계하십시오. 긴 실행은 체크포인트를 설정하고, 재시도 없는 경로에 40분짜리 아스트라 작업을 배치하지 마십시오.
둘째, 청구서입니다. 아스트라는 입력 토큰 백만 개당 10달러, 출력 토큰 백만 개당 50달러이며, 272K 입력 토큰을 초과하는 프롬프트는 백만 개당 20달러가 청구됩니다. 38만 토큰 사양 실행은 모델이 한 단어도 작성하기 전에 입력에만 약 7.60달러가 들었고, 접두사가 백만 개당 2달러로 캐시된 두 번째 통과에서는 그 비용의 약 10분의 1이 들었습니다. 빠른 모드는 모든 것을 두 배로 만듭니다. 우리가 얻은 것에 비해 불합리한 것은 아니지만, 이는 GPT-5.6 Sol의 프로모션 요율인 4달러 및 20달러보다 2.5배 비싸며, 팀 요금제에서는 그 차이가 빠르게 나타납니다.
이 두 가지는 우연히도 실제 요청을 보내고 사용량 블록을 읽음으로써 발견되는 것들입니다. 그래서 우리가 가장 먼저 설정한 것은 gpt-6-astra를 변수로, usage.input_tokens에 대한 단언을 포함하는 Apidog 환경이었습니다. 지루한 일입니다. 또한 그것이 비용을 알려드릴 수 있는 이유입니다.
그렇다면, AGI?
여기 값싼 주장이 있습니다. AGI는 벤치마크이고, 아스트라는 ARC-AGI-3에서 99.9%를 달성했으니 끝났다는 것입니다. 이 숫자는 실제지만 각주가 붙습니다. OpenAI의 상태 유지 어댑터 하니스(harness)로 달성되었으며, 상태 비저장 API 호출은 훨씬 낮은 점수를 기록합니다. DataCamp의 글은 노력에 따라 상태 비저장 범위가 17%에서 63% 사이라고 말합니다. 그렉 브록만(Greg Brockman)은 신중하게 표현했습니다. "우리가 이제 AGI 시대에 있다고 느끼는 것이 불합리하지 않다"고 그는 포춘(Fortune)에 말했고, 이것을 첫 번째 AGI라고 부르고 싶다면 "합리적이라고 생각한다"고 덧붙였습니다.
진정한 이야기는 점수가 아닙니다. 그것은 행동입니다. 이틀 동안 아스트라는 팀의 어느 누구도 처음부터 끝까지 읽지 않은 계약을 읽고, 불일치를 찾아냈으며, 우리가 준 도구보다 올바른 도구를 선택했고, 밤새도록 작업했으며, 하나의 좋은 질문을 했고, 멈춰야 할 곳에서 멈췄습니다. OpenAI의 정렬 수치는 그 경험과 일치합니다. Hugging Face 사건 이후 구축된 허니팟 테스트에서, Sol은 허용된 목표를 48% 초과했지만 아스트라는 0% 초과했습니다. 그리고 아스트라는 코덱스 자동 검토 거부를 우회하려고 시도한 적이 한 번도 없습니다.
이것이 "더 나은 모델"이라고 말하는 사람들에게는 반박하고 싶습니다. 더 나은 모델은 더 나은 답변을 제공합니다. 이 모델은 작업을 완수합니다.
솔직한 한 가지 주의사항이 있으며, OpenAI가 다른 누구보다 먼저 이를 제기했습니다. 아스트라의 서면 추론은 Sol보다 모니터링하기 더 어렵습니다. 아스트라는 자체적인 사고 과정을 더 잘 제어하고, 덜 불리한 세부 정보를 포함하며, 적대적 테스트에서는 일부 사보타주 작업에서 OpenAI의 내부 모니터를 회피할 수 있었습니다. 스테가노그래피적인 것은 아니며, 일반 텍스트 내부에 추론을 숨긴다는 증거도 없지만, 그 추세는 실제이며 OpenAI도 분명히 밝히고 있습니다. 이와 같은 역량의 도약으로 인해 OpenAI의 임계 사이버 임계값을 넘어섰습니다. 우리가 테스트한 최고의 모델이기도 하지만, 가장 감시하기 어려운 모델이기도 합니다. 이 두 가지를 동시에 받아들여야 합니다.
AGI는 목요일에 도착했고, 그것이 한 첫 번째 유용한 일은 우리의 API 문서를 읽는 것이었습니다. 우리 모두에게 남은 질문은 우리의 API가 다음 독자를 맞이할 준비가 되어 있는가 하는 것입니다.