How to Use GPT, Gemini, and Grok Models Inside Claude Code with CLI Proxy
Quick Summary
CLI Proxy는 Claude Code의 API 요청과 인증을 로컬에서 변환해 기존 구독으로 GPT·Gemini·Grok 계열 모델을 사용하고, Claude 모델 등급별로 서로 다른 모델을 배치할 수 있게 해주는 오픈소스 프록시입니다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
CLI Proxy는 Claude Code의 API 요청과 인증을 로컬에서 변환해 기존 구독으로 GPT·Gemini·Grok 계열 모델을 사용하고, Claude 모델 등급별로 서로 다른 모델을 배치할 수 있게 해주는 오픈소스 프록시입니다.
📌 핵심 요약
- CLI Proxy는 localhost:8317에서 동작하며, Claude Code의 ANTHROPIC_BASE_URL과 ANTHROPIC_AUTH_TOKEN을 이 주소와 프록시용 키로 지정해 비Claude 모델을 연결합니다.
- 사용자는 CLI Proxy에서 공급자별 OAuth 로그인을 수행하고, 프록시는 저장된 실제 공급자 토큰을 이용해 종량제 API 크레딧이 아닌 기존 구독 한도에서 요청을 처리합니다.
- Claude Code의 Opus·Sonnet·Haiku·Fable 등급별 환경변수를 각각 다른 모델이나 공급자에 매핑할 수 있으며, 추론 강도·스킬·서브에이전트·계획 모드도 API 변환 계층 위에서 계속 작동합니다.
- 프록시 설정에는 관리 화면 비밀번호인 secret-key와 클라이언트 요청을 검증할 api-keys가 필요하며, 사용 가능한 정확한 모델 이름은 인증된 /v1/models 엔드포인트에서 확인할 수 있습니다.
- CLI Proxy는 공급자별 OAuth 자격 증명을 여러 개 저장하고 기본적으로 라운드로빈 방식으로 순환하지만, Claude 구독을 다른 CLI에서 사용하는 역방향 구성은 Anthropic 이용약관에 어긋날 수 있다고 글은 경고합니다.
🧩 주요 포인트
- API 형식의 양방향 변환 → Claude Code의 인터페이스와 작업 흐름을 유지하면서 실제 모델 공급자를 교체할 수 있습니다.
- 더미 클라이언트 키와 실제 OAuth 토큰의 분리 → Claude Code의 인증 요구를 충족하면서 공급자 구독과 다중 계정 사용을 프록시가 중앙 관리합니다.
- Claude 등급별 독립 모델 매핑 → 하나의 공급자에 고정되는 기존 통합보다 모델 조합의 선택 폭이 넓어집니다.
🧠 상세 정리
1. CLI Proxy의 목적과 실행 모습
글은 CLI Proxy를 Claude Code와 외부 모델 공급자 사이에서 동작하는 로컬 프록시 서버로 소개합니다. Claude Code가 기본적으로 기대하는 Anthropic API 대신 localhost:8317을 바라보게 하면, 실제 응답 모델을 GPT·Gemini·Grok 계열로 바꿀 수 있다는 설명입니다. 시연에서는 Claude Code 상태 줄과 모델 선택기에 GPT 모델명이 표시되고, 사용자는 Claude Code를 벗어나지 않은 채 Terra·Luna·Sol 모델과 추론 강도를 전환합니다. 인터페이스만 유지되는 것이 아니라 스킬을 불러오고, 중간 수준 추론을 수행하며, 서브에이전트를 동원하는 실제 작업 흐름도 실행됩니다. 즉 이 구성의 핵심은 별도의 코딩 도구로 이동하는 것이 아니라 Claude Code의 조작 방식과 기능을 그대로 둔 채 뒤에서 호출되는 모델을 교체하는 데 있습니다.
2. 설치 방식과 기본 서비스 구성
CLI Proxy의 설치 경로는 운영체제와 배포 형태에 따라 달라집니다. 글에 따르면 Linux에는 원클릭 설치 스크립트와 AUR 패키지가 있고, Windows에는 릴리스 바이너리와 데스크톱 GUI가 있으며, 별도 VPS에서 운영하려는 경우에는 Docker 이미지도 사용할 수 있습니다. macOS에서는 Homebrew로 설치하고 서비스로 시작할 수 있으며, Apple Silicon 환경의 설정 파일 예시는 /opt/homebrew/etc/cliproxyapi.conf입니다. 설정 파일 위치는 설치 방식에 따라 달라지므로 사용자는 자신의 패키지 관리자나 설치 문서가 지정한 경로를 확인해야 합니다. 기본 예시는 포트 8317을 사용하며, 설정을 저장한 뒤에는 서비스가 새 값을 읽도록 재시작해야 합니다.
3. 관리 비밀번호와 프록시 API 키
설정에서 먼저 필요한 값은 관리 화면에 로그인할 때 사용하는 remote-management의 secret-key입니다. 글은 평문으로 입력한 이 값이 이후 해시되어 설정에 그대로 남지 않는다고 설명합니다. 별도의 api-keys 목록에는 Claude Code가 프록시로 보내는 모든 요청에 포함할 키를 등록하며, 예측하기 어려운 무작위 값을 생성해 사용하는 방식을 권합니다. Claude Code는 인증 토큰이 존재할 것을 요구하므로 이 키가 필요하지만, 실제 모델 공급자에게 전달되는 OAuth 토큰과는 역할이 다릅니다. 프록시는 수신한 키가 목록에 등록되어 있는지 먼저 검사하고, 일치하는 경우에만 실제 공급자 요청을 진행해 같은 컴퓨터의 다른 애플리케이션이 무단으로 사용량을 소모하는 것을 막습니다.
4. 공급자 OAuth 로그인과 자격 증명 확인
서비스를 시작한 뒤 사용자는 http://localhost:8317의 관리 센터에 접속해 설정한 secret-key로 로그인합니다. 대시보드의 OAuth Login 화면에서는 글의 예시 기준으로 Codex·Anthropic·Antigravity·Kimi 등 인증 가능한 공급자가 표시됩니다. Codex 로그인을 시작하면 일반적인 OAuth 승인 절차가 열리고, 계정을 선택해 권한을 승인하면 인증이 완료됩니다. 로그인 직후 화면 변화만으로 성공 여부가 명확하지 않을 수 있으므로, 글은 Auth Files 화면에서 공급자·파일 크기·상태 정보가 포함된 자격 증명을 확인하도록 안내합니다. 같은 공급자에 서로 다른 계정으로 여러 번 로그인하면 각 계정의 자격 증명이 별도 항목으로 저장되어 이후 다중 계정 순환에 사용됩니다.
5. Claude Code의 엔드포인트와 모델 매핑
클라이언트 측 구성은 Claude Code가 읽는 환경변수로 이루어지며, 글은 이를 셸 별칭 하나에 묶는 예시를 제시합니다. ANTHROPIC_BASE_URL에는 Anthropic 서버 대신 로컬 프록시 주소를 지정하고, ANTHROPIC_AUTH_TOKEN에는 설정 파일의 api-keys 중 하나를 넣습니다. ANTHROPIC_DEFAULT_OPUS_MODEL·ANTHROPIC_DEFAULT_SONNET_MODEL·ANTHROPIC_DEFAULT_HAIKU_MODEL·ANTHROPIC_DEFAULT_FABLE_MODEL은 Claude Code의 각 등급을 실제 실행할 모델에 대응시킵니다. 각 변수가 독립되어 있으므로 모든 등급에 같은 GPT 모델을 넣을 수도 있고, 등급마다 서로 다른 모델이나 공급자를 배정할 수도 있습니다. 서브에이전트용 모델 역시 별도 환경변수로 지정할 수 있으며, 셸 설정을 다시 불러온 뒤 별칭을 실행하면 Claude Code가 지정 모델로 시작합니다.
6. 모델 조회와 여러 클라이언트의 구분
환경변수에 넣을 정확한 모델명이 불분명하면 프록시가 제공하는 OpenAI 호환 /v1/models 엔드포인트를 조회할 수 있습니다. 요청의 Authorization 헤더에는 Claude Code에 설정한 것과 같은 프록시 API 키를 전달하며, 반환값은 jq로 정리해 읽을 수 있다고 글은 안내합니다. 모델 목록을 직접 조회하는 절차는 공급자별 명칭을 추정해서 입력하는 대신 현재 프록시가 실제로 노출하는 식별자를 확인하게 해줍니다. CLI Proxy는 Claude Code뿐 아니라 Codex·Factory Droid·OpenCode용 클라이언트 구성 문서도 제공합니다. 여러 클라이언트를 같은 프록시에 연결할 때는 api-keys 목록에서 서로 다른 키를 하나씩 할당하면 로그와 할당량 추적에서 각 클라이언트를 구분할 수 있습니다.
7. API 변환과 인증 처리 원리
Claude Code와 OpenAI 계열 CLI는 비슷한 프롬프트를 보내더라도 서로 다른 API 요청·응답 형식을 사용하므로, 한쪽의 응답을 다른 쪽이 그대로 해석할 수 없습니다. CLI Proxy는 중간에서 Claude Code의 요청을 대상 공급자가 이해하는 형식으로 바꾸고, 공급자의 응답을 다시 Claude Code가 읽을 수 있는 Anthropic 형식으로 변환합니다. 이 변환이 애플리케이션 기능이 아니라 API 계층에서 이뤄지기 때문에 추론 강도, 서브에이전트, 스킬, 계획 모드와 같은 상위 작업 흐름이 유지된다는 것이 글의 설명입니다. 인증에서도 Claude Code가 보내는 프록시용 키와 공급자가 발급한 실제 OAuth 토큰을 분리합니다. 프록시는 자체 키를 검증한 뒤 auth-dir에 저장한 공급자 토큰으로 실제 요청을 보내므로, 서로 교환할 수 없는 공급자별 토큰을 Claude Code가 직접 처리할 필요가 없습니다.
8. 다중 계정 운용, 시연 결과와 제한 사항
프록시가 실제 OAuth 자격 증명을 보유하므로 같은 공급자의 여러 계정 가운데 요청마다 사용할 토큰을 선택할 수 있습니다. 기본 전략은 계정을 순서대로 사용하는 라운드로빈이며, 한 계정을 먼저 소진한 뒤 다음 계정으로 이동하는 fill-first와 대화를 특정 자격 증명에 묶는 선택적 세션 고정 기능도 소개됩니다. 글의 시연에서는 Firecrawl 검색 API로 최신 정보를 조사해 Anthropic 스타일의 HTML 상태 페이지를 만들었지만, 결과물은 데모일 뿐 사실 검증된 참고 자료가 아니라고 명시합니다. 해당 실행은 주간 구독 한도의 11%를 사용했고 Claude Code가 더 높은 컨텍스트 수치를 표시했는데, 글은 이를 실제 사용량이 아닌 표시 오류라고 설명합니다. Kimi·GLM이나 cc-mirror 같은 기존 방식은 대체로 한 공급자에 고정되는 반면 CLI Proxy는 등급별 조합을 지원하지만, Anthropic OAuth로 Claude 구독을 Codex 같은 다른 CLI에서 사용하는 역방향 구성은 이용약관에 어긋날 수 있으므로 권장하지 않습니다.
🧾 핵심 주장 / 시사점
- CLI Proxy의 실질적 가치는 특정 모델 자체보다 API 호환 계층에 있으며, 이 계층이 Claude Code의 사용자 경험과 모델 공급자 선택을 분리합니다.
- 클라이언트용 API 키를 각각 나누면 접근 검증뿐 아니라 로그와 할당량을 클라이언트별로 식별할 수 있어, 하나의 프록시를 여러 도구가 공유할 때 관리 기준이 명확해집니다.
- 다중 OAuth 계정 순환은 구독 한도 활용 범위를 넓히지만, 기술적으로 가능한 연결 방향이 모두 이용약관상 허용되는 것은 아니므로 공급자와 사용 방향을 구분해야 합니다.
✅ 액션 아이템
- Claude Code의 ANTHROPIC_BASE_URL과 AUTH_TOKEN을 localhost:8317과 프록시 api-key로 맞춰 비Claude 모델 연결을 점검한다.
- Opus·Sonnet·Haiku·Fable 등급별 환경변수에 GPT·Gemini·Grok 계열 모델 매핑을 정의하고 /v1/models로 이름을 확인한다.
- 공급자별 OAuth 다중 자격 증명과 라운드로빈 순환은 유지하되, Claude 구독 역방향 사용은 약관 리스크로 제외한다.
❓ 열린 질문
- 등급별 매핑에서 추론 강도·스킬·서브에이전트·계획 모드를 가장 안정적으로 유지하는 모델 조합은 무엇인가?
- secret-key와 api-keys를 어떻게 분리·관리해야 클라이언트 검증과 관리 화면 접근 보안을 동시에 충족하는가?
- 다중 OAuth 계정 라운드로빈이 기존 구독 한도 소진과 요청 실패를 줄이는 기준은 어떻게 판단할 것인가?