2026 Cursor OpenAI o1 청구서 이상? 먼저 실제 호출 경로를 확인하세요

Cursor에서는 OpenAI o1을 골랐고 LiteLLM에는 대체 경로가 찍히는데, OpenAI 청구서는 계속 늘어나는 상황이 발생합니다.
가장 빠른 해결책은 로컬 모델을 바로 늘리는 것이 아니라 Cursor, 게이트웨이, 모델 공급자의 호출 기록을 먼저 연결해 실제 모델과 반복 요청을 확정하는 것입니다.

이번 주 권장 순서: 첫째 날에는 모델 식별과 키를 대조하고, 둘째 날에는 추론 사용량과 재시도를 확인하며, 셋째 날에는 Qwen3-Coder의 세 가지 분기 경로를 재현합니다. 원인이 확인되기 전에는 상시 장비나 추가 클라우드 자원을 구매하지 않는 편이 안전합니다.

이 글은 Cursor, 모델 공급자, 게이트웨이의 비용을 함께 감사하는 팀 관리자에게 적합합니다. LiteLLM 라우팅과 로그를 관리하는 플랫폼 엔지니어, Qwen3-Coder로 일반 코딩 요청을 맡기려는 기술 책임자도 대상입니다.

최신 확인 범위

이 글은 2026년 9월 17일에 마지막으로 확인했습니다. 모델 지원 범위는 Cursor의 자체 API 키 문서, 모델 동작과 사용 방식은 Cursor 모델 문서, 사용량 필드는 OpenAI의 사용량 API 문서와 Responses API의 추론 사용량 문서를 기준으로 대조했습니다.

현재 Cursor의 자체 키 문서는 OpenAI 지원 범위를 표준 비추론 채팅 모델로 설명합니다. 따라서 Cursor 화면에 OpenAI o1이 표시된다는 사실만으로 Cursor가 자체 키를 통해 o1을 직접 호출한다고 결론 내리면 안 됩니다. 별도 프록시, 호환 인터페이스, 모델 별칭, 전체 Base URL 설정이 실제 경로를 바꿀 수 있습니다.

OpenAI의 o1 자료에는 추론 토큰이 별도 사용량으로 다뤄집니다. 반면 커뮤니티의 특정 프록시 호환성 제보는 개별 사례일 뿐입니다. 중계 계층에서 추론 필드가 잘리거나 이름이 바뀌는 문제를 일반적인 사실로 확대하지 말고, 해당 요청의 원본 기록으로만 판단해야 합니다.

호출 경계와 증거 묶음

세 기록은 서로 다른 사실을 보여줍니다.

• Cursor 기록은 사용자가 고른 모델, 에이전트 단계, 도구 호출과 클라이언트 쪽 오류를 보여줍니다.
• LiteLLM 기록은 게이트웨이가 받은 요청, 선택한 별칭, 재시도, 대체 경로와 가상 키를 보여줍니다.
• OpenAI API 기록은 공급자 측에서 실제 처리된 모델과 사용량을 보여줍니다.

따라서 세 계층의 숫자를 그대로 더하면 안 됩니다. 같은 요청이 Cursor에서 한 번 보이고, 게이트웨이에서 재시도와 대체 요청으로 여러 번 기록될 수 있기 때문입니다. LiteLLM 공식 문서도 통합 인터페이스, 재시도, 대체 경로와 비용 추적 기능을 설명하지만, 이 기능이 작업 난도를 자동으로 이해하는 분류기라는 뜻은 아닙니다.

최소한 다음 연결 키를 보존해야 합니다.

1. 요청 시작 시각과 종료 시각
2. Cursor가 만든 요청 ID 또는 상관 ID
3. 가상 키와 팀 식별자
4. Cursor의 모델 표시 이름
5. LiteLLM의 모델 별칭과 최종 배포 이름
6. 상태 코드, 재시도 원인, 최종 공급자 응답

예를 들어 아래와 같이 민감한 내용은 제거하고 구조만 남깁니다.

time=2026-09-17T09:14:22Z
source=cursor
model_label=openai-o1
correlation_id=req_redacted_41
virtual_key=team_redacted_a

gateway_model=reasoning-route
deployment=local-qwen-redacted
attempt=1
status=504
fallback=openai-o1
attempt=2

provider_model=o1
usage.prompt_tokens=redacted
usage.cached_input_tokens=redacted
usage.output_tokens=redacted
usage.reasoning_tokens=redacted

상관 ID가 Cursor와 게이트웨이 사이에서 사라졌거나 공급자 기록에 연결되지 않으면, 해당 기간의 증가 추세만 말할 수 있습니다. 특정 사용자 작업이 OpenAI o1 비용을 만들었다고 단정할 수는 없습니다.

모델 신원과 사용량 판독

화면 이름의 한계

Cursor에서 OpenAI o1을 선택했어도 다음 경우에는 실제 처리 모델이 달라질 수 있습니다.

• 자체 키가 아니라 전체 Base URL이 지정된 경우
• 프록시가 openai-o1을 다른 배포 이름으로 재작성한 경우
• LiteLLM의 model_name과 실제 배포가 분리된 경우
• 여러 공급자가 같은 별칭을 공유하는 경우
• 로컬 건강 검사 실패 뒤 대체 경로가 실행된 경우

감사할 때는 화면 이름보다 게이트웨이의 최종 배포 이름과 공급자 기록을 우선합니다. 모델 별칭이 같더라도 실제 모델, 키, 지역과 사용량 기록이 같다는 보장은 없습니다.

추론 토큰의 계산 경계

OpenAI o1의 비용을 화면에 보이는 답변 길이로 추정하면 안 됩니다. 입력 토큰, 캐시 입력 토큰, 출력 토큰과 추론 관련 사용량은 서로 다른 필드로 관리될 수 있으며, 정확한 필드명은 사용한 API와 응답 형식에 따라 확인해야 합니다. OpenAI o1 모델 자료와 Responses API 사용량 필드를 기준으로 원본 응답을 확인합니다.

프록시 로그에서 reasoning_tokens가 누락됐다고 해서 답변 길이와 입력 길이로 나머지를 계산해서는 안 됩니다. 필드가 잘렸는지, 이름이 바뀌었는지, 게이트웨이가 집계해서 숨겼는지 확인할 수 없기 때문입니다. 이 경우의 판정은 비용 확정이 아니라 사용량 호환성 미확인입니다.

재시도와 대체 경로의 누수

한 번의 사용자 작업이 한 번의 공급자 요청만 만든다고 가정하면 안 됩니다. Cursor Agent가 여러 단계에서 도구를 호출하고, 도구 결과가 불완전해 다시 요청하며, 게이트웨이가 시간 초과 뒤 재시도할 수 있습니다. 여기에 로컬 모델 실패 뒤 OpenAI o1 대체 요청까지 발생하면 최종 답변이 성공해도 클라우드 요청은 증가합니다.

다만 일반적인 대체 경로를 지능형 작업 분류라고 표현하면 안 됩니다. LiteLLM은 설정된 오류 조건에 따라 재시도와 대체를 수행합니다. 작업이 단순한지 복잡한지를 스스로 판단해 모델을 고르는 기능과는 다릅니다.

다음 순서로 한 작업의 호출 체인을 복원합니다.

1. Cursor에서 작업 시작 시각과 에이전트 단계 ID를 기록합니다.
2. LiteLLM에서 같은 시간대의 상관 ID와 가상 키를 찾습니다.
3. 첫 요청의 모델 별칭, 실제 배포, 상태 코드를 확인합니다.
4. 재시도마다 원인과 대상 모델이 바뀌었는지 기록합니다.
5. 공급자 기록에서 실제 처리 모델과 사용량을 대조합니다.
6. 마지막 답변의 성공 여부와 별개로 모든 시도를 한 행으로 정리합니다.

HTTP 429나 5xx 같은 상태 코드가 보인다는 사실만으로 원인을 확정하지도 않습니다. 시간 초과 설정, 공급자 응답, 네트워크 계층 로그를 함께 확인해야 합니다. 핵심은 같은 작업을 시간, 상태 코드, 재시도 원인과 대상 모델로 연결하는 것입니다.

Qwen3-Coder 분기 누수

Qwen3-Coder를 일반 코딩 요청에 사용하려면 로컬 응답이 성공했다는 결과만으로는 부족합니다. 모델 별칭이 정확한지, 로컬 엔드포인트의 건강 상태가 정상인지, 컨텍스트 형식이 호환되는지, 시간 초과가 너무 짧지 않은지를 따로 검증해야 합니다. Qwen3-Coder 공식 소개는 모델의 용도와 인터페이스 정보를 제공하지만, 특정 팀의 게이트웨이 설정이 올바르다는 증거는 아닙니다.

반드시 다음 세 경로를 각각 실행합니다.

• 로컬 적중: 일반 코드 수정 작업을 보내고 최종 배포 이름이 Qwen3-Coder인지 확인합니다.
• 명시적 승격: 복잡한 추론이 필요한 테스트에서 OpenAI o1을 직접 지정하고 해당 경로가 기록되는지 확인합니다.
• 로컬 실패 후 대체: 로컬 엔드포인트를 통제된 테스트 조건에서 실패시키고, 대체 요청의 원인과 대상 모델을 확인합니다.

첫 번째 경로의 답변이 정상이어도 두 번째나 세 번째 경로가 백그라운드에서 추가로 실행될 수 있습니다. 따라서 화면의 최종 답변만 검사하면 비용 누수를 놓칩니다.

주간 판정 조건

다음 조건 목록으로 조치 방향을 정합니다.

• 모델 별칭과 최종 배포 이름이 모두 일치하고, 세 계층의 요청 ID가 연결되면 현재 라우팅을 유지합니다.
• 일반 작업이 Qwen3-Coder에 도달하지만 실패 뒤 OpenAI o1로 넘어가는 이유가 로그에 남지 않으면 라우팅 규칙을 조정합니다.
• 공급자 사용량에 추론 필드가 있으나 게이트웨이에서 사라지면 사용량 보존 설정을 먼저 수정합니다.
• 같은 작업에서 Cursor 재실행과 게이트웨이 재시도가 함께 발생하면 재시도 횟수와 시간 초과 조건을 분리해 조정합니다.
• 상관 ID, 모델 식별자, 사용량 필드가 계속 누락되면 프록시를 일시 중단하고 직접 연결 또는 검증된 구성을 검토합니다.
• 로컬 노드가 안정적으로 응답하고 품질 저하가 없으면 추가 장비를 늘리지 않습니다.
• 로컬 노드의 안정성만 병목으로 확인되면 그때 상시 장비와 탄력형 맥 컴퓨팅을 비교합니다.

세 경로의 합격 기준

감사 항목별 판단 점수

자주 확인하는 항목

Cursor가 API 프록시를 거친 뒤 실제로 어떤 모델을 호출했는지 확인하는 방법

Cursor 화면의 모델 이름만 보지 말고 요청 시간, 요청 ID, 가상 키, 게이트웨이의 모델 별칭, 최종 공급자 응답을 같은 기록으로 묶어야 합니다. LiteLLM 로그의 실제 배포 이름과 공급자 사용량 기록이 연결되지 않으면 추세만 확인할 수 있으며, 특정 요청의 모델을 단정해서는 안 됩니다.

LiteLLM 대체 경로가 일반 작업을 OpenAI o1로 보내는 이유

대체 경로는 보통 연결 실패, 시간 초과, 상태 코드, 사용량 제한 같은 오류를 처리하기 위한 기능입니다. 작업 난도를 자동 판정하는 분류기가 아닙니다. 기본 모델 별칭이 OpenAI o1로 설정됐거나 로컬 엔드포인트의 건강 검사가 실패하면 일반 코딩 요청도 대체 경로로 이동할 수 있으므로 원인과 상태 코드를 함께 확인해야 합니다.

OpenAI o1 추론 토큰을 게이트웨이 로그와 대조하는 방법

답변의 길이로 비용을 계산하지 않습니다. OpenAI API의 사용량 기록에서 입력, 캐시 입력, 출력과 추론 관련 필드를 확인하고, 같은 요청 ID와 시간의 LiteLLM 기록에 해당 값이 보존됐는지 비교합니다. 필드가 잘리거나 이름이 바뀌었으면 누락분을 임의로 계산하지 말고 호환성 미확인으로 표시해야 합니다.

로컬 Qwen3-Coder가 정상 응답해도 클라우드 비용이 늘어나는 이유

최종 답변이 성공했다는 사실은 로컬 모델만 사용했다는 뜻이 아닙니다. Cursor의 여러 에이전트 단계, 도구 호출 재시도, 로컬 요청 시간 초과 뒤의 대체 요청이 모두 클라우드 비용을 만들 수 있습니다. 로컬 성공, 명시적 OpenAI o1 전환, 로컬 실패 뒤 대체 전환을 각각 별도 테스트하고 세 경로를 로그에서 복원해야 합니다.

다음 선택

현재 방식은 화면 이름과 최종 답변만으로 비용을 판단한다는 약점이 있습니다. 모델 별칭이 실제 배포를 가리고, 공용 키가 팀별 사용량을 섞으며, 로컬 실패와 게이트웨이 재시도가 OpenAI o1 요청을 늘릴 수 있습니다. 반대로 JexMac의 맥 환경을 임시 검증 노드로 사용하면 로컬 모델의 안정성을 별도 환경에서 확인한 뒤 라우팅 결정을 내릴 수 있습니다.

먼저 JexMac의 도움말과 운영 안내에서 환경 확인 절차를 살펴보시기 바랍니다. 호출 체인 감사가 끝난 뒤에도 로컬 노드의 안정성이 병목으로 남고 단기간 테스트 환경이 필요하다면 JexMac의 이용 요금 안내를 비교 대상으로 삼을 수 있습니다. 장기 고정 부하나 물리 장치 연결이 필요한 팀에는 직접 장비를 운영하는 편이 나을 수 있지만, 원인이 확인되지 않은 상태에서 확장하는 것보다 검증 가능한 맥 렌탈 환경으로 먼저 재현하는 편이 비용 판단에 유리합니다.

자주 묻는 질문