GPT-6.1 Sol은 저렴함. 코드를 절대 직접 짜지 못하게 해서 77% 더 싸게 만듦

사소한 수정은 그냥 속도 제한을 걸어버려. 예를 들어 1분당 3회 정도로 제한하는 식으로.

변경 유형이 글자 수보다 낫지, <가 뒤집히면 한 글자라도 모든 게 바뀌니까.

체크 기준에 대해 말하자면: 세 경로 모두 같은 프롬프트를 썼지만 공유된 테스트 스위트는 없었음. 게임을 직접 실행해서 판단했으니 여기서 '완료'는 'N개의 체크 통과'가 아니라 '플레이 가능'을 의미함. 그게 이 비교의 약점인데, 제대로 하려면 경로마다 동일한 완료 체크 기준이 필요함.

재밌겠네, 한번 해봐야겠다

에이전트에게 위임할 때, 그 위임이 코드로 정의된 거야, 아니면 스킬 내에서 이루어지는 거야, 아니면 다른 방식임?

Swift 1.5 Qwen3.8 NVFP4 쓰고 있음? 아니면 시간 엄청 잡아먹을 텐데.

오케스트레이션에 뭘 쓰고 있는 거야?

난 오케스트레이터가 아무것도 안 하게 두는 걸 선호해. 그냥 오케스트레이션이랑 검토만 하고, 코드 수정은 서브 에이전트들이 알아서 하게 하는 거지. 이렇게 생각해 봐. 오케스트레이터가 더 똑똑하면 서브 에이전트들이 제대로 일하게 가이드할 수 있잖아. 오케스트레이터가 잘 만든 브리핑 덕분에 그 지능의 일부가 서브 에이전트들한테 전달되는 셈이지. 그리고 Qwen 3.8 27B가 Sonnet 4.5보다 더 똑똑한 LLM이라는 점도 고려해야 해. Sonnet도 이미 코딩을 마스터했었으니까, 결국 플래시 LLM 모델들도 충분히 능력이 있다는 거지. 좋은 가이드만 있으면 뭐든 코딩할 수 있어.

반대로 해야지. 오케스트레이터/플래너는 똑똑하되 장황함을 제한하고, 느리지만 추론 능력이 뛰어난 워커/코더를 두고, 범용 작업용 소형 워커를 따로 두는 거야. 나라면 Sol을 느린 워커/코더로 쓸 것 같아.

쓰기 권한을 아예 막아서 77% 비용 절감하는 건, 복잡한 작업이라면 느려져도 충분히 가치 있지. 나라면 오케스트레이터가 20자 미만 정도만 수정하게 하고, 그보다 큰 건 워커한테 넘기거나 아니면 그냥 조용히 다시 코딩하게 할 것 같아.