Codex의 GPT-6 Astra: 창 간 노트, 에포트 레벨, 그리고 실제 청구서

GPT-6 Astra는 2026-09-03 모델이며, 이 페이지는 출시 보도가 아닙니다 — 이는 이제 널리 사용 가능해진 이 모델에 코딩 에이전트를 연결하기 위한 참조 자료입니다. 개발자가 전환하는 이유는 하나의 특정 메커니즘 때문이며, 여기에 비용을 지출하기 전에 이해할 가치가 있습니다: 창이 가득 찰 때마다 긴 세션을 하나의 손실 요약으로 압축하는 대신, GPT-6 Astra와 함께하는 Co​dex는 컨텍스트 창 전반에 걸쳐 노트를 유지하고 이전 컨텍스트 창을 검색 가능하게 남겨두므로, 40턴 전에 언급한 요구사항과 10턴 전에 실패한 테스트 출력 모두 요약되어 사라지는 대신 여전히 검색할 수 있습니다. Ope​nAI는 이 기능을 실험적이라고 부르며, Co​dex config.toml에 한 줄을 추가하여 활성화하고, Astra의 기본값이 될 것이라고 말합니다. 아래의 모든 내용 — 정확한 구성, 노력 수준, 측정된 결과, 그리고 캐시된 입력 줄을 명시한 실제 세션 청구서 — 은 2026-09-16에 Ope​nAI 자체 페이지에서 읽은 것이며, 모든 제3자 수치는 그렇게 표시되어 있습니다.

이번 주에 두 가지 일이 있었는데, 이는 그것을 도입하는 셈법을 바꿉니다. 2026-09-12에 Ope​nAI의 Co​dex 리드는 컨텍스트 관리 실험 자체에 버그가 있었다는 것을 확인하는 사후 분석을 게시했습니다. 그 버그는 조기 중단과 오래된 메시지에 대한 답장을 일으켰고, 그 실험을 쓰던 약 4,000~5,000명의 사용자에게서 비활성화되었습니다. 그리고 Ope​nAI는 09-12에서 09-13으로 넘어가는 자정에 Co​dex 및 Astra 사용자를 위해 전체 사용량 초기화를 시행했습니다. 같은 주에, 출시 당시 기본적으로 Astra가 꺼져 있던 엔터프라이즈 워크스페이스가 자체 요금표에 따라 관리 가능해졌습니다. 그러므로 솔직한 입장은 이렇습니다: 이 메커니즘은 도입할 가치가 있고, 빌드는 아직 당신 발밑에서 움직이고 있으니, 마감 기한이 아니라 브랜치에서 시도해 보십시오.

GPT-6 Astra와 함께하는 Co​dex에서 실제로 새로운 점은 무엇인가요?

코딩 에이전트에게 여섯 시간 동안 작업하라고 시키면, 똑같은 벽에 부딪힌다. 컨텍스트 윈도우가 가득 차고, 하네스는 자리를 만들기 위해 대화 기록을 하나의 빽빽한 블록으로 요약하며, 그 요약은 정확히 가장 아프게 손실되는 방식으로 손실된다. 이전 수정이 실패한 이유, 실패하는 테스트의 정확한 형태, 사용자가 세 번째 턴에서 곁다리로 언급한 제약 조건 같은 것들이 그렇다. 당신이 실제로 원했던 것은 요약된 세부 사항이 아니라 검색된 세부 사항이다.

Astra의 Codex 통합은 그 형태를 바꿉니다. OpenAI의 Codex 문서는 이를 명확히 밝힙니다: "Astra는 컨텍스트 창 전반에 걸쳐 노트를 유지하며, 같은 작업의 이전 메시지와 도구 결과를 검색할 수 있습니다." 노트는 영구적이고 쓰기 가능하며, 그 뒤의 기록은 읽을 수 있는 상태로 유지되므로, 해당 노트가 작성된 후에도 원래 증거를 찾기 위해 이전 창을 여전히 검색할 수 있습니다. 이전 메시지와 도구 출력에서 나온 요구 사항과 테스트 결과도 계속 찾을 수 있습니다.

Ope​nAI는 이것이 완성된 작업이 아니라고 분명히 밝힌다. 구성 참조 문서에서는 이 플래그를 "실험적 컨텍스트 관리를 활성화합니다(기본적으로 꺼짐)"라고 설명하며, 이 기능이 "노트와 검색 가능한 기록을 사용해 누적된 세부 정보를 보존한다"고 말한다. 문서는 또한 이 기능이 "출시 시점에는 Business, Enterprise 또는 API 키 로그인으로는 사용할 수 없다"고 명시한다. 이것 역시 무한 컨텍스트가 아니다. 모델은 여전히 유한한 윈도우 안에서 추론하며, 이전 노트를 다시 읽을 때마다 해당 턴의 입력 예산을 소모한다. Ope​nAI의 모델 문서에 따르면 윈도우는 1,050,000 토큰이고 최대 입력 토큰은 922,000개다. 노트 메커니즘은 그 위에 올라가는 것이지, 그것을 대체하지 않는다.

OpenAI가 문서에 명시한 그대로의 config

이 설정은 Codex config.toml의 [features] 테이블의 하위 항목입니다. 이 파일은 CODEX_HOME을 재정의하지 않은 경우 ~/.codex/에 있습니다. 문서에 나온 키 경로는 features.context_management.experimental_mode이며 불리언이고, 값은 true입니다:

[features.context_management]
experimental_mode = true

파일에 [features] 테이블이 이미 있다면, 테이블을 두 번 선언하지 말고 그 안에 관련 키를 추가하세요:

[features]
context_management.experimental_mode = true

둘 중 하나의 형식을 사용하세요. 플래그 보고서에 관한 커뮤니티 글에서는 루트에 점 표기 경로를 선언한 다음 같은 파일 뒤쪽에서 [features] 테이블을 열면 재선언된 테이블로 인해 파싱에 실패할 수 있다고 보고합니다. 이는 OpenAI의 규칙이라기보다 TOML 규칙이지만, 사람들이 자주 겪는 문제이므로 한 가지 형식을 골라 계속 사용하세요. 편집한 후에는 새 작업을 시작하세요: 설정은 이미 실행 중인 세션에 소급 적용되지 않습니다.

같은 파일의 모델 부분은 별다를 게 없으며, Ope​nAI의 참조 문서에서는 이 키들을 직접 설명합니다 — model은 "사용할 모델"이고, model_provider의 기본값은 openai입니다:

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

문서 버전을 읽을 때 한 가지 주의할 점이 있습니다. Codex 구성 참조는 model_reasoning_effort가 minimal, low, medium, high, xhigh를 허용한다고 나열하며, xhigh는 모델에 따라 다르다고 언급합니다. 반면 gpt-6-astra에 대한 OpenAI의 API 모델 페이지는 reasoning.effort를 low, medium, high, xhigh, max로 문서화합니다. 클라이언트 슬라이더와 API는 동일한 집합을 설명하지 않으므로, effort를 명시적으로 설정하고 가정하지 말고 클라이언트가 무엇을 받아들였는지 확인하십시오.

모델 선택 — 그리고 사람들을 함정에 빠뜨리는 액세스 규칙

OpenAI의 Codex 모델 문서에는 CLI 형식이 그대로 나와 있습니다: codex -m gpt-6-astra. 대화형 세션에서는 /model이 모델을 전환하고 추론 강도를 조정합니다. 단일 실행에서는 codex exec -m gpt-6-astra "Review the current changes"도 같은 방식으로 작동합니다. 데스크톱 앱과 IDE 확장 프로그램에서는 모델 컨트롤이 작성 창 아래에 있습니다.

접근 규칙은 사람들이 실수하는 부분이며, 두 기능의 게이트가 서로 다르기 때문에 두 번 읽을 가치가 있습니다:

• 이 모델은 ChatGPT Work, Co​dex, API 전반에서 사용할 수 있으며 Microsoft Azure와 AWS Bedrock에서도 제공됩니다. Ope​nAI의 출시 페이지에 따르면 Astra는 "오늘 제한된 일부 조직을 대상으로 순차 배포되기 시작했으며, 앞으로 며칠에 걸쳐 모든 ChatGPT Plus, Pro, Business, Enterprise 사용자가 이용할 수 있게 될 것"이라고 밝혔습니다.

• 실험적 컨텍스트 관리 — 범위가 더 좁습니다. OpenAI의 문서에는 이 기능이 "Plus, Pro 또는 Pro Lite에서 ChatGPT 로그인이 필요하다"고 명시되어 있으며, "출시 시점에는 Business, Enterprise 또는 API 키 로그인으로는 사용할 수 없습니다"라고 밝히고 있습니다.

그 두 번째 줄이 바로 내면화해야 할 부분이다. API 키로 gpt-6-astra를 호출할 수 있고, Business 플랜으로 그 비용을 지불할 수도 있다. 하지만 창 간 노트 기능은 거기 없을 것이다. 노트 메커니즘이 전환하려는 이유라면, 필요한 것은 Codex 클라이언트에서의 Plus, Pro 또는 Pro Lite ChatGPT 로그인이지 API 키가 아니다. Ope​nAI는 이를 "롤아웃, 로그인 방식, 클라이언트"에 따라 달라지는 가용성이라고 설명하는데, 이는 같은 말을 정중하게 표현한 것이다.

추가로 두 가지 주의사항이 있으며, 이는 공급업체가 문서화한 내용이라기보다 보도된 내용으로 표시되어 있습니다. 롤아웃 관련 보도에서는 Astra에 Codex CLI 버전 0.153.0 이상이 필요하다고 밝히지만, 우리는 OpenAI 자체 페이지에서 해당 최소 버전을 확인할 수 없었습니다. 그리고 Codex 문서는 모델 선택기 프리셋 — Astra Light, Astra Medium, Astra Extra High — 을 설명하며, 이는 자격을 갖춘 Pro, Business($100), Enterprise 계정에 추론 슬라이더와 함께 제공됩니다. 이는 별도 제품이 아니라 선택기 내 위치입니다: OpenAI는 하나의 모델 ID인 gpt-6-astra를 하나의 사양 세트와 하나의 가격으로 문서화하며, "Astra Pro" 또는 "Astra Medium" 구성에 대해 별도의 사양이나 요금을 공개하지 않습니다. 이름이 지정된 Astra 등급에 대해 인용된 모든 수치는 미검증으로 취급하십시오.

프로덕션 경로를 이 모델로 확정하기 전에 시험해 보고 싶다면, 현재 모델과 함께 하나의 엔드포인트를 통해 라우팅하는 것이 알아볼 수 있는 저렴한 방법입니다 — GPT-6 Astra는 OrcaRouter 카탈로그에 있으므로, 비교 실행에 드는 비용은 두 번째 계약과 두 번째 SDK가 아니라 모델 문자열 하나입니다.

추론 노력: 다섯 단계, 그리고 각 단계에 드는 비용

OpenAI의 gpt-6-astra API 문서에는 다섯 가지 추론 노력 수준—low, medium, high, xhigh, max—이 나열되어 있으며, Codex 지침은 이들을 사용하는 방법에 대해 단호합니다: "필요한 결과를 내는 가장 낮은 추론 노력 수준을 사용하세요," 그리고 기본값에서 시작해, 작업에 더 깊은 계획이 필요할 때 수준을 높이세요.

이 모델에서 특히 그 조언을 무시하는 데 비용이 많이 드는 이유는 추론 토큰이 청구서에 어디로 잡히는지에 있습니다. 추론 토큰은 출력 토큰이며, Astra의 출력은 백만 개당 $50.00입니다 — 입력 요율의 10배, 캐시된 입력 요율의 50배입니다. 따라서 이 트레이드오프는 추상적이지 않습니다:

• 턴당 추가 추론 토큰 1,000개마다 출력 요금으로 $0.05가 부과됩니다.

150턴 세션 전체에서 턴당 추론 토큰을 1,000개 더 유지하면 약 $7.50의 비용이 들고, 5,000개 더 유지하면 약 $37.50이 듭니다.

• 아래 예시 세션에서 출력은 이미 턴당 $0.200로 $0.090의 캐시 읽기에 맞서는 가장 큰 단일 항목입니다 — 추론의 증가가 총합을 가장 빠르게 움직이는 요인입니다.

OpenAI가 공개하지 않는 것은 노력 수준별 표입니다: xhigh나 max가 코딩 작업에서 medium 대비 추론 토큰을 얼마나 내보내는지에 대한 벤더 수치는 없고, 노력 수준별로 세분화된 벤더 벤치마크도 없습니다. 정확한 "max는 2배 든다" 비율을 인용하는 사람은 누구든 OpenAI의 측정값이 아니라 자신의 측정값을 인용하는 것입니다. 정직한 방법은 대표 작업 하나를 두 노력 수준에서 실행하고 응답의 사용량 블록을 읽는 것입니다 — 그 숫자에 백만 개당 $50을 곱한 것이 바로 실제 노력 프리미엄입니다.

각각 자체 출처를 지닌 측정 결과

코딩 및 터미널 작업 관련 수치로, 별도 표기가 없는 한 모두 Ope​nAI가 보고한 값이다. Terminal-Bench 4.0: GPT-6 Astra가 57.9%로, GPT-5.6 Sol의 37.3%와 Claude Fable 5.1의 55.8%를 상회한다. Ope​nAI는 작업당 API 비용이 GPT-5.6 Sol 대비 약 9%, Claude Fable 5.1 대비 63% 더 낮을 것으로 추산한다. Datacurve의 DeepSWE v1.1에서 Astra는 Datacurve 자체 벤치마크 기준 74.1%를 기록했는데, Datacurve는 이를 신기록이라고 설명하며 일부 보도에서는 74%로 반올림해 전한다. 더 넓은 에이전트 벤치마크에서는 Ope​nAI가 OSWorld 2.0에서 작업당 약 40분에 72.6%를 보고했으며, 이는 GPT-5.6 Sol보다 작업당 시간이 약 47% 적은 수치다. 아울러 FrontierMath Tier 4 98%, ARC-AGI-3 99.9%, ExploitBench 100%를 함께 보고했는데, Ope​nAI는 이들 모두를 포화되었거나 사실상 포화된 등급이라고 설명한다. 이는 벤더 측 수치이며, 우리가 이를 재현한 것은 아니고, ARC Prize가 ARC-AGI-3 수치를 독립적으로 검증한 결과 그 수치가 특수한 제공자 어댑터 환경에서 측정된 것이며 표준 조건에서는 그보다 낮아지는 것으로 나타났다.

벤더 번호가 아닌 부분이야말로 코드 리뷰 워크플로가 가장 중요하게 여겨야 할 부분이다. CodeRabbit은 2026-09-04에 Astra에 대한 자체 평가를 공개했으며, 그 결과는 헤드라인보다 좁다. 여러 파일에 걸친 풀 리퀘스트 — 변경 사항을 코드베이스 다른 곳의 결과와 연결해야 하는 어려운 리뷰 — 에서 Astra는 GPT-5.6 Sol보다 약 20% 더 많은 버그를 잡아냈고, 실행 가능한 버그 커버리지는 57.1% 대 47.6%였다. 전체 리뷰에서는 이득이 대부분 사라진다: 61.3% 대 59.0%로 약 4% 더 높다. CodeRabbit은 둘 다 순위를 세우지 못하는 "초기 방향성 결과"라고 규정하고, 자사 방법이 개선의 원인을 분리하지 못한다고 지적한다. Ope​nAI의 출시 페이지는 같은 작업을 "여러 파일에 걸친 풀 리퀘스트에서 두 배 이상"이라고 표현한다; CodeRabbit의 자체 글은 위의 20%와 커버리지 비율을 제시한다. 요약이 아니라 비율을 읽어라.

그 비대칭성은 이 페이지에서 모델을 어떻게 배포할지 결정하는 데 가장 유용한 단일 수치이며, 가격과 같은 방향을 가리킵니다. 즉 이득은 파일 간 추론에 집중되어 있으므로, 바로 그곳에 모델을 투입해야 합니다.

What computer use in Co​dex changes for your workflow → Codex에서의 컴퓨터 사용이 워크플로에 어떤 변화를 가져오는가

Ope​nAI는 업데이트된 Co​dex 하네스 덕분에 Mind2Web에서 GPT-6 Astra가 현재 GPT-5.6 Sol 경험보다 작업 완료 속도가 1.9배 빠르다고 말합니다. Mind2Web은 웹 작업 자동화이므로, 이렇게 해석하세요: 브라우저나 GUI를 다뤄야 하는 에이전트 작업이 실질적으로 더 빨리 끝나며, Co​dex를 사용할 때면 언제나 바로 그 업데이트된 하네스를 실행하게 됩니다. 함께 제시된 수치는 위의 OSWorld 2.0 결과입니다 — 작업당 약 40분에 72.6%로, Sol보다 작업당 시간이 약 47% 적습니다.

개발자에게 실질적인 결과는 무엇을 위임할 가치가 있는지가 달라진다는 점이다. 이전에는 엔드투엔드 자동화를 하기에는 너무 느렸던 워크플로 — API가 없는 스테이징 콘솔을 조작하기, UI를 통해 버그를 재현하기, 다단계 양식을 거쳐 픽스처를 생성하기 — 는 이제 사람이 직접 하는 것보다 에이전트 실행이 더 저렴한 범위 안으로 들어온다. 또한 이는 OpenAI가 함께 출시한 엔터프라이즈 측 제어의 가치를 높인다. ChatGPT Work와 Codex는 확인 정책, 즉 중대한 작업 전 승인과 안전하지 않거나 권한이 없는 도구 호출에 대한 자동 검토를 추가한다. 에이전트가 실제 인터페이스를 클릭해 나가도록 한다면, 그 검토 계층이야말로 잘못된 실행이 엉망인 오후로 번지지 않게 막아 주는 것이다 — 그리고 그것이 엔터프라이즈 액세스가 기본적으로 꺼져 있고 관리자가 적용 가능한 요금표에 따라 이를 활성화하도록 되어 있는 것이 장애물이 아니라 거버넌스 기능인 이유다.

워크플로에 가격을 매기고, 토큰이 아니라

이름과 날짜가 명시된 가격은 다음과 같습니다. Ope​nAI의 가격 페이지(2026-09-16 확인)에 따르면, gpt-6-astra standard는 100만 입력 토큰당 $10.00, 100만 캐시 입력 토큰당 $1.00, 100만 캐시 쓰기당 $12.50, 100만 출력 토큰당 $50.00입니다. Batch와 Flex에는 해당 요금의 절반이 적용되고, Fast 모드에는 두 배가 적용됩니다. 에이전틱 루프에서 청구서를 결정하는 것은 바로 그 캐시 입력 항목입니다. 코딩 에이전트는 매 턴마다 대부분 변경되지 않은 큰 컨텍스트를 다시 전송하고, 캐시 입력은 새 입력 비용의 10분의 1이기 때문입니다.

산술을 적용하기 전에 중요한 두 가지 임계값이 있습니다. Ope​nAI의 모델 문서에 따르면 272,000 입력 토큰을 초과하는 프롬프트는 입력 및 캐시 요금의 2배, 출력의 1.5배로 청구됩니다전체 요청에 대해 — 초과분만이 아니라 — 그리고 요금 페이지에는 롱 컨텍스트 행이 입력 $20.00, 캐시된 입력 $2.00, 출력 $75.00으로 나와 있습니다. 또한 위에서 설명한 대로 모든 추론 토큰은 출력 요금으로 청구됩니다.

현실적인 야간 리팩터링을 하나 들어 보자: 모델 턴 150회, 턴당 평균 입력 토큰 100,000개. 그중 90,000개는 캐시 읽기이고 10,000개는 새 입력이며, 턴당 출력 토큰은 추론을 포함해 4,000개다. 272K 임계값 미만에서 표준 요율을 적용하면:

• 캐시된 입력 — 90,000 토큰 × 백만당 $1.00 = 턴당 $0.090

• 신규 입력 — 10,000 토큰 × 백만 개당 $10.00 = 턴당 $0.100

• 출력 — 4,000 토큰 × 백만 개당 $50.00 = 턴당 $0.200

• 합계 — 턴당 $0.390, 따라서 150턴이면 세션당 약 $58.50

이제 동일한 세션을 임계값 위로 넘겨 보겠습니다. 턴당 입력 토큰이 300,000개일 때 — 270,000개는 캐시, 30,000개는 신규 — 전체 요청의 가격이 다시 산정되므로, 캐시된 입력은 두 배로 올라 $2.00가 되고, 신규 입력은 두 배로 올라 $20.00가 되며, 출력은 $75.00가 됩니다:

• 캐시된 입력 — 270,000 × 백만당 $2.00 = 턴당 $0.540

• 신규 입력 — 30,000 × 백만당 $20.00 = 턴당 $0.600

• 출력 — 4,000 × 백만 개당 $75.00 = 턴당 $0.300

• 총계 — 턴당 $1.44, 또는 150턴 기준 약 $216.00

동일한 작업 형태, 대략 3.7배의 비용, 그리고 그 모든 차이는 당신의 트랜스크립트가 272,000 토큰의 어느 쪽에 있느냐에 달려 있습니다. 이것이 노트 메커니즘에 대한 논거를 한 줄로 요약한 것입니다: 만약 지속적인 노트와 검색 가능한 기록이 전체 트랜스크립트를 끌고 가는 대신 작업 컨텍스트를 더 간결하게 유지할 수 있게 해준다면, 그 기능은 품질에 도움이 되기 전에 입력 토큰 면에서 이미 비용을 회수합니다. 또한 이는 무인 실행이 트랜스크립트를 상한 없이 키우도록 내버려두지 말아야 하는 이유이기도 합니다.

규모를 가늠해 보면, 동일한 토큰 프로필로 같은 150턴 세션을 더 저렴한 등급에서 돌릴 경우: GPT-5.6 Terra는 공개된 입력 $2.00 / 캐시 $0.20 / 출력 $12.00 기준으로 약 $12.90이 나오고, GPT-5.6 Luna는 $0.20 / $0.02 / $1.20 기준으로 대략 $1.29가 나온다. 이는 Ope​nAI가 공개한 요율에 대한 산술 계산일 뿐, 이들이 동일한 작업을 완수할 것이라는 주장이 아니다. 그리고 바로 그 점이 다음 두 섹션의 핵심이다.

이 모든 것을 여러 제공업체와 비교하고 있다면, OrcaRouter가 그렇게 한다는 점을 알아두는 것이 좋습니다. 제공업체 목록 가격을 0% 마크업으로 전달합니다.따라서 공급업체 가격 변경은 다음 인보이스가 아니라 라우팅된 엔드포인트에 같은 날 바로 반영됩니다.

설계 시 대비해야 할 실패 모드

Astra는 장문맥 설계를 기반으로 한 장기 지평 모델이며, 그 설명의 양쪽 절반 모두 문제가 도사리는 곳입니다. 이는 우리의 측정값이 아니라 커뮤니티의 발견과 벤더의 사후 분석입니다.

• 컨텍스트 관리 실험에 이번 주 버그가 있었다. OpenAI의 2026-09-12 포스트모템은 옵트인 실험이 "조기 중단과 오래된 메시지에 대한 답변을 초래했다"고 확인했으며, 약 4,000–5,000명의 사용자에게 영향을 주었고 비활성화되었다. 같은 포스트모템은 출시 주간 품질 불만의 다른 두 원인도 지목한다: 이전 모델용으로 작성된 스킬이 오작동해 Astra가 자체 작업을 점검하지 못하게 한 것, 그리고 잘못 구성된 서빙 엔진이 트래픽의 꼬리 부분을 저하시킨 것이다. 이어 09-12에서 09-13으로 넘어가는 자정에 사용량 재설정이 이루어졌다.

• 과잉 사고와 테스트 난립. 널리 공유된 r/codex 스레드에서는 Astra가 작은 기능 요청에 대응해 먼저 여러 계층의 검증, 스모크 테스트, 해시 검사를 구축하고 이를 여러 순서로 실행했으며, 해당 기능이 존재하기도 훨씬 전에 사용량 미터가 거의 소진되었다고 보고했다고 설명합니다. 이 보고들은 통제된 측정이 아니라 개별 사례의 진술이며, 한 달 전에는 다른 프런티어 모델들에 대해서도 비슷한 불만이 돌았습니다 — 그러니 이를 계획의 근거로 삼을 수 있는 비율이 아니라, 대비해 범위를 가늠해야 할 실제 패턴으로 취급하세요.

• 종료되지 않는 실행. Flask의 창시자인 아르민 로나허는 Astra를 감독 없이 35시간 동안 실행시켰다고 설명했는데, 그 끝에 79개의 커밋에 걸쳐 약 75,000줄의 순증 코드, 약 1,400개의 에이전트 간 메시지, 약 $1,200의 API 비용, 즉 커밋당 약 $15.50가 발생했지만, 그의 평가로는 가치 있는 결과물이 전혀 나오지 않았다. 토큰 수에 대한 보고는 다양하므로 그 수치는 대략적으로만 받아들여야 한다. 그는 빠진 정지 조건을 모델의 문제만큼이나 하네스의 문제로 규정했는데, 이것이 실행 가능한 해석이다: 시작하기 전에 완료를 정의하라.

• 반대되는 실패도 존재합니다. 커뮤니티 보고서에 따르면 Astra는 완료된 작업에 이르지 못한 채 멈추고 계속하라는 프롬프트를 기다린다고 합니다. 이는 동일한 근본 원인을 다른 쪽에서 본 것으로, '완료'에 대한 불충분하게 정의된 개념입니다. '완료'를 명시적으로 정의하는 것이 작업 프롬프트에서 가장 가치 있는 단 한 줄입니다.

• 긴 세션은 복구 불가능해질 수 있습니다. Open Co​dex 이슈는 컨텍스트 창이 가득 차고, 자동 압축이 트리거되며, 압축 작업 자체가 컨텍스트 부족에 빠지고, 스레드가 복구될 수 없는 catch-22를 보고합니다 — 그리고 별도로, 일부 구성에서 Pro with Astra의 네이티브 노트 및 히스토리 라우트가 404를 반환하고, 창을 전환하면 작업 상태가 폐기될 수 있다고 합니다. 둘 다 벤더의 성명이 아닌 공개 보고서이지만, 세션이 살아남을 것이라고 믿기보다는 git에 실행을 체크포인트로 유지할 것을 주장합니다.

• 오래된 노트는 버그가 아니라 설계상의 속성이다. 노트가 설명하는 파일의 현재 상태를 반영한다고 보장하는 것은 아무것도 없으며, 검색은 의미 기반이 아니라 문자 그대로의 부분 문자열 일치다. 노트와 함께 원본 경로를 저장하고, 변경 시 다시 검증하며, 무인 실행에서 나온 노트는 신뢰할 진실이 아니라 확인해야 할 증거로 취급하라.

• 현재 활발히 제기되는 불만은 사용량 한도다. 2026-09-14가 있는 주의 보고서에는 출시 주보다 최대 네 배 더 엄격한 한도와, xhigh effort가 medium보다 허용량을 덜 소모한다는 미해결 불만이 포함되어 있다 — 이것이 사실이라면 effort와 quota가 함께 움직이지 않는다는 뜻이다. Ope​nAI는 Astra의 플랜별 수치 한도를 공개하지 않았다.

더 저렴한 모델이 올바른 선택일 때

위의 측정 결과는 라우팅 결정을 대신 내려줍니다. Astra의 우위는 파일을 넘나들거나 몇 시간에 걸친 작업, 즉 파일 간 리뷰, 장기적인 에이전트 작업, 컴퓨터 사용 흐름에 집중되어 있습니다. 일반적인 단일 파일 편집, 기계적 리팩터링, 테스트 스캐폴딩 및 포매팅에서는 GPT-5.6 Sol 대비 약 4%의 전체 리뷰 차이가 현재 토큰당 가격의 약 2.5배를 정당화하지 못하며, CodeRabbit 자체의 결론도 같은 방향을 가리키면서 전면적 교체보다 지능형 작업 라우팅을 권장합니다. 값비싼 모델은 그 우위가 드러나는 작업에 남겨두고, 나머지는 하위로 라우팅하세요.

구체적으로, 실용적인 분담은 다음과 같습니다: GPT-6 Astra는 파일 간 변경, 익숙하지 않은 코드베이스, 여러 시간에 걸친 에이전트 실행, 브라우저를 건드리는 모든 작업에; GPT-5.6 Terra는 범위가 한정된 편집, 보일러플레이트, 테스트 생성에; GPT-5.6 Luna는 분류, 추출, 대량의 기계적 처리에. 위의 세션 계산에서, 모든 것을 Astra로 실행하는 것과 그중 3분의 1을 Astra로 실행하는 것의 차이는 동일한 150턴에 대해 대략 $58.50와 대략 $28의 차이입니다.

그 분배를 제대로 해내는 것이 바로 라우팅 레이어의 존재 이유입니다. OrcaRouter는 200개 이상의 모델을 하나의 API 뒤에 배치하므로, 위의 분배는 세 가지 통합이 아니라 설정 변경에 불과합니다. 또한 자동 장애 조치 덕분에, 실험적 기능이 이번처럼 한동안 문제를 일으키더라도 실행이 끝나는 대신 성능이 저하되는 정도로 그칩니다. OpenAI 스스로가 아직 실험적이라고 표시하고 잠시 비활성화하기까지 했던 컨텍스트 메커니즘을 가진 모델이라면, 두 번째 경로를 구성해 두는 것은 편집증이 아닙니다. 그것이 바로 적절한 수준의 신중함입니다.

앞으로 지켜봐야 할 것

이 페이지를 바꿀 네 가지가 있으며, 네 가지 모두 아직 결론이 나지 않았다. 컨텍스트 관리 실험이 다시 켜질지, 그리고 어떤 형태로 켜질지 — OpenAI는 이것이 Astra의 기본값이 될 것이라고 말하며, 이는 위의 설정 줄이 결국 사용자가 직접 설정하는 항목이 아니게 된다는 뜻이다. Pro에서 노트와 기록 관련 404 보고가 종료될지, 이는 해당 메커니즘이 문서에 나온 대로 작동하는지 일부 경로에서만 작동하는지를 가르는 차이이기 때문이다. OpenAI가 effort별 토큰 또는 비용 데이터를 공개할지, 이는 오늘날 모든 effort 결정에서 빠져 있는 수치다. 그리고 출시 주간에 걸쳐 강화된 사용량 한도가, 2026-09-10에 신규 $200 Pro 구독을 중단시킨 수요가 흡수된 뒤 완화될지.

그때까지는 플레이북은 짧습니다. codex -m gpt-6-astra로 모델을 고정하고, 클라이언트에 Plus, Pro 또는 Pro Lite 로그인이 있을 때만 실험을 켜고, 슬라이더 라벨을 믿기보다 effort를 명시적으로 설정하고, 청구 금액이 두 배가 되는 지점이므로 작업 컨텍스트를 272,000 토큰 미만으로 유지하고, 자리를 뜨기 전에 무엇이 완료인지 정의하고, 쉬운 작업은 더 저렴한 곳으로 돌리세요. 이 모델은 2026-09-03 버전이며 없어지지 않습니다. 아직 자리를 잡아가는 중인 것은 그 주변의 툴링입니다.

제기되는 질문들

창 간 메모 기능은 일반적인 규모의 작업에도 활성화할 가치가 있나요?일반적으로는 아닙니다. 이 기능은 컨텍스트 창 경계를 넘어서 생기는 손실을 해결하기 위해 존재하므로, 하나의 창에 들어가는 작업에서는 어떤 불편도 덜어주지 않으면서, 2026-09-12에 버그로 인해 비활성화된 실험적 코드 경로를 포함한 복잡한 요소만 늘립니다. 장기적인 작업에는 켜고, 범위가 한정된 편집에는 꺼두세요.

제 설정에서 1,050,000토큰 창이 검색을 대체할 수 있나요? 비용 측면에서는 아닙니다. 매 턴마다 큰 컨텍스트를 다시 읽는 데 매 턴마다 비용이 청구되며, 272,000 입력 토큰을 초과하면 전체 요청이 입력 $20.00, 출력 $75.00로 가격이 재산정됩니다. 작업 컨텍스트를 더 작게 유지하는 검색 단계가 보통 더 저렴한 설계입니다. 그래서 노트 메커니즘이 흥미롭습니다: 이는 하네스에 내장된 검색입니다.

작업이 끝나면 노트는 어떻게 되나요? OpenAI의 문서는 이 메커니즘을 동일한 작업 범위로 한정하고 있으며, 커뮤니티 글에서는 노트가 자동으로 다음으로 이어지는 것이 아니라 해당 작업에 저장되는 것으로 설명합니다. 새 작업이 이전 작업의 노트를 상속한다고 가정하지 마세요. 반드시 남아 있어야 하는 내용은 에이전트의 메모리가 아니라 여러분의 리포지토리에 두어야 합니다.