Claude Code Router OpenRouter, 다른 모델에서 멈추면 provider only를 의심해야 합니다

Claude Code Router에서 OpenRouter 모델만 바꿨는데 멈추거나 빈 응답, 404가 나오면 먼저 provider.only를 의심하면 됩니다. OpenRouter는 같은 모델 ID를 여러 provider endpoint로 라우팅하고, Claude Code가 보내는 tools 요청을 처리할 수 있는 endpoint 후보가 아니면 요청이 거절되거나 스트림이 끊길 수 있습니다. /41의 novita/fp8은 qwen/qwen3-coder에 대한 모델별 핀이므로 새 모델에 그대로 복사하면 안 됩니다.

qwen/qwen3-coder에서 멈춤과 빈 응답을 다룬 해결 과정은 이 글에 따로 정리되어 있습니다. 여기서는 그 설정을 다시 설명하지 않고, 다른 OpenRouter 모델로 바꿀 때 provider를 왜 다시 고르고 only를 어디서 확인해야 하는지만 정리하겠습니다.

OpenRouter에서 모델만 바꿨는데 왜 빈 응답이나 중간 끊김이 생길까?

한 줄 답: OpenRouter의 모델 ID와 실제 요청을 처리하는 provider endpoint는 별개고, Claude Code는 일반 채팅보다 tools가 붙은 요청을 자주 보내기 때문에 모델을 바꾸면 호환 후보도 달라질 수 있습니다.

OpenRouter에서 제공자/모델 형식의 모델 ID를 선택하면 그 모델을 제공하는 여러 endpoint 중 하나로 요청이 전달됩니다. provider를 따로 제한하지 않으면 가용성이나 라우팅 규칙에 따라 후보가 선택되고, provider.only를 지정하면 그 목록 안에서만 endpoint를 찾게 됩니다.

문제는 Claude Code의 요청이 단순히 텍스트를 보내고 답을 받는 형태로 끝나지 않는다는 점입니다. 파일 확인, 명령 실행, 검색 같은 작업을 이어 가는 과정에서 tools와 tool_choice가 포함될 수 있습니다. 모델 자체는 응답할 수 있어도 현재 선택된 endpoint가 tools를 처리하지 못하면, 첫 번째 일반 질문은 지나가고 실제 작업 단계에서 빈 응답이나 스트림 중단이 나타날 수 있습니다.

따라서 “모델을 바꿨더니 멈췄다”는 현상만 보고 모델의 성능이나 timeout부터 의심하면 안 됩니다. 로그에서 요청한 모델, 최종 provider, 응답 상태, 오류 문구를 함께 봐야 provider 후보가 바뀐 문제인지 구분할 수 있습니다.

404 No endpoints found that support tool use는 무엇을 뜻할까?

한 줄 답: 현재 모델과 허용된 provider 범위 안에서 tools를 지원하는 endpoint를 찾지 못했다는 뜻입니다.

OpenRouter에서 다음과 같은 오류가 나오면 HTTP 상태 코드 404만 볼 게 아니라 뒤의 문장을 읽어야 합니다.

No endpoints found that support tool use

이 오류는 크게 두 경우로 나뉩니다. 모델 페이지에서 해당 모델이 tools를 지원하지 않거나, 모델은 tools를 지원하지만 provider.only로 남겨 둔 endpoint 중에는 tools를 처리할 수 있는 곳이 없는 경우입니다. 두 번째 경우라면 모델을 바꿀 필요 없이 provider 제한부터 다시 확인할 수 있습니다.

OpenRouter 모델 페이지에서 먼저 Tools 또는 지원 파라미터 항목을 보고, provider 목록에서도 tools를 지원하는 endpoint를 확인해야 합니다. 화면에 보이는 provider 이름과 요청에 넣어야 하는 provider slug가 다를 수 있으니, 표시명만 보고 임의로 적지 말고 해당 모델 페이지에 표시된 정확한 slug를 사용해야 합니다.

반대로 모델 자체에 tools 지원 정보가 없다면 only 값을 바꿔도 해결되지 않습니다. Claude Code가 필요한 도구 요청을 보낼 수 있는 모델인지부터 다시 선택해야 합니다. 이때 timeout을 늘리는 것은 endpoint에 tools 기능을 추가하는 방법이 아닙니다.

No allowed providers are available는 provider.only와 어떤 관계가 있을까?

한 줄 답: only로 허용한 목록과 현재 모델이 실제로 제공하는 endpoint의 교집합이 없거나, 허용된 endpoint가 사용할 수 없는 상태라는 뜻입니다.

예를 들어 기존 모델에서만 제공되는 특정 endpoint variant를 새 모델의 only에 남겨 두면, 새 모델을 제공하는 후보가 있어도 그 endpoint는 선택할 수 없습니다. slug를 잘못 적은 경우, 모델 페이지에서 해당 variant가 사라진 경우, tools 조건까지 겹친 경우에도 같은 결과가 날 수 있습니다.

only는 “이 provider를 우선 사용해 달라”는 힌트가 아니라 허용 목록입니다. 목록 밖의 provider로 우회하는 것이 막히므로, allow_fallbacks를 꺼 둔 설정에서는 첫 후보가 unavailable일 때 바로 실패할 수 있습니다. fallback을 켜 두었더라도 only 목록 자체가 너무 좁으면 목록 밖의 endpoint는 대안이 되지 않습니다.

두 오류는 비슷해 보여도 확인 지점이 조금 다릅니다. No endpoints found that support tool use라면 tools 지원 여부와 provider 호환성을 먼저 보고, No allowed providers are available라면 only의 철자·범위·preset·fallback 설정을 먼저 보면 됩니다. 물론 하나의 설정이 두 조건을 동시에 막아서 두 메시지가 번갈아 나올 수도 있습니다.

/41의 novita/fp8을 다른 OpenRouter 모델에 그대로 넣으면 안 되는 이유는 무엇일까?

한 줄 답: /41의 provider.only 값은 qwen/qwen3-coder 요청이 사용할 endpoint를 고정한 모델별 설정이지, 모든 OpenRouter 모델에 적용되는 공통 provider가 아닙니다.

novita/fp8이라는 문자열이 설정에 들어 있다고 해서 모든 모델이 같은 endpoint에서 서비스되는 것은 아닙니다. OpenRouter의 provider 목록은 모델마다 다르고, 같은 provider라도 모델별로 tools·출력 길이·reasoning 같은 지원 조건이 달라질 수 있습니다. fp8 같은 variant 표기도 다른 모델의 endpoint가 자동으로 된다는 뜻이 아니고, 해당 모델 페이지에 실제로 노출되는지 따로 봐야 합니다.

그래서 /41의 설정을 새 모델에 복사하면 두 가지 문제가 생길 수 있습니다. 새 모델이 그 endpoint에 없어서 허용 후보가 사라지거나, endpoint는 존재해도 Claude Code가 보내는 tools 요청을 처리하지 못해 404가 날 수 있습니다. 이전 글의 설정은 그 글에서 다룬 모델과 endpoint의 조합으로만 이해하면 됩니다.

새 모델의 provider.only는 어떤 순서로 다시 설정할까?

모델을 바꿀 때는 기존 only 값을 먼저 복사한 다음 오류를 기다리는 방식보다, 새 모델의 endpoint 목록에서 다시 시작하는 편이 안전합니다. 다음 순서로 확인하면 됩니다.

1. Claude Code와 CCR이 실제로 요청할 정확한 모델 ID를 확인합니다. 모델 이름의 버전, 제공자 prefix, preset이 다르면 OpenRouter가 전혀 다른 모델로 처리할 수 있습니다.

2. OpenRouter의 새 모델 페이지에서 tools 지원 여부를 보고, provider 목록에서 tools를 지원하는 endpoint slug를 확인합니다. 일반 응답 가능 여부만 보지 말고 Claude Code의 도구 요청까지 처리할 수 있는지를 기준으로 봐야 합니다.

3. 처음에는 기존 모델의 provider.only를 새 모델에 복사하지 말고 잠시 삭제해서 기본 라우팅으로 확인합니다. 이 상태에서 tools 요청이 통과하면, provider 제한이 원인이었을 가능성이 높습니다.

4. 특정 endpoint를 꼭 고정해야 할 때만 새 모델의 모델별 transformer 안에 해당 slug를 넣습니다. CCR 설정 구조에서의 형태는 다음처럼 볼 수 있습니다.

{
  "transformer": {
    "use": ["openrouter"],
    "<새 모델 ID>": {
      "use": [
        [
          "openrouter",
          {
            "provider": {
              "only": ["<tool-use 지원 provider slug>"]
            }
          }
        ]
      ]
    }
  }
}

위 코드는 전체 config.json이 아니라 Providers 안의 모델별 transformer 설정 형태만 보여 준 예시입니다. <tool-use 지원 provider slug> 부분에는 새 모델 페이지에서 확인한 정확한 값을 넣어야 하고, 이전 모델에서 쓰던 값을 습관처럼 다시 넣으면 안 됩니다. provider를 고정할 이유가 없다면 모델별 transformer에서 provider.only를 빼고 OpenRouter의 기본 후보 선택에 맡기는 것도 확인 순서에 포함됩니다.

5. 설정을 저장한 뒤 ccr restart로 CCR을 다시 시작합니다. 재시작하지 않으면 파일에 바꾼 값과 실행 중인 서비스의 값이 다를 수 있습니다.

6. "LOG": true를 켜고 짧은 요청을 보내서 요청 모델과 최종 provider가 예상대로 잡혔는지 확인합니다. 오류가 사라졌다는 결과만 보지 말고, 실제로 어느 provider endpoint를 거쳤는지 로그와 OpenRouter 요청 기록을 대조하는 게 좋습니다.

기본 라우팅에서는 정상인데 특정 slug를 넣은 뒤 다시 404가 난다면, 그 slug가 새 모델의 tools 지원 endpoint가 아니라는 뜻일 수 있습니다. 이때는 only를 다시 지우고 모델 페이지의 provider 목록부터 재확인하면 됩니다.

transformer 설정과 OpenRouter preset은 언제 확인해야 할까?

한 줄 답: CCR의 transformer가 provider.only를 요청에 넣을 수 있고, OpenRouter preset도 provider routing 조건을 가질 수 있으므로 둘 중 하나만 바꾸면 실제 요청에 이전 제한이 남을 수 있습니다.

CCR에서는 openrouter transformer가 Claude Code 요청을 OpenRouter 형식으로 바꾸면서 provider 객체를 함께 전달합니다. 모델별 설정을 쓰는 경우에는 모델 ID가 실제 라우팅 대상과 정확히 일치해야 하고, 다른 이름 아래에 넣은 only는 현재 요청에 적용되지 않을 수 있습니다.

또 모델 값에 model@preset/name 형태가 들어 있다면 OpenRouter preset도 확인해야 합니다. preset 안에 provider 순서, only, fallback 같은 조건이 들어 있을 수 있기 때문입니다. CCR의 Providers[].transformer와 Router 또는 Claude Code의 모델 선택 화면을 따로 보지 말고, 최종 요청이 어떤 모델과 preset으로 만들어지는지 한 흐름으로 확인해야 합니다.

설정 위치를 고친 뒤에는 다시 ccr restart를 실행하고, 로그에서 요청 모델과 resolved provider를 확인하면 됩니다. 로그에 계속 이전 provider가 찍힌다면 only 문법보다 먼저 라우팅 대상과 preset이 바뀌었는지부터 봐야 합니다.

provider 문제 말고 함께 점검할 설정은 무엇일까?

한 줄 답: 요청이 provider까지 도달한 뒤 400이 난다면 only와 별개로 token 제한이나 reasoning 파라미터를 확인해야 합니다.

404나 No allowed providers are available는 후보 endpoint를 고르는 단계의 문제라서, timeout 값을 늘려도 해결되지 않습니다. 반면 provider가 선택된 다음 400이 반환된다면 요청 변환이나 모델별 파라미터 호환성이 원인일 수 있습니다.

커뮤니티 이슈에서는 일부 provider와 모델 조합에서 maxtoken transformer가 필요하다는 사례, mandatory-reasoning 모델에 thinking 비활성화 값을 보내면 400이 날 수 있다는 사례가 따로 언급됩니다. 이런 보조 원인을 확인할 때 참고할 이슈 번호는 #409, #419, #188, #1238입니다. 다만 특정 모델에 나온 사례를 모든 provider에 적용되는 규칙으로 보면 안 되고, 로그의 실제 요청 본문과 오류를 기준으로 판단해야 합니다.

정리하면 Claude Code Router에서 OpenRouter 모델을 바꿀 때는 다음 흐름만 기억하면 됩니다. 새 모델의 정확한 ID를 확인하고, 모델 페이지에서 tools 지원 endpoint를 찾고, 기존 provider.only는 일단 제거한 뒤 기본 라우팅을 확인합니다. 그다음 꼭 필요한 경우에만 새 모델의 provider slug를 모델별 transformer 또는 preset에 다시 지정하고, ccr restart와 LOG=true로 최종 provider까지 확인하면 됩니다.

할인 경로가 필요하면 마지막으로 이 글만 확인하면 됩니다.