확인된 해결 범위는 Windows VS Code 확장뿐이야

Sol이 전체 작업을 나누는 부모라면 Luna는 그중 한 조각을 처리하는 하위 작업용 모델이야. 릴리스 노트의 leaf model은 멀티에이전트 v2에서 이런 자식 역할로 붙는 모델을 뜻하고, spawn_agent는 Sol이 Luna를 띄울 때 쓰는 기능이야.

Windows VS Code 확장은 번들 Codex가 0.148.0-alpha.9로 올라간 뒤 이 spawn_agent 거부가 풀렸어. 이 환경이면 지금 시험해볼 수 있지만, macOS나 Codex Desktop이면 아직 보류해야 해.

0.147.0 릴리스 노트에 Support leaf models in multi-agent v2 한 줄이 들어갔어. 8월 7일 자야. 다만 실제 동작은 앱에 묶인 Codex 런타임 버전에 달려 있어. 같은 0.147.0 이름을 봐도 바로 된다고 판단하면 안 돼.

8월 4일까지는 막혀 있었어

그 전엔 Unknown model gpt-5.6-luna for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra 에러가 났어.

원인은 모델 카탈로그 표기야. Luna는 멀티에이전트 v1으로 등록돼 있었고, v2 세션의 spawn_agent는 v2로 등록된 모델만 받았거든. 7월 24일 올라온 이슈가 그 얘기야.

8월 4일 커뮤니티에는 이게 의도된 제한이라는 답이 달렸어. 답변 작성자는 에이전트끼리 주고받는 작업의 성능을 이유로 들었지만, OpenAI의 공식 원인 설명으로 확인된 내용은 아니야.

이름이 같아도 빌드가 다르면 갈려

같은 0.147.0인데 결과가 달랐던 구간이 있어. 정식 CLI 0.147.0은 되는데, VS Code 확장에 묶인 0.147.0-alpha.6.5는 같은 에러로 거부했거든.

이유가 커밋 단위로 정리돼 있어. leaf 기능을 넣은 커밋 6d4d9442가 그 알파 빌드에는 안 들어가 있었어. 확장 밖에서 그 바이너리를 직접 실행해도 결과가 같았고.

Windows VS Code 확장이 0.148.0-alpha.9를 묶은 26.810.41047로 올라가면서 풀렸어. 8월 14일에 그 이슈도 닫혔어. 이 결과를 macOS나 Codex Desktop까지 넓혀 말할 근거는 없어.

구성을 바꾸기 전에 확인할 것

  • 버전 이름 말고 번들 런타임: 0.147.0이라는 이름이 두 빌드에 다 붙어 있었어. 확장이나 데스크톱을 쓴다면 그 안에 묶인 Codex 런타임 버전을 봐야 해.
  • 해결이 확인된 범위는 Windows 확장까지: macOS와 Codex Desktop에서 나온 신고는 별도 이슈로 아직 열려 있어. 막혀 있으면 서브에이전트 대신 codex exec로 Luna를 띄우는 우회가 쓰였어.
  • Luna는 말단까지: 서브에이전트로는 서지만 다른 에이전트와 주고받는 역할은 아직 아니야. 오케스트레이터 자리는 그대로 Sol이 맡아야 해.
  • 크레딧 사용량은 직접 재기: Luna에 넘겼을 때 사용량이 얼마나 달라지는지는 공개된 수치가 없어. 팀 작업 며칠치로 재보고 정해도 늦지 않아.

Windows VS Code 확장에서 번들 런타임이 0.148.0-alpha.9 이상이고, Sol이 나눈 독립 작업을 Luna에 맡기려는 팀이면 지금 시험해볼 수 있어. macOS·Codex Desktop을 쓰거나 에이전트끼리 계속 대화해야 하는 작업이라면 관련 이슈가 닫힐 때까지 미루는 편이 낫겠어.