• Ploy는 프로덕션 마케팅 웹사이트를 계획·구축·검증하는 에이전트를 Claude Opus 4.8에서
  GPT-5.6 Sol로 전환하고 모든 워크스페이스의 기본 모델로 지정함 - 평가 하네스의 모델별 가정을 바로잡은 뒤 홈페이지 재구축 작업에서 평균 실행 시간이
  8분에서 3분 42초로 줄었고, 비용은 $3.06에서 $2.22로 27% 낮아졌으며 시각 점수도 0.970으로 높아짐 - GPT-5.6이 도구 호출의 선택적 매개변수 25개를 임의 값으로 모두 채우면서 파일 읽기의 52~64%가 빈 결과를 반환했으나, 선택 필드를
  필수·nullable로 바꾸자 빈 읽기가 0%로 줄고 도구 호출도 약 30% 감소함 - OpenAI와 Anthropic의 캐시 범위·처리량 구조 차이로 GPT-5.6이 처음에는 약 50% 비싸게 측정됐지만,
  워크스페이스 단위 캐시 키와 계층별 breakpoint를 적용해 첫 호출 적중률을 0%에서 83.7%로 높이고 미캐시 입력 토큰을 28% 줄임 - 모델 교체의 비용과 성능은 모델 자체뿐 아니라 평가 예산, 도구 스키마, 캐시 구조, 추론 재생 방식에 좌우되므로 기존 모델에 맞춰진
  프로바이더별 가정부터 찾아 수정해야 신뢰할 수 있는 비교와 안정적인 운영이 가능함

Claude Opus를 대체한 GPT-5.6 Sol

• Ploy 에이전트는 프로덕션 마케팅 웹사이트의 페이지를 계획하고 코드베이스를 읽으며, 컴포넌트와 이미지를 생성하고 결과를 스크린샷으로 확인한 뒤 작업 완료 여부를 판단함
• 여러 달 동안 Claude Opus를 대체할 기준을 충족한 모델이 없었고, 기본 모델은 4개월 동안 Opus 4.7과 4.8 순서로 유지됨
  GPT-5.6 Sol은 동일 작업을 대상으로 한 일대일 평가에서 처음으로 Opus를 앞서며 모든 Ploy 워크스페이스의 기본 모델이 됨- 초기 평가에서도 완료된 빌드의 실행 시간은 절반 미만이었고 비용은 27% 낮았으며, 기존 모델과 같거나 높은 점수를 기록해 마이그레이션을 진행할 근거가 됨
• Ploy는 Vercel AI SDK를 사용하지만, 모델 전환 과정에서 도구 인자 구성과 프롬프트 캐싱, 턴 간 추론 재생에 관한
  프로바이더별 가정이 스택 전반에 남아 있음을 발견함 - 마이그레이션은 평가 하네스, 도구 스키마, 프롬프트 캐싱, 추론 재생 순으로 수정하며 진행됨

평가 수치를 믿기 전에 하네스부터 수정

• 평가 제품군은 프로덕션 에이전트를 고정 테스트 워크스페이스에서 실행하며, 홈페이지를 처음부터 구축하는 작업부터 복제 요청을 안전하게 실행할 수 있는지 판단하는 작업까지 수백 개 사례를 다룸

• 빌드 사례에서는 시각 판정기가 기준 디자인과 비교해 10개의 이진 검사를 수행함

• hero 영역이 화면 전체 폭을 채우는 사진 장면인지 검사함

• 주요 CTA가 pill 형태가 아닌 둥근 모서리의 직사각형인지 확인함

• 콘텐츠 검사와 도구 실행 경로 검사, 파일 단언도 함께 수행하며, 실패 시 도구 호출과 모델 텍스트를 포함한
  전체 실행 추적을 검토함 -

기존 모델의 호출 방식에 맞춰진 제약

• 기존 도구 호출 예산은 Opus의 순차 호출 방식에 맞춰져 있었지만, GPT-5.6은 병렬 호출을 사용해 올바르게 문제를 해결한 사례에서도 예산을 초과함

• 평가 실행기는 Opus가 거의 사용하지 않던
  일괄 파일 읽기를 지원하지 않았지만 GPT-5.6은 이를 자주 사용함 - 첫 실행에서 발생한 원시 실패의 약 3분의 1은 모델 동작이 아닌 하네스의 가정에서 비롯됐으며, 모델별로 고르게 분포하지도 않았음

• 도전 모델과 기존 모델의 실행 추적을 먼저 분류하지 않으면 새 모델이 기존 모델처럼 행동할수록 유리한 평가가 됨

암묵적인 점수 임계값

minScore

가 빠진 데이터셋은 아무 경고 없이 기본값 1.0을 물려받음- 이 때문에 GPT-5.6은 hero 점수 0.98을 받고도 실패 처리됐고, Opus 역시 모든 개별 검사를 통과한 사례에서 실패로 판정됨

• 두 결과 모두 방어 가능한 디자인이었지만 모델이 아닌
  암묵적 임계값때문에 탈락함

수정된 벤치마크 결과

• 하네스를 고친 뒤 브랜드 홈페이지를 기준 디자인에 맞춰 다시 구축하는 평가 제품군을 재실행함

| 완료된 빌드당 평균 | Claude Opus 4.8 (n=11 ) |
GPT-5.6 (n=10 ) |
|---|---|---|
| 비용 | $3.06 | $2.22 |
| 실행 시간 | 8분 00초 | 3분 42초 |
| 입력 토큰 | 260만 | 170만 |
| 출력 토큰 | 33,000 | 17,100 |
| 시각 점수 | 0.936 | 0.970 |

• GPT-5.6은 페이지를
  2.2배 빠르게완성했고 비용은 27% 낮았으며, 출력 토큰도 약 절반만 사용함 - 생성한 코드의 양도 더 적었음
• 한 쌍의 비교 사례에서 Opus는 대부분 사용되지 않는 색상 계열을 포함해 CSS 변수 174개와 17,957자의
  globals.css

를 생성함 - GPT-5.6은 CSS 변수 45개와 2,508자를 사용하면서도 비슷하거나 더 나은 렌더링 결과를 냄

• 한 쌍의 비교 사례에서 Opus는 대부분 사용되지 않는 색상 계열을 포함해 CSS 변수 174개와 17,957자의

디자인 품질과 일관성

• GPT-5.6은 깔끔하고 격자가 촘촘한 레이아웃에 강하지만, 강하게 유도하지 않으면 해당 스타일로 수렴하는 경향이 있음
• Opus 4.8용으로 설계된 기존 하네스에서는 기존 디자인 시스템을 무시한 채
  깔끔하지만 평범한 결과물을 자주 생성함 - 디자인팀과 엔지니어링팀이 모델 유도 방식을 개선한 뒤에는 프로덕션에 필요한 브랜드 준수 기준을 충족함

도구 호출의 선택적 매개변수 처리

• 에이전트의
  code

도구에는 최상위 매개변수 25개가 있으며,action

만 필수이고 나머지는 선택 사항임 - Claude는 사용하는 매개변수 2~3개만 전송하지만 GPT-5.6은 호출마다 25개를 모두 보내며, 사용하지 않는 필드도
offset: 0

,timeout: 120000

,siteId: "00000000-0000-0000-0000-000000000000"

같은 그럴듯한 값으로 채움 - 3일간 수집한 프로덕션
code(read)

실행 추적에서도 같은 패턴이 나타남

모델	호출 수	25개 속성을 모두 포함한 호출
gpt-5.6
6,635	6,635건, 100%
claude-opus-4.8
2,898	4건, 0.1%
claude-sonnet-5
1,933	0건

빈 파일 읽기가 발생한 원인

• 문제는 단순히 인자가 장황하다는 데 있지 않고, 파일 읽기 구현이 모델이 임의로 만든 값과 사용자가 의도한 값을 구별할 수 없다는 데 있었음
• 구현은
  offset: 0

을 실제 인자로 처리했고, GPT-5.6 파일 읽기의52~64%가 빈 결과를 반환함 - 도구가 유효한 읽기와 빈 읽기 모두에
success: true

를 반환해 모델은 빈 파일을 읽고 있다는 사실을 알 수 없었음 - 빈 결과를 보완하려고 호출을 더 많이 수행하면서 결과 품질까지 나빠짐

프롬프트와 strict 모드로 해결되지 않은 문제

• 도구 설명에 사용하지 않는 매개변수를 생략하라는 지시를 넣어도 25개가 모두 생성됨
• 각 속성에
  OPTIONAL, omit if unused

를 붙여도 동작은 달라지지 않음 - OpenAI의
strict

모드에서도 같은 결과가 나왔으며, 이를 도입하려면 모든 스키마에서pattern

,format

, 배열 크기 검증을 제거해야 했음 - 이 동작은 모델이 함수 호출을 생성하는 방식에서 나오므로 프롬프트 대신 스키마를 변경함

프로바이더 경계의 스키마 변환

• OpenAI 계열 모델에는 모든 선택 속성을
  anyOf: [T, null]

형태의필수·nullable 속성으로 다시 작성함 - 모델은 사용하지 않는 매개변수를 명시적인
null

로 채우고, 공유 도구 호출 경계에서 검증하기 전에null

을 제거함 - 도구 구현은 바꾸지 않고 모델용 스키마에서만 사용하지 않는 값을 표현할 수 있도록 함

// 변경 전: 25개 키가 모두 임의 값으로 채워짐 { "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 } // 변경 후: 실제 값 4개와 null 21개를 보내고, 도구 실행 전에 null을 제거함 { "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }

• 변경 후 빈 파일 읽기는
  **52%에서 0%**로 떨어짐 - 같은 작업에 필요한 도구 호출 수도 약 30% 줄어 빈 결과를 반복해서 읽는 동작이 사라짐

• OpenAI 계열 모델에는 모든 선택 속성을

OpenAI 방식에 맞춘 프롬프트 캐싱

• 두 프로바이더 모두 프롬프트 캐싱을 제공하지만 구현 방식은 서로 다름
• 이 차이를 반영하기 전에는 GPT-5.6이 Opus보다 약 50% 비싸게 보였지만, 원인은 모델 가격이 아닌
  캐시 구성이었음 -

Anthropic의 조직 단위 캐시

• 에이전트 프롬프트는 도구 스키마와 핵심 시스템 프롬프트로 구성된 약
  29,000토큰의 정적 접두부로 시작하며 모든 대화에서 동일함 - Claude에서는
  cache_control

로 캐시 breakpoint를 표시하고 접두부를 조직 전체에서 공유함 - 어떤 워크스페이스의 대화든 하나의 공유 항목을 사용할 수 있고, 키별 처리량 제한도 없음

• 캐시 적중률은 92~96%임

• 에이전트 프롬프트는 도구 스키마와 핵심 시스템 프롬프트로 구성된 약

GPT-5.6에서 달라진 캐시 동작

• 이전 GPT 모델은 암묵적으로 부분 접두부 일치를 캐시했지만, GPT-5.6은 부분 접두부 일치를 제거함

• 암묵적 캐시는 최신 메시지를 기준으로 전체 프롬프트 항목을 만들기 때문에, 동일한 29,000토큰 정적 접두부를 공유하는 새 대화도 첫 호출에서는 캐시 적중률이 0%임

• 이에 따라 대화마다 접두부 전체가 미캐시 요금으로 다시 청구됨

• 애플리케이션의 캐시 사용 여부와 관계없이 GPT-5.6은 모든 미캐시 프롬프트에
  1.25배 캐시 쓰기 할증을 적용함

명시적 캐시 키의 제약

• 명시적 캐싱에는
  prompt_cache_breakpoint

와 필수prompt_cache_key

가 필요함 - 키도 캐시 정체성에 포함되므로 동일한 프롬프트라도 키가 다르면 적중하지 않음

• 각 키는 분당 약 15개 요청을 처리하는 캐시 노드에 매핑되며, 이를 넘으면 OpenAI가 독립적인 콜드 캐시를 가진 다른 노드로 트래픽을 분산함

• 따라서 어떤 단위로 키를 지정할지가 핵심 설계 결정이 됨
  **대화별 키:새 대화가 공유 접두부를 적중하지 못해 첫 호출 적중률이 0%였음전역 키 하나:모든 요청이 한 노드로 해시되며, 프로덕션 트래픽이 15 rpm을 넘으면 콜드 노드로 넘침워크스페이스별 키:**고객 워크스페이스의 모든 대화가 항목을 공유하면서도 키별 트래픽은 낮게 유지됨

• 명시적 캐싱에는

워크스페이스 단위 계층형 캐시

• 실제 구성은
  ws:{workspaceId}

형태의워크스페이스 단위 키를 사용하고 시스템 프롬프트를 breakpoint 계층으로 나눔 - 항목 A는 도구와 정적 접두부를 담아 세션의 첫 호출 비용을 줄임

• 항목 B는 정적 접두부에 워크스페이스 컨텍스트를 더함

• 항목 C는 첫 턴부터 최신 메시지까지 이어지는 세션별 전체 프롬프트 체인임

• 워크스페이스 메모리가 바뀌면 항목 B는 빗나가지만 항목 A는 계속 적중해, 29,000토큰 전체가 아닌 변경된 컨텍스트 크기만 새로 씀

• 항목 C는 프롬프트가 엄격한 추가 전용 구조이므로 세션 안에서 OpenAI의 암묵적 전체 프롬프트 체인을 활용함

• OpenAI의 키 파티셔닝 때문에 정적 접두부를 워크스페이스 사이에서 공유할 수 없음

• 반면 Anthropic은 키 파티셔닝 없는 조직 단위 캐시를 사용해 접두부 공유가 가능함

• GPT-5.6에서는 각 워크스페이스가 유휴 시간 구간마다 29,000토큰을 한 번 콜드 쓰기하며, 비용은 약
  $0.18임 - 이 비용은 범위가 제한돼 있고 예측 가능함

• 실제 구성은

캐시 수정 결과

• 첫 호출 캐시 적중률은 약 0%에서
  **83.7%**로 상승함 - 전체 미캐시 입력 토큰은 28% 감소함

• GPT-5.6의 평가 제품군당 비용은 Opus보다 낮아졌으며, 초기 비용 격차 전체가 잘못된 캐시 구성에서 발생함

• 한 모델만 콜드 캐시로 시작한 상태에서 수행한 모델 간 비용 비교는 유효하지 않음

• 첫 호출 캐시 적중률은 약 0%에서

추론 재생을 자체 완결형으로 변경

• GPT-5.6 Responses API는 기본적으로 이전 턴의 추론을 서버 측 항목 참조로 재생하며, 프로덕션 대화에서 간헐적으로
  Item 'rs_...' not found

오류가 발생함 store: false

를 설정하면 SDK가 암호화된 추론 콘텐츠를 요청하고, 서버 상태를 가리키는 포인터 대신자체 완결형 blob을 재생함- 애플리케이션이 보내는 바이트가 추가 전용 구조여도 서버 측 추론 상태가 유효 프롬프트를 바꿀 수 있음

• 평가 하네스와 도구 스키마, 프롬프트 캐시, 추론 재생을 모두 수정한 GPT-5.6 Sol은 Ploy의 프로덕션 기본 모델로 운영 중임