작성자 주: Codex와 WorkBuddy는 모두 Claude 전용 클라이언트가 아니며, 오류는 대부분 연결 계층에서 발생해요. 이 글에서는 오류를 ‘엔드포인트, 도구 호출과 응답, 사고 블록’ 세 가지로 나누고, 오류 메시지별 해결 방법을 살펴볼게요.
저희도 직접 이 문제를 겪었어요. 처음에는 편의상 OpenAI 호환 프로토콜로 Claude를 호출했어요. Claude를 OpenAI 모델처럼 사용한 거죠. 간단한 대화는 문제없었지만, 도구를 호출하기만 하면 오류가 났고 재시도해도 소용없었어요. 프로토콜을 Anthropic 네이티브 엔드포인트인 /v1/messages로 바꾸고 나서야 정상적으로 작동했어요.
먼저 해당되는지 확인해 보세요. Codex를 시작하자마자 wire_api 관련 오류가 나거나, WorkBuddy에서 대화는 정상인데 도구를 호출하면 400 오류가 나거나, 응답 내용이 이유 없이 비어 있다면 이 글에서 다루는 문제일 가능성이 높아요.
- 모델 자체의 문제는 아니에요. 연결 계층에서 세 가지가 맞지 않는 것이 원인이에요. 엔드포인트, 도구 호출과 응답, 사고 블록이죠.
- 가장 쉽게 해결할 수 있는 건 세 번째 유형인 사고 블록과 출력 예산 문제예요. 클라이언트에서 읽기 방식과
max_tokens만 바꾸면 돼요. - 두 번째 유형인 도구 호출과 응답은 중간 정도의 난이도로, 주로 변환 계층이나 게이트웨이에서 수정해요.
- 가장 까다로운 건 첫 번째 유형인 엔드포인트 문제예요. 클라이언트를 바꾸거나 변환 게이트웨이를 추가해야 해요.
결론부터 말하면 권장 순서는 Anthropic 네이티브 프로토콜 > 게이트웨이에서 anthropic으로 변환 > OpenAI 호환 chat이에요. 우선 아래 대조표에서 발생한 오류가 어떤 유형인지 확인해 보세요.
Codex·WorkBuddy에서 Claude 사용 시 오류가 발생하는 3가지 핵심 원인
먼저 몇 가지 용어부터 살펴볼게요. Responses, Messages, Chat Completions는 세 가지 주문 방식이라고 생각하면 돼요. 주방에서 만드는 요리는 같지만 주문서 형식이 다른 거죠. Codex는 Responses로만 주문하고, Claude는 Messages와 Chat Completions만 받아요. thinking 블록은 모델의 연습장에 해당하며, Anthropic은 이 연습장이 누군가에 의해 수정됐는지 검증해요.
| 유형 | 핵심 원리 | 주로 수정하는 쪽 | 수정 난이도 |
|---|---|---|---|
| 유형 1 엔드포인트 불일치 | Codex는 Responses만 보내고 Claude는 이 형식을 받지 않음 | 도구 또는 게이트웨이 교체 | 가장 어려움 |
| 유형 2 도구 왕복 처리 불일치 | 변환 과정에서 id, 콘텐츠 블록 또는 thinking 블록이 변경됨 | 주로 게이트웨이 | 보통 |
| 유형 3 thinking 블록과 예산 불일치 | 모델은 매번 생각하는데 클라이언트는 여전히 기존 방식으로 결과를 읽음 | 클라이언트 | 가장 쉬움 |
제1유형: Codex에서 Claude를 호출할 때 엔드포인트가 맞지 않는 경우
오류 메시지: Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
설정에서 wire_api = "chat"을 더 이상 지원하지 않으므로 responses로 바꿔야 한다는 뜻이에요.
원인: Codex 공식 설정 문서에 따르면 wire_api에 사용할 수 있는 값은 이제 responses뿐이에요. 예전에 대안으로 쓰던 ‘wire_api를 chat으로 변경하기’는 더 이상 통하지 않으며, 새 버전의 Codex는 설정을 불러올 때 바로 오류를 발생시켜요. 해당 provider를 전혀 사용하지 않더라도 codex login status까지 실행되지 않을 수 있어요. 반면 APIYI apiyi.com의 Claude 모델은 anthropic과 openai 엔드포인트만 제공하고 /v1/responses는 제공하지 않아요. 양쪽 형식이 맞지 않는데 중간에서 변환해 주는 계층도 없으니 오류가 발생할 수밖에 없어요.
해결 방법:
1. 클라이언트: ~/.codex/config.toml을 열고 오류 메시지에 따라 남아 있는 chat 설정을 제거해 Codex부터 정상 실행되게 해요.
2. 도구 변경: Claude로 코딩하는 게 목적이라면 네이티브 Messages를 사용하는 Claude Code로 바꾸세요.
3. 게이트웨이: Codex를 계속 써야 한다면 Responses를 Messages로 변환하는 게이트웨이를 추가하세요. 공급자 주소에는 Anthropic 네이티브 엔드포인트를 우선 입력하세요.
확인 기준: codex login status가 정상 실행되어야 해요. 게이트웨이를 사용할 때는 파일을 읽어야 하는 지시를 내려 Codex가 도구 호출을 한 차례 완전히 수행하는지 확인하세요.
유형 2: Claude 도구 호출과 응답이 맞지 않는 경우
오류 메시지:
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
첫 번째는 tool_use 바로 뒤에 대응하는 tool_result가 없다는 뜻이에요. 두 번째는 Chat 형식에서 발생하는 같은 유형의 문제예요. 세 번째는 이전 턴의 thinking 블록이 수정됐다는 뜻이고, 네 번째는 thinking 블록의 서명이 현재 세션과 일치하지 않는다는 뜻이에요.
원인: 호환 계층은 Claude의 text, tool_use, tool_result, thinking 콘텐츠 블록을 각각 tool_calls와 role: tool로 변환한 뒤 다시 원래 형식으로 변환해요. 이 과정에서 id가 잘못 연결되거나, 콘텐츠 블록이 합쳐지거나, thinking 블록이 이동하면 400 오류가 반환돼요. Responses에는 developer 역할이 있지만 Messages에는 없으므로 system에 합쳐야 해요. 또한 claude-opus-5-5는 다음과 같은 이전 방식을 지원하지 않아요: 강제 tool_choice(any 또는 특정 도구 지정), assistant 메시지 사전 입력(prefill), temperature / top_p / top_k.
해결 방법:
1. 게이트웨이: 각 tool_use 바로 뒤에 같은 id의 tool_result가 오도록 하고, tool_result를 user 메시지 콘텐츠 블록의 맨 앞에 배치하세요.
2. 게이트웨이: 이전 턴의 assistant 메시지를 그대로 반환하세요. thinking 필드가 비어 있는 블록도 포함하고, developer 콘텐츠는 system에 합치세요.
3. 클라이언트: tool_choice는 auto 또는 none만 사용하고, prefill과 샘플링 파라미터를 삭제하세요.
4. 클라이언트: 이미 서명 오류가 발생했다면 새 세션을 시작하세요. APIYI 공식 FAQ에 따르면 이 오류가 Request rejected (429)로 표시되기도 하지만, 요청 제한이 아니므로 대기 시간을 늘려 재시도해도 소용없어요.
5. 도구 변경: harness에 강제 tool_choice가 고정되어 있어 직접 수정할 수 없다면 클라이언트를 바꾸세요.
비슷한 400 오류를 해결할 때는 Claude Code 400 tool use concurrency 오류 해결 가이드를 참고하세요. tool_use와 tool_result의 연결이 실패했을 때 문제를 하나씩 찾아내는 방법을 설명해요.
검증 기준: 파일 읽기, 수정, 다시 읽기 등 여러 턴에 걸친 도구 호출에서 더 이상 400 오류가 발생하지 않고, 같은 세션에서 서명 오류도 발생하지 않아야 해요.
유형 3: Claude thinking 블록과 출력 예산 불일치
오류 증상: "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. 오류가 나타나요. "thinking.type.disabled" is not supported for this model. 오류가 발생하거나, 오류 없이 응답이 비어 있거나 잘리는 경우도 있어요.
원인: claude-opus-5-5는 요청할 때마다 사고하며, 응답이 thinking 블록으로 시작할 수 있어요. 클라이언트가 위치를 기준으로 content[0].text를 읽으면 빈값을 가져오게 돼요. 사고 토큰은 출력 토큰으로 과금되며 max_tokens도 차지해요. 이 세대부터 도구 호출 사이의 설명도 thinking 블록에 들어가는데, 기본 display가 omitted라서 내용이 비어 보일 수 있어요.
해결 방법:
1. 클라이언트: thinking 파라미터를 생략하거나 thinking: {"type": "adaptive"}로 설정하고, budget_tokens를 삭제하세요.
2. 클라이언트: 사고 깊이는 output_config.effort로 제어하세요. low / medium / high / xhigh / max 중 선택할 수 있으며, 기본값은 medium이에요.
3. 클라이언트: 응답을 읽을 때 위치가 아닌 type을 기준으로 text 블록을 찾으세요.
4. 클라이언트: max_tokens를 사고 내용과 본문을 모두 담을 수 있도록 설정하세요. 설명 내용을 보려면 thinking.display를 summarized로 설정하세요.
이 새로운 방식을 자세히 이해하려면 Adaptive Thinking 적응형 사고 알아보기를 참고하세요. budget_tokens에서 effort 단계로 전환하는 방법을 설명해요.
확인 기준: 같은 프롬프트를 여러 번 연속으로 보내도 본문이 비어 있지 않고, thinking.type 관련 오류가 더 이상 발생하지 않아요.
Claude 오류 메시지 빠른 확인표
| 오류 메시지 키워드 | 유형 | 5분 자가 점검 | 해결 후에도 오류가 나면 |
|---|---|---|---|
wire_api = "chat" is no longer supported |
유형 1 | config.toml에 chat 설정이 남아 있는지 확인 | Magpie 튜토리얼 |
tool_use ids were found without tool_result |
유형 2 | tool_result의 id와 위치 확인 | Claude Code 400 tool use concurrency 오류 |
must be followed by tool messages |
유형 2 | Chat 호환 레이어를 거치는지 확인 | Claude Code 400 tool use concurrency 오류 |
Invalid signature in thinking block |
유형 2 | 새 세션을 열고 다시 시도 | Adaptive Thinking 적응형 사고 알아보기 |
thinking.type.enabled / 응답이 비어 있음 |
유형 3 | budget_tokens를 삭제하고 type을 기준으로 읽도록 변경 | Adaptive Thinking 적응형 사고 알아보기 |
| 간단한 대화는 되지만 도구를 호출하면 오류 발생 | 유형 2 | WorkBuddy 연동 프로토콜 확인 | Workbuddy는 Claude 네이티브 형식 호출을 지원하나요? |
Codex와 WorkBuddy에서 Claude 호출 오류를 해결하는 두 가지 방법
| 방법 | 적합한 사용자 | 프로토콜 우선순위 |
|---|---|---|
| A 네이티브 클라이언트로 전환 | Claude로 코딩만 하고 싶은 사용자 | 가장 높음, 변환에 따른 손실 없음 |
| B 변환 게이트웨이 추가 | Codex나 WorkBuddy를 계속 써야 하는 사용자 | 두 번째, 공급업체 주소에 anthropic 입력 |
| chat 호환 방식 장기 사용 | 권장하지 않음 | 가장 낮음, 도구 호출과 사고 블록에 문제가 생기기 쉬움 |
방법 A: Codex에서 Claude를 쓰고 싶다면 Claude Code로 전환하세요. WorkBuddy의 공식 모델 설정에는 /chat/completions와 「사용자 지정 프로토콜」 스위치만 있고 Anthropic 네이티브 연결 옵션은 없어요. 따라서 WorkBuddy에서 네이티브 thinking을 사용할 수 있다고 기대하기는 어려워요. 자세한 내용은 WorkBuddy가 Claude 네이티브 형식 호출을 지원하나요?를 참고하세요. 대화는 되는데 도구 호출에서 오류가 나는 이유와 우회 방법을 설명해요.
WorkBuddy에 직접 연결하려면 「설정 → 모델 → 사용자 지정」으로 이동하세요. Base URL에는 https://api.apiyi.com/v1, 모델명에는 claude-opus-5-5를 입력하고, Key에는 APIYI apiyi.com의 토큰 페이지에서 생성한 키를 사용하세요. URL은 /v1까지만 입력하고 /chat/completions를 직접 덧붙이지 마세요.
이미지 설명: URL이 /v1까지만 입력됐는지, 모델명이 claude-opus-5-5인지, 「사용자 지정 프로토콜」 스위치가 꺼져 있는지 확인하세요.
방법 B: Codex에 게이트웨이를 추가할 때는 Codex의 wire_api = "responses" 설정을 그대로 유지하세요. 게이트웨이가 요청을 Messages 형식으로 변환해 전달해요. WorkBuddy의 사용자 지정 모델 URL은 로컬 게이트웨이를 가리키도록 설정하고, Claude 모델의 공급업체 주소에는 Anthropic 네이티브 엔드포인트 https://api.apiyi.com을 입력하세요.
🎯 기술 팁: 키 하나로 네이티브 Messages와 호환 chat 엔드포인트를 모두 테스트할 수 있어요. 먼저 APIYI apiyi.com의 테스트 크레딧으로 두 프로토콜의 도구 호출 결과를 비교한 뒤 방법을 선택해 보세요.
Magpie로 Codex와 WorkBuddy에 Claude 연결하기
Magpie는 MIT 라이선스로 제공되는 커뮤니티 오픈소스 도구예요. 로컬 127.0.0.1:3425에 게이트웨이를 띄워 OpenAI Chat, Responses, Anthropic Messages 형식 간 변환을 지원해 첫 번째 유형의 문제를 해결해 줘요. 수동 설정 외에도 Magpie의 그래픽 화면에서 설정할 수 있어요. API 키와 Base URL을 입력한 뒤 Codex와 WorkBuddy를 같은 게이트웨이에 연결하면 설정 파일을 직접 수정할 필요가 없어요. 전체 과정은 Magpie 튜토리얼에서 확인하세요. 게이트웨이 하나로 여러 Agent의 모델 공급원을 통합하는 방법을 설명해요.
- 공급업체 페이지: 키를 추가하세요. APIYI는 「중계」 그룹에 있으며, 「+ 사용자 지정 공급업체」를 눌러 직접 입력할 수도 있어요.
- Agent 페이지: Codex와 WorkBuddy에서 각각 claude-opus-5-5를 선택하세요.
- 새 세션을 시작하세요. 기존 세션의 대화 기록은 이어서 사용하지 마세요.
이미지 설명: 공급업체가 「중계」 그룹에서 사용 가능으로 표시되는지, Base URL이 Anthropic 네이티브 주소인지, Agent 페이지의 두 스위치가 모두 켜져 있는지 확인하세요.
Claude 호출 가격과 캐시 비용
아래 가격의 단위는 미국 달러 / 100만 토큰이에요. 2026-10-28 기준으로 확인했으며, 모델과 가격은 플랫폼의 모델 목록을 확인해 주세요.
| 모델 | 입력 | 출력 | 캐시 읽기 | 사용 가능 플랫폼 |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | APIYI apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | APIYI apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | APIYI apiyi.com |
에이전트는 매 라운드마다 전체 대화 이력을 다시 전송하며, claude-opus-5-5의 사고 토큰은 출력 가격으로 과금돼요. 변환 계층에서 system, tools 또는 접두사의 순서가 바뀌면 cache_control 중단점이 무효화되어 비용과 지연 시간이 모두 증가해요. 캐시 적중률이 비정상적이라면 Claude 캐시 적중률이 0으로 떨어졌을 때(diagnostics)에서 중단점이 무효화된 원인을 찾는 방법을 확인해 보세요.
위험 및 계정 차단에 대한 책임
Magpie 같은 게이트웨이는 커뮤니티 오픈소스 도구이며, APIYI의 공식 구성 요소가 아니에요. APIYI는 이를 보증하거나 기술 지원을 제공하지 않아요. 이런 도구로 요청을 전달하면 대상 서비스에서 요청이 제한되거나 계정이 차단될 수 있으며, 그에 따른 책임은 사용자에게 있어요. 먼저 테스트 계정으로 전체 연결 과정을 검증하고, 문제가 없는지 확인한 뒤 실제 계정에 적용하는 것을 권장해요.
이런 경우에는 굳이 설정하지 마세요
Codex에서 Claude를 가끔만 사용하거나, 회사 환경에서 추가 소프트웨어를 설치할 수 없거나, Claude만 사용하면 된다면 게이트웨이를 구축할 필요가 없어요. 클라이언트를 Claude Code로 바꾸거나, Codex에서 Responses를 기본 지원하는 모델로 바꾸는 편이 훨씬 간편해요.
자주 묻는 질문 FAQ
Q1: Codex는 Claude를 공식 지원하나요?
아니요. Codex는 Responses만 사용하는데, Claude는 해당 엔드포인트를 제공하지 않아요. 따라서 변환 계층을 거쳐야 사용할 수 있어요.
Q2: APIYI의 Claude에서 /v1/responses를 사용할 수 있나요?
아니요. APIYI apiyi.com의 Claude 모델은 anthropic과 openai 엔드포인트만 제공해요.
Q3: 429 오류가 발생하면 요청 제한에 걸린 건가요?
오류 메시지에 `Invalid signature in thinking block`이 포함되어 있다면 요청 제한이 아니라 사고 블록의 서명 검증에 실패한 거예요. 새 세션을 시작하면 돼요.
Q4: WorkBuddy에서 Anthropic 네이티브 프로토콜을 사용할 수 있나요?
공식 설정에는 Anthropic 네이티브 연결 옵션이 없어요. OpenAI 호환 방식을 사용하거나 게이트웨이를 거쳐 변환해야 해요.
Q5: 문제가 해결됐는지 빠르게 확인하려면 어떻게 하나요?
APIYI apiyi.com의 테스트 크레딧으로 새 세션을 시작해 도구를 여러 차례 연속 호출하고, 응답 본문이 비어 있지 않은지도 확인하세요.
Codex, WorkBuddy에서 Claude 오류가 발생할 때 확인할 사항
- Codex 설정에 chat 방식이 남아 있지 않은지 확인하세요.
- Claude 요청이 chat 호환 방식이 아닌 네이티브 프로토콜이나 anthropic으로 변환하는 게이트웨이를 거치는지 확인하세요.
- 각 tool_use 바로 뒤에 같은 id의 tool_result가 있는지 확인하세요.
- 이전 턴의 thinking 블록이 수정 없이 그대로 반환됐는지 확인하세요.
- 강제 tool_choice, prefill 또는 샘플링 파라미터를 사용하지 않았는지 확인하세요.
- 응답을 type별로 읽고,
max_tokens에 사고를 위한 공간이 확보됐는지 확인하세요.
정리
Codex나 WorkBuddy에서 Claude를 사용할 때 발생하는 오류는 대부분 엔드포인트, 도구 요청과 응답, 사고 블록의 세 가지로 나눌 수 있어요. 먼저 클라이언트의 응답 처리 방식을 고치고, 그다음 변환 계층을 수정하세요. 그래도 해결되지 않으면 클라이언트를 바꾸거나 게이트웨이를 추가하는 방법을 고려하세요.
프로토콜은 가능하면 네이티브 Anthropic을 사용하고, 그렇지 않다면 게이트웨이에서 anthropic으로 변환하세요. chat 호환 방식에 장기간 의존하는 것은 피하는 게 좋아요. APIYI apiyi.com에서 동일한 API 키로 다양한 프로토콜의 결과를 비교해 보세요.
📚 참고 자료
- Codex 설정 참조: wire_api 설정값 설명
- 링크:
developers.openai.com/codex/config-reference - 설명: 현재 wire_api가 responses만 지원하는지 확인할 수 있어요.
- Codex 설정 로딩 오류 사례
- 링크:
github.com/openai/codex/issues/41816 - 설명: wire_api 오류 메시지의 원문 출처예요.
- Claude Opus 5.5 마이그레이션 가이드
- 링크:
platform.claude.com/docs/en/models/opus-5-5/migration-guide - 설명: thinking, tool_choice, 샘플링 매개변수의 필수 제한 사항을 확인할 수 있어요.
- Anthropic 도구 호출 문제 해결
- 링크:
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - 설명: tool_use와 tool_result의 짝짓기 규칙을 확인할 수 있어요.
- WorkBuddy 모델 설정
- 링크:
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - 설명: 사용자 지정 모델 설정 메뉴와 사용자 지정 프로토콜 스위치를 확인할 수 있어요.
- Magpie 저장소
- 링크:
github.com/yetone/magpie - 설명: 커뮤니티 오픈소스 게이트웨이예요. 사용 전 위험을 직접 평가해 주세요.
작성자: APIYI 기술팀
기술 문의: APIYI apiyi.com 홈페이지에서 문의해 주세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
