GPT-6 Sol High와 XHigh, 언제 추론을 더 늘려야 할까?

복잡한 코드 수정은 high부터 평가하고, 추가 추론의 이점이 확인되는 작업에만 xhigh를 적용하는 방법이 합리적입니다. 서로 다른 두 모델이 아니라 gpt-6-sol의 설정 두 가지를 비교하는 것입니다. 추론을 늘린다고 패치의 정확성이 보장되지는 않습니다.

공식 문서는 2026년 9월 25일 확인했습니다. 동일 작업을 두 설정으로 실행한 실측은 하지 않았습니다. 아래 내용은 설정, 가정한 비용 계산, 평가 절차이며 달러 가격은 OpenAI 직접 API 기준입니다. Ofox 가격이나 ChatGPT 구독 요금이 아닙니다.

XHigh로 바꾸면 무엇이 달라질까?

Sol 모델 문서는 none, low, medium, high, xhigh, max를 지원하며 기본값은 medium이라고 설명합니다. high도 기본값에서 변경한 설정입니다. 추론 가이드는 높은 설정의 이점을 지연과 비용에 비춰 평가하도록 안내합니다.

이는 평가 출발점이지 성능 순위가 아닙니다. 먼저 실패 테스트, 기대 동작, 관련 파일과 제약을 제공하세요. 요구가 빠진 상태에서 추론만 높이거나 무관한 파일을 오래 조사하게 하면 비용만 늘 수 있습니다.

비교 조건부터 고정하기

추론과 도구 호출을 함께 쓰는 에이전트는 Responses를 사용해야 합니다. Sol의 Chat Completions 함수 호출은 none만 지원합니다. 이 경로에서 high를 설정해 발생한 오류를 모델의 코딩 실패로 세면 안 됩니다. 도구 호출 이전 가이드를 먼저 확인하세요.

{"model":"gpt-6-sol","reasoning":{"effort":"high"},"input":"Review the supplied patch against the stated acceptance tests."}

실행하지 않은 요청 형식 예시이며 완성된 저장소 에이전트가 아닙니다. 비교 요청은 effort만 xhigh로 바꿉니다. 실제 평가는 commit, 프롬프트, 도구 정의, 권한, 출력 한도, 재시도 횟수도 고정합니다. reasoning.mode의 standard와 pro는 effort와 독립된 실행 모드이므로 함께 바꾸지 않습니다. 예시는 이를 생략해 기본 standard를 사용합니다.

각 실행은 같은 깨끗한 코드 상태에서 시작합니다. 두 번째 실행에 첫 번째 패치나 숨겨진 정답을 보여 주지 마세요. 여러 대표 작업에서 순서를 바꾸고 실패와 시간 초과를 남깁니다. 실패한 쪽만 추가로 실행하면 비교가 편향됩니다. 비밀 정보를 지운 실제 요청, 요청 ID, 제공자 사용량도 보관합니다.

단가가 같아도 청구액은 달라진다

Standard 처리에서 입력이 272K 토큰 이하면 Sol은 일반 입력 100만 토큰당 $2, 출력 $10입니다. API 요금표에 high/xhigh별 단가는 없지만, 추론이 과금 출력량을 늘리거나 도구 호출이 다음 요청의 입력을 늘릴 수 있습니다.

캐시 없는 입력 5만 토큰에 과금 출력 5천 토큰을 가정하면 $0.15, 출력이 1만5천이면 $0.25입니다. 선택한 가상 수량이며 high와 xhigh의 실제 사용량이 아닙니다. 보이는 답변 길이 대신 제공자의 usage를 확인해야 합니다.

캐시 읽기·쓰기, 도구, 처리 모드는 따로 계산합니다. 입력이 272K를 넘으면 요청 전체의 입력과 캐시 단가는 2배, 출력 단가는 1.5배입니다. 긴 입력 구간으로 넘어간 효과를 effort 변경 탓으로 돌리지 마세요. Sol 비용 설명에서 구분을 확인할 수 있습니다.

통과한 수정으로 판단하기

답변을 보기 전에 기준을 정합니다. 원래 문제가 해결되고 필요한 테스트가 통과하며 관련 없는 동작은 유지돼야 합니다. 검토자가 패치가 맞는 이유를 설명할 수 있어야 합니다. 수동 검토 시간은 별도로 남깁니다. 긴 설명이 검토 시간을 줄인다는 보장은 없습니다.

실패 시도까지 포함한 총 평가 비용을 통과 작업 수로 나눕니다. 통과가 0이면 이 비율은 정의되지 않습니다. 첫 토큰 시간뿐 아니라 통과한 패치를 얻을 때까지의 총시간도 비교합니다. 저렴한 실패를 저렴한 결과물로 세지 않습니다.

결과가 같고 high의 실제 비용이나 시간이 더 적다면 high를 유지하세요. xhigh가 반복적으로 통과 수를 늘릴 때 해당 작업에 선택적으로 적용합니다. 둘 다 실패하면 요구 정의와 파일 검색을 먼저 개선합니다. 모델 자체의 선택은 Sol·Luna·Astra 비교를 참고하세요. 프롬프트, commit, 테스트 명령과 실패 기록이 있어야 프로젝트가 바뀌었을 때 결론을 다시 검증할 수 있습니다.