Jev가 Opus에 도움을 청하는 하이브리드 판정으로 4배 저렴하게 Opus 정확도 확보

Sonnet이나 Haiku는 왜 안 봤을까. 꼭 Opus여야 하는지 궁금하네.

핵심은 Jev의 신뢰도 캘리브레이션이 좋다는 점임. 어차피 Jev보다 잘하는 모델이면 뭘 붙이든 크게 상관없을 듯.

나도 보안 엔지니어링에 같은 하이브리드 방식 씀. 툴 호출이랑 의도 판정하는 자체 하네스를 이 구조로 다시 만들었는데 초기 캘리브레이션만 지나면 잘 돌아감.

opencode-warden에 로컬 결정 모델 붙여서 툴 입출력 검증하게 해봤음. d1이 오래된 1080 GTX에서도 돌아가는데, 이거에 의존하라고 추천할 정도는 아닌 듯.

Qwen3.8 27B를 오케스트레이터로 두고 Claude한테 물어보게 하면 Haiku든 Opus든 비슷한 답이 나옴. 내 하네스에 orchestrate 툴 붙여서 3라운드 실험해봤는데 나쁘지 않았음.

그거랑 그냥 모델한테 알아서 빈칸 채우라고 하는 거랑 뭐가 다름? 중간 단계를 사람이 검토하지 않으면 '너를 이해한다'는 게 무슨 의미인지 모르겠음.

나는 반대로 씀. Qwen3.8-27B는 서브에이전트로, Opus 5.5는 오케스트레이터 겸 플래너로만 쓰고 구현은 절대 안 시킴. 토큰 사용량이 확 줄더라.

Anthropic에 /advisor 설정이 있음. Sonnet 쓰면서 Opus를 advisor로 지정하면 약한 모델이 필요하다고 판단할 때 자동으로 호출함.

작은 모델이 큰 모델 부르는 것과 큰 모델이 작은 모델 부리는 것 둘 다 해보는 중인데 문제 영역의 '취향'에 따라 답이 갈림. 토큰까지 아끼는 정답은 없더라.

gemma는 어떻게 생각함?

코드 예제가 있었으면 좋겠음. Jev랑 Luna를 실제로 어떻게 구현했는지 감이 안 잡힘.

이런 걸 보면 AGENTS.md 파일 대신 결정 모델이 컨텍스트를 관리하는 게 다음 단계 같음. 문제마다 컨텍스트를 자동으로 요약하고 큐레이션하는 식으로.

동적 컨텍스트 관리는 캐시 적중률을 박살낼 가능성이 큼. 접두사 매칭이 아닌 캐싱이 있어야 이게 말이 됨.

4배 낮다는 표현이 수학적으로 어색함. 그럼 -3배인가.

GPT-6 Luna는 결정 모델이 아니라 작은 LLM임.

decisions API가 있는 유일한 OpenAI 모델이라 그렇게 부르는 거고, 결정 모델 버전도 따로 있음. 이름 짓기가 계속 이상해지는 중.

이거 Anthropic이 준비 중이라는 그 멀티 모델 결합 방식 아님?

OpenAI랑 Anthropic 둘 다 라우팅 오래 해왔음. Grok도 내부적으로 Opus로 라우팅한다는 얘기가 있음.

이런 헤드라인에 이제 무감각해짐. 샌드박스 시나리오에서만 증명되고 실제 작업에서는 기대만큼 안 되는 경우가 많았음.

우리는 결정 모델 파인튜닝까지 해서 씀. 신뢰도 임계값을 10%까지 낮춰야 하지만 작업량이 70% 줄고 품질 손실은 0이었음.

이건 identity resolution이라는 특정 과제에 대한 벤치마크 결과임. 제목과 달리 일반 코딩 에이전트 개선을 주장하는 건 아님.

동의함. 다만 이런 패턴이 도움 되는 작업 종류는 꽤 많을 듯.