Claude Code가 Opus 4.7에서 top_p deprecated를 보여줄 때 가장 먼저 해야 할 일은 provider를 바꾸는 것도, Claude Code 자체가 망가졌다고 단정하는 것도 아닙니다. 실제로 바뀐 것은 Opus 4.7의 request contract입니다. Anthropic은 이제 비기본값 top_p, temperature, top_k를 포함한 request를 400으로 거절합니다. 그래서 실제 질문은 "Claude Code가 왜 고장 났지?"가 아니라 "어느 layer가 아직도 예전 sampling params를 보내고 있지?"입니다.
가장 빠르고 안전한 순서는 route-first입니다. 먼저 Claude Code 버전을 확인하고, 다음으로 backend route를 확인한 뒤, wrapper, plugin, proxy, config 중 어느 layer가 오래된 fields를 계속 주입하는지 봅니다. 그다음에야 같은 path에서 같은 task를 다시 실행하세요. version, route, cleanup을 다 확인했는데도 stack이 그 fields를 멈출 수 없을 때만 temporary fallback이 합리적입니다.
여기서 먼저 고정해야 할 current fact가 하나 있습니다. 2026년 4월 17일 기준으로 다시 확인한 Claude Code docs는 Opus 4.7에 Claude Code v2.1.111+가 필요하다고 말합니다. 동시에 opus alias는 모든 backend에서 같은 의미가 아닙니다. Anthropic API에서는 opus가 Opus 4.7이지만, Bedrock, Vertex, Foundry에서는 4.7을 명시적으로 pin하지 않으면 여전히 Opus 4.6일 수 있습니다.
이런 종류의 error에서 시간을 잃는 가장 흔한 이유는 답이 없어서가 아니라, 처음부터 잘못된 가지로 들어가기 때문입니다. 아래 route board는 그 분기 판단을 최소 비용으로 끝내기 위한 것입니다.
먼저 분기를 고르세요: 지금 어디에서 막혔나요?
top_p deprecated는 하나의 error처럼 보이지만 실제로는 어느 분기에 있는지 먼저 가려야 하는 문제입니다. 먼저 대답해야 할 질문은 "Opus 4.7의 모든 변경점이 무엇인가"가 아니라 "지금 version 문제인지, route 문제인지, outer cleanup 문제인지"입니다.
| 지금 보이는 상황 | 먼저 의심할 owner | 가장 안전한 첫 조치 | 같은 path에서 확인할 것 | 언제 fallback을 고려할지 |
|---|---|---|---|---|
Claude Code가 v2.1.111보다 오래됐거나 로컬 path가 오래된 install을 가리킴 | first-party client version 또는 local install drift | 먼저 Claude Code를 업데이트하고 실제로 새 binary를 실행 중인지 확인 | update 후 같은 task를 같은 path에서 다시 실행 | current version에서도 같은 deprecated-parameter error가 남음 |
opus로 바꿨다고 생각하지만 backend route가 다름 | Anthropic API와 Bedrock / Vertex / Foundry alias 차이 | opus가 그 route에서 정말 Opus 4.7인지 먼저 확인 | correction 또는 pin 후 같은 path에서 재실행 | route를 확인해도 error가 그대로 |
wrapper, plugin, proxy, config가 아직 top_p / temperature / top_k를 주입함 | outer request-shaping layer | 오래된 fields를 값 조정이 아니라 삭제 | cleaned request shape로 같은 path 재실행 | 오늘 당장 stack이 그 fields를 멈출 수 없음 |
| stack을 바로 고치기 어렵지만 workflow를 복구해야 함 | first-party 밖의 compatibility lag | version, route, cleanup 이후에만 bridge 사용 | fallback이 같은 task를 복구하는지 확인 | fallback이 또 다른 contract mismatch를 만듦 |
이 표의 목적은 가능한 모든 시나리오를 넓게 나열하는 것이 아닙니다. 가장 작은 change로 가장 큰 signal을 얻는 순서를 강제하는 데 있습니다. 많은 사용자가 시간을 잃는 이유는 해결책이 부족해서가 아니라 provider나 route를 너무 빨리 바꿔서 원래 path의 검증 가능성을 잃기 때문입니다.
Opus 4.7에서 무엇이 바뀌었고, 왜 top_p가 400이 되는가
Anthropic의 migration guide는 이 지점을 꽤 분명하게 씁니다. Opus 4.7에서는 비기본값 top_p, temperature, top_k가 400을 반환하며, 가장 안전한 migration path는 그 fields를 request에서 아예 빼는 것입니다. 핵심은 단순한 deprecated warning이 아니라 hard request validation boundary가 바뀌었다는 점입니다.
이 차이를 놓치면 독자는 바로 "더 안전한 숫자를 넣으면 되지 않을까?"라고 생각합니다. 하지만 이제 correct move는 오래된 knob를 다른 값으로 연명시키는 것이 아닙니다. 아예 보내지 않는 것입니다. request path에 그 fields가 남아 있는 한 model contract와 request shape는 계속 충돌합니다.
또 하나의 변화는 제어 방식의 중심이 sampling params에서 prompt quality나 effort 같은 현재 surface로 이동했다는 점입니다. 여기서 필요한 것은 오래된 knobs를 붙잡는 것이 아니라, 지금 model family가 기대하는 control surface로 path를 맞추는 일입니다.
Claude Code 자체가 오래됐거나 supported route 위에 있지 않은 경우
2026년 4월 17일 기준 Claude Code docs는 Opus 4.7에 Claude Code v2.1.111+가 필요하다고 말합니다. 따라서 version check를 첫 줄에 두는 편이 맞습니다. first-party client가 support window 밖에 있다면 그 뒤의 wrapper나 alias diagnosis는 전부 흐려집니다.
실제 확인 순서는 짧으면 충분합니다.
- 지금 실행 중인 Claude Code version을 확인합니다.
v2.1.111보다 오래됐다면 업데이트하고, shell이 새 binary path를 가리키는지 봅니다.- update 뒤에는 provider나 env vars를 동시에 바꾸지 말고 같은 task를 같은 path에서 다시 실행합니다.
세 번째가 특히 중요합니다. update와 route change를 동시에 하면 current first-party client가 문제를 고쳤는지, 아니면 다른 path로 빠져나갔는지 알 수 없습니다.
실제 root cause가 stale install이나 old binary path였다면, 다음 단계는 Claude Code install guide가 더 잘 맞습니다. 이 페이지는 exact deprecated-parameter recovery에 집중하는 편이 독자에게 더 유용합니다.
provider / alias route가 생각한 것과 다른 경우
이 지점을 흐리게 쓰면 diagnosis가 무너집니다. Claude Code의 current docs는 모든 backend를 같은 이야기로 취급하지 않습니다. Anthropic API에서는 opus가 이미 Opus 4.7입니다. 반대로 Bedrock, Vertex, Foundry에서는 4.7을 명시적으로 pin하지 않으면 opus가 여전히 4.6일 수 있습니다.
즉, 두 독자가 모두 "opus로 바꿨다"고 말해도 같은 contract를 테스트하는 것은 아닙니다. 한 사람은 실제로 4.7에 있어 deprecated-parameter rule에 맞닥뜨리고 있고, 다른 사람은 아직 4.6에 있어 전혀 다른 mismatch를 추적하는 중일 수 있습니다. 이 구분 없이 body cleanup에 들어가면 독자는 틀린 branch를 고치기 시작합니다.
안전한 읽기는 이렇게 정리됩니다.
- Anthropic API path라면 alias failure보다 outer layer를 먼저 의심합니다.
- Bedrock, Vertex, Foundry라면
opus만 바꿔 놓고 정말 4.7인지 먼저 확인합니다. - provider panel이나 wrapper가 있다면 UI label이 아니라 actual target route를 확인합니다.
이 section의 목적은 쓸데없는 paranoia가 아니라 wrong contract를 고치지 않기 위한 최소한의 branch correction입니다.
wrapper, plugin, config가 오래된 sampling params를 보내는 경우
version과 route가 확인된 뒤 가장 가능성이 높은 branch가 여깁니다. current Claude Code support가 있다는 사실만으로는 "왜 같은 path가 아직도 top_p deprecated를 보여주는가"에 대한 답이 되지 않습니다. 실제 owner가 outer layer에 있는 경우가 훨씬 많습니다.
먼저 살펴볼 곳은 대체로 정해져 있습니다.
- Claude Code 바깥에 감싼 local scripts
- provider adapters
- proxy middleware
- 오래된 examples에서 남은 config fragments
여기서 가장 단단한 fix는 값을 조정하는 것이 아니라 fields를 삭제하는 것입니다. temperature: 1을 넣어 연명하는 것보다 omission이 더 안전합니다. Anthropic의 migration guidance도 그 방향입니다.
fields를 지운 뒤에도 output behavior 제어가 필요하다면 더 선명한 prompting과 current effort로 제어를 옮기세요. 목표는 오래된 sampling surface를 되살리는 것이 아니라 request path를 current model contract로 되돌리는 것입니다.
독자의 실제 job이 "4.7과 4.6 중 어느 쪽을 선택할까"까지 넓어졌다면 Claude Opus 4.7 vs Claude Opus 4.6로 보내는 편이 낫습니다. 이 페이지는 path recovery만 담당해야 합니다.
fix를 어떻게 검증하고, 언제 fallback이 타당해지는가
same-path verification은 이 페이지의 경계선입니다. 무엇을 고쳤든 verification은 같은 task, 같은 backend, 같은 path로 돌아와야 합니다. 다른 provider, 다른 model family, 다른 wrapper chain에서 동작한 것은 원래 path recovery를 증명하지 않습니다.
verification loop는 짧으면 됩니다.
- backend와 task를 그대로 둡니다.
- request를 실제로 보내는 layer에서 deprecated fields를 지웁니다.
- 같은 path에서 한 번 다시 실행합니다.
- cleaned config를 남겨 재발을 막습니다.
fallback은 금지되지 않았습니다. 다만 등장 순서가 늦어야 합니다. 다음 조건이 모두 만족된 뒤에야 합니다.
- Claude Code가 current support window 안에 있습니다.
- backend route가 확인되었습니다.
- cleanup branch에서 무엇을 지워야 하는지 알고 있습니다.
- 그래도 stack이 오늘 그 fields를 멈출 수 없습니다.
이때 fallback은 temporary bridge가 될 수 있습니다. 예를 들어 오래된 model path를 잠시 유지하거나, compatibility layer로 rejected fields를 잘라내는 방식입니다. 하지만 main fix는 아닙니다. 장기적으로 올바른 상태는 request path를 Opus 4.7의 current contract에 맞추는 것입니다.
만약 진짜 exact 400 break가 sampling params가 아니라 assistant-prefill removal 쪽이었다면 Claude Opus prefill error fix가 더 가까운 sibling입니다. 둘 다 old request shape와 new contract의 충돌이지만, 원인과 replacement workflow는 같지 않습니다.
Frequently Asked Questions
top_p deprecated는 Claude Code 자체 bug인가요?
단순하게는 아닙니다. Claude Code는 독자가 보고 검색하는 symptom surface입니다. hard break 자체는 Opus 4.7의 request validation에 있습니다. current Claude Code support는 존재하고, 실제 질문은 어느 layer가 아직 오래된 fields를 보내고 있느냐입니다.
왜 opus는 backend마다 의미가 다른가요?
current alias mapping이 backend마다 다르기 때문입니다. Anthropic API에서는 opus가 Opus 4.7이지만, Bedrock, Vertex, Foundry에서는 explicit pin이 없으면 아직 4.6일 수 있습니다. 그래서 route verification이 body cleanup보다 먼저 옵니다.
temperature나 top_p를 안전한 값으로 바꿔 남길 수 없나요?
지금 더 안전한 move는 삭제입니다. Anthropic의 Opus 4.7 guidance는 다른 숫자로 연명시키기보다 omission을 권합니다.
오래된 sampling controls 대신 무엇을 써야 하나요?
더 분명한 prompting과, 지원되는 범위의 effort입니다. 오래된 sampling surface를 재구성하는 대신 current model family가 기대하는 control surface를 씁니다.
fallback은 언제 타당한가요?
version, route, cleanup을 확인했는데도 stack이 fields를 멈추지 못할 때만입니다. temporary bridge는 될 수 있지만 첫 조치는 아닙니다.
The Working Rule
Claude Code가 Opus 4.7에서 top_p deprecated를 보여주면 provider shopping 신호가 아니라 request contract mismatch로 다루세요. 먼저 version, 그다음 route, 그 다음 old fields remove, 그리고 같은 path verification. 그래도 stack이 멈추지 못하면 그때만 fallback을 씁니다.