Ploy는 실제 마케팅 웹사이트를 구축하는 프로덕션 AI 에이전트를 Claude Opus에서 GPT-5.6으로 전환했습니다. 그 결과 작업 완료 시간은 2.2배 단축되고 비용은 27% 절감되었습니다. 이 과정에서 기존 평가 시스템이 특정 모델에 맞춰져 있었다는 사실을 발견하고, 새 모델의 병렬 처리 방식에 맞게 시스템 전면을 수정했습니다.
번역된 본문
오늘부터 Ploy의 에이전트는 오늘 아침 오픈AI가 출시한 모델 패밀리의 플래십 티어인 GPT-5.6 Sol에서 실행됩니다. 수개월 동안 당사의 매우 높은 품질 기준을 고려할 때 Claude Opus와 경쟁할 수 있는 모델을 찾지 못했습니다. GPT 5.6 Sol이 나오면서 상황이 바뀌었습니다. Claude Opus와 직접 비교 테스트를 실행한 후, GPT 5.6 Sol을 모든 Ploy 워크스페이스를 구동하는 기본 모델로 설정했습니다. 이는 생각보다 큰 전환입니다. Ploy의 에이전트는 실제 마케팅 웹사이트를 구축하고 편집합니다. 페이지를 계획하고, 코드베이스를 읽고, 컴포넌트를 작성하고, 이미지를 생성하고, 자신의 작업을 스크린샷으로 찍고, 완료 시점을 결정합니다. 이 직무는 모델에게 매우 높은 기준을 요구하며, 우리는 모든 프론티어 릴리스를 이 기준으로 테스트합니다. Opus가 기본 모델이었던 4개월 동안 (처음에는 Opus 4.7, 그 다음은 4.8), 우리가 테스트한 어떤 것도 이것을 능가하지 못했습니다. GPT-5.6은 이를 달성한 첫 모델입니다. 첫 평가 실행이 완벽했다는 것은 아닙니다. 실제 실패 사례가 있었으며, 이는 보여드릴 것입니다. 하지만 매우 잘 수행되었고, 그 가능성은 즉각적이고 구체적이었습니다: 완료된 작업에 대한 점수가 기존 모델과 같거나 그 이상이면서, 빌드가 실제 시간의 절반 이하로 완료되고 비용은 27% 더 저렴했습니다. 이러한 수치는 모델에게 실제 마이그레이션 노력을 기울일 만한 가치를 줍니다. Vercel의 AI SDK, 범용 LLM SDK를 사용함에도 불구하고 Claude Opus 4.8에서 GPT 5.6 Sol로 전환하려면, 평가 실패를 하나씩 발견하면서 우리가 "모델"이라고 생각했던 것이 우리 전체 스택이 조용히 특화되어 있던 제공자별 행동이라는 것을 알아차려야 했습니다: 도구 인수를 채우는 방법, 프롬프트 캐시 작동 방식, 턴 사이에 자체 추론을 재생하는 방법 등입니다. 여기 필요한 것들이 있습니다: 평가 하네스, 도구 스키마, 캐싱, 추론 재생을 차례로 수정합니다.
단계 0: 단 하나의 숫자를 신뢰하기 전에 하네스를 수정하세요
우리의 평가 제품군은 실제 에이전트를 실제 테스트용 워크스페이스에서 실행합니다. "처음부터 홈페이지 구축"부터 "이 복제 요청이 실행에 안전한가"까지 수백 건의 사례가 있습니다. 빌드 사례는 참조 디자인에 대해 바이너리 검사를 실행하는 비주얼 심사관에 의해 점수가 매겨지며, "히어로는 전체 폭 사진 장면입니다" 또는 "기본 CTA는 알약 모양이 아닌 둥근 사각형입니다"와 같은 10개의 예/아니오 질문과 콘텐츠 검사, 도구 궤적 검사, 파일 어설션이 있습니다. 모든 실패 사례는 점수가 아닌 실제 도구 호출과 모델 텍스트인 전체 추적에 대해 분류됩니다. 두 모델 패밀리에 걸쳐 이 제품군을 실행한 것은 개별 결과보다 우리를 더 놀라게 했습니다: 당신의 하네스는 기존 모델에 맞춰져 있으며, 당신은 그것을 모릅니다. 우리의 도구 호출 예산은 Opus의 순차적 스타일에 맞게 크기가 조정되었습니다; GPT-5.6은 병렬 호출을 펼치고 올바르게 해결하는 사례에서 예산을 초과했습니다. 우리의 평가 실행기는 Opus가 거의 사용하지 않고 GPT-5.6이 지속적으로 사용하는 배치 파일 읽기를 지원하지 않았습니다. 첫 모델 간 실행에서 원시 실패의 약 1/3은 모델 동작이 아닌 하네스 가정으로 거슬러 올라갔으며, 이는 모델 간에 균등하게 분포되지 않았습니다. 기존 모델에 대해 도전자 모델을 평가하는 경우, 합격률을 신뢰하기 전에 추적을 분류하세요. 그렇지 않으면 새 모델이 이전 모델을 얼마나 잘 모방하는지에 따라 점수를 매기게 됩니다. 평가에서 모델을 공정하게 채점하는지 확인하세요. minScore 임계값을 생략한 데이터 세트는 조용히 1.0의 기본값을 상속했으므로, GPT-5.6은 0.98점을 받은 히어로에서 "실패"했고, Opus는 모든 개별 검사를 통과하면서도 사례에서 "실패"했습니다. 방어 가능한 두 가지 설계 방향; 하나의 보이지 않는 임계값.
첫인상: 즉각적인 유망함
하네스를 정리한 후, 에이전트가 참조 디자인에 대해 브랜드의 홈페이지를 재구축하는 재디자인 제품군의 샘플이 있습니다:
완료된 빌드당 평균 (Mean per completed build)
Claude Opus 4.8 (n=11) | GPT-5.6 (n=10)
비용 (Cost): $3.06 | $2.22
실제 시간 (Wall-clock time): 8m 00s | 3m 42s
입력 토큰 (Input tokens): 2.60M | 1.70M
출력 토큰 (Output tokens): 33.0K | 17.1K
시각적 점수 (Visual score): 0.936 | 0.970
이것이 약속의 형태입니다: 완성된 페이지까지 2.2배 더 빠르고, 27% 더 저렴하며, 출력 토큰은 약 절반입니다. GPT-5.6은 간결한 코드를 작성합니다. 한 쌍을 비교해보면, Opus는 174개의 CSS 변수가 있는 17,957자의 globals.css를 생성했습니다 (대부분 사용 불가능한 전체 색상 램프).
As of today, Ploy’s agent runs on GPT-5.6 Sol, the flagship tier of the model family OpenAI released this morning. For months, we couldn’t find a model that challenges Claude Opus given our incredibly high bar for quality. That changed with GPT 5.6 Sol. After running it head-to-head against Claude Opus, we’ve made GPT 5.6 Sol the default model powering every Ploy workspace. That’s a bigger switch than it sounds. Ploy’s agent builds and edits real marketing websites. It plans a page, reads the codebase, writes components, generates imagery, screenshots its own work, and decides when it’s done. That job description sets a very high bar for a model, and we test every frontier release against it. For the four months Opus held the default slot (first Opus 4.7, then 4.8), nothing we tested beat it. GPT-5.6 is the first model that did. Not that the first eval run was perfect. It had real failure modes, which we’ll show you. But it did extremely well, and the promise was immediate and specific: builds finishing in less than half the wall-clock time, at 27% lower cost, scoring at or above our incumbent on completed work. Numbers like that buy a model a real migration effort. Despite using Vercel’s AI SDK , a universal LLM SDK, switching from Claude Opus 4.8 to GPT 5.6 Sol required discovering, one eval failure at a time, that the things we think of as “the model” are provider-specific behaviors our whole stack has quietly specialized around: how it fills in tool arguments, how its prompt cache works, how it replays its own reasoning between turns. Here’s what it took: fix the eval harness, then the tool schemas, then caching, then reasoning replay. Step 0: Fix your harness before you trust a single number Our eval suite runs the real agent against real fixture workspaces. Hundreds of cases, from “build a homepage from scratch” to “is this clone request safe to execute.” Build cases are scored by a visual judge running binary checks against a reference design, ten yes/no questions like “the hero is a full-bleed photographic scene” or “primary CTAs are rounded rectangles, not pills” , plus content checks, tool-trajectory checks, and file assertions. Every failed case gets triaged against its full trace: the actual tool calls and model text, not just the score. Running that suite across two model families surprised us more than any individual result: Your harness is tuned to your incumbent model, and you don’t know it. Our tool-call budgets were sized for Opus’s sequential style; GPT-5.6 fans out parallel calls and blew through them on cases it was solving correctly. Our eval executor didn’t support batched file reads, which Opus rarely used and GPT-5.6 uses constantly. Roughly a third of the raw failures in the first cross-model run traced back to harness assumptions, not model behavior, and they were not evenly distributed between the models. If you’re evaluating a challenger model against an incumbent, triage the traces before you trust the pass rate . Otherwise you’re grading the new model on how well it imitates the old one. Make sure you’re grading models fairly in evals. A dataset that omitted its minScore threshold silently inherited a default of 1.0, so GPT-5.6 “failed” a hero it scored 0.98 on, and Opus “failed” a case while passing every individual check. Two defensible design directions; one invisible threshold. First impression: immediately promising With the harness cleaned up, here’s a sample from our redesign suite, where the agent rebuilds a brand’s homepage against a reference design: Mean per completed build Claude Opus 4.8 (n=11) GPT-5.6 (n=10) Cost $3.06 $2.22 Wall-clock time 8m 00s 3m 42s Input tokens 2.60M 1.70M Output tokens 33.0K 17.1K Visual score 0.936 0.970 This is the shape of the promise: 2.2× faster to a finished page, 27% cheaper, and about half the output tokens. GPT-5.6 writes lean code. On one matched pair, Opus produced a 17,957-character globals.css with 174 CSS variables (full color ramps, mostly unused) where GPT-5.6 wrote 2,508 characters and 45 variables for a comparable (and sometimes better) rendered page. Claude Opus 4.8 GPT-5.6 Sol Design: sharp, clean, but a little bit uniform Our overall read on GPT-5.6’s design work: it is very good at clean, modern, tightly-gridded layouts, but it tends to converge towards that look unless you steer it well. With our older harness designed for Opus 4.8, GPT 5.6 Sol tends to ignore existing design systems and instead produces sharp, restrained, and visibly generic output. The details of how we fixed this are worth a separate blog post of its own. With the expertise of our design and engineering teams, we are able to steer models to achieve world-class brand adherence that you can’t get out of the box. Step 1: Check your tool calls Here’s the one that was silently corrupting results before we caught it. Our agent’s code tool has 25 top-level parameters, one required ( action ) and the rest optional. Claude sends the two or three it’s using and omits the rest. GPT-5.6 sends all 25, every time , inventing plausible values for the ones it doesn’t need: offset: 0 , timeout: 120000 , siteId: "00000000-0000-0000-0000-000000000000" . Three days of production traces, code(read) calls carrying every property: Model Calls Carrying all 25 properties gpt-5.6 6,635 6,635 (100%) claude-opus-4.8 2,898 4 (0.1%) claude-sonnet-5 1,933 0 The problem isn’t verbosity. It’s that an invented value is indistinguishable from an intended one . offset: 0 looks like a real argument. Our file-read implementation treated it as one, and 52% to 64% of GPT-5.6’s file reads were coming back empty because of it. The tool returned success: true both ways, so the model had no way to know it was reading blank files. It just did the work worse, with more calls. Prompting doesn’t fix this. A tool-description directive to “omit unused parameters”: still 25/25. Per-property “OPTIONAL, omit if unused” hints: still 25/25. OpenAI’s strict mode: identical behavior (we measured), and adopting it would have forced us to strip pattern , format , and array-bound validation from every schema. This is baked into how the model emits function calls . You don’t instruct it away; you design around it. The fix that worked is a schema transform at the provider boundary. For OpenAI-family models only, we rewrite every optional property to be required but nullable , using anyOf: [T, null] , which gives the model an explicit way to say “not using this.” Then, at the single seam every tool invocation passes through, we strip the nulls back out before validation, so no tool implementation changes at all. Round trip: the model sees a schema where honesty is expressible; the tools see the same inputs they always did. // Before: 25 keys, every one carrying an invented value { "action" : "read" , "file_paths" : [ ... ], "offset" : 0 , "timeout" : 120000 , ... } // After: 25 keys, 4 real values, 21 explicit nulls (stripped before the tool runs) { "action" : "read" , "file_paths" : [ ... ], "offset" : null , "timeout" : null , ... } Results: empty file reads went from 52% to 0%, and the agent needed roughly 30% fewer tool calls for the same work, because it was no longer re-reading files that came back blank. Step 2: Rebuild prompt caching This was the most instructive engineering difference, because on the surface both providers offer “prompt caching” and the words hide two entirely different designs. If you migrate one thing carefully, make it this: before we did, GPT-5.6 looked about 50% more expensive than Opus. It wasn’t the model’s pricing; it was our cache configuration. Our agent’s prompt opens with a static prefix of roughly 29K tokens (tool schemas plus the core system prompt) that’s identical for every conversation. On Claude, we mark cache breakpoints with cache_control and that prefix caches across the whole organization : any conversation, any workspace, one shared entry, no throughput budget to think about. Cache hit rates run 92% to