Cursor Ultra 한도 점검: 사용량 풀, 온디맨드, 지출 상한

매달 200달러를 내고 Cursor Ultra를 사용해도 한도에 가까워졌다는 경고가 나타날 수 있습니다. 이때 가장 비싼 실수는 모든 퍼센트를 하나의 공용 한도로 보고 곧바로 Spending을 No Limit으로 바꾸는 것입니다. 먼저 어느 카운터가 증가하는지 확인하고, 작업을 중단하지 않는 가치가 추가 비용보다 큰지 판단한 다음, 감당할 수 있는 월간 지출 상한을 설정해야 합니다.

핵심 결론: Ultra에는 하나의 통합 사용량 게이지가 없다

2026년 9월 27일 기준 Cursor는 Pro, Pro Plus, Ultra에 서로 분리된 두 사용량 풀이 있으며, 각각 월간 결제 주기에 맞춰 초기화된다고 설명합니다. 바로 Cursor Models와 Other Models입니다. Ultra의 표시 가격은 월 200달러이고 두 풀을 모두 포함하지만, 선택한 모델에 따라 포함 사용량이 소진되는 속도는 달라집니다.

• Cursor Models에는 현재 Grok 4.7, Grok 4.6, Grok 4.5, Composer 2.5가 포함됩니다. Cursor는 이 풀에 훨씬 많은 포함 사용량이 제공된다고 설명합니다.
• Other Models는 사용자가 명시적으로 선택한 서드파티 모델용입니다. 각 모델의 API 가격에 따라 사용량이 계산됩니다.

따라서 “Ultra를 80% 사용했다”는 말만으로는 원인을 진단할 수 없습니다. Cursor Models가 줄고 있는지, Other Models가 줄고 있는지, 아니면 특정 기능의 주간 한도 경고인지 나눠서 확인해야 합니다.

예를 들어 X에 사용자가 올린 스크린샷에는 Cursor Models 월간 사용량 72%와 Grok Bot 주간 한도 90%가 동시에 표시됐습니다. 두 수치는 서로 다른 카운터입니다. Grok Bot의 주간 경고만으로 Ultra의 두 월간 모델 풀이 소진됐다고 판단할 수 없습니다.

플랜이나 결제를 바꾸기 전에 어느 카운터가 움직이는지 확인한다

남은 토큰을 추측하는 것보다 경고가 나온 위치, 선택한 모델, 결제 내역을 맞춰 보는 편이 훨씬 정확합니다.

보이는 신호	보통 의미하는 것	다음 조치
Cursor Models 퍼센트가 올라간다	Grok 또는 Composer가 Cursor Models 풀을 소비한다	Other Models에 여유가 있는지, 모델 변경이 작업에 맞는지 확인한다
Other Models 퍼센트가 올라간다	선택한 서드파티 모델이 자체 API 가격 기준으로 사용량을 소비한다	비싼 모델, 긴 컨텍스트, 잦은 Agent 작업을 확인한다
Grok Bot에 주간 경고가 나온다	해당 Bot 기능의 주간 한도가 초기화 시점에 가까워졌다	주간 초기화를 기다리거나 그 기능의 사용을 줄이고, 월간 Ultra 소진으로 해석하지 않는다
Included Usage와 On-Demand Usage가 따로 보인다	포함 사용량과 추가 종량 사용량이 별도 결제 항목으로 기록된다	온디맨드 활성화 여부와 지출 상한을 확인한다

3분 안에 검증 가능한 진단 절차

1. Cursor 에디터 설정 또는 usage dashboard를 열고 Cursor Models와 Other Models의 퍼센트, 월간 초기화 날짜를 기록합니다. Cursor는 두 풀이 모두 이 위치에 표시된다고 안내합니다.
2. 최근의 무거운 작업으로 돌아가 실제로 선택했던 모델을 확인합니다. 모델마다 포함 사용량을 소모하는 속도가 다르므로 요청 횟수만으로 비용을 판단할 수 없습니다.
3. Billing & Invoices에서 Included Usage와 On-Demand Usage를 비교합니다. 후자에 이미 금액이 표시된다면 구독에 포함된 범위를 넘어 추가 비용이 발생 중입니다.
4. Spending을 열어 온디맨드가 켜져 있는지, 현재 월간 한도가 얼마인지, No Limit으로 설정됐는지 확인합니다.
5. 단일 파일 리팩터링처럼 범위가 명확한 작은 작업을 하나 실행한 뒤 어느 풀 또는 결제 항목이 변했는지 다시 확인합니다.

팝업 문구가 모호하다면 본인 dashboard의 두 풀과 결제 항목을 기준으로 판단하세요. 스크린샷, 채팅 답변, 단일 배너는 계정의 실시간 데이터보다 우선할 수 없습니다.

온디맨드 사용이 합리적인 경우

온디맨드는 작업 중단을 피하는 가치가 감당 가능한 추가 비용보다 클 때만 합리적입니다. Cursor의 usage-based charges 문서에 따르면 개인 사용자는 온디맨드를 명시적으로 활성화해야 하며, 포함 사용량을 넘긴 요청은 API 가격으로 과금되고 구독료와 별도로 표시됩니다.

다음 세 조건을 모두 충족한다면 활성화를 고려할 만합니다.

• 출시, 수정, 마이그레이션에 명확한 마감이 있고 지연 비용을 추정할 수 있다.
• 남은 작업이 코드 리뷰 두 건이나 특정 모듈 하나처럼 경계가 분명하고, 끝이 없는 Agent 루프가 아니다.
• 무거운 작업이 끝날 때마다 사용량을 확인하고 예산에 도달하면 멈출 수 있다.

반대로 다음 상황에서는 우선 꺼 두는 편이 안전합니다.

• 어느 풀이 소비되는지 아직 확인하지 못했다.
• 여러 Agent, 자동화, 긴 컨텍스트 작업이 병렬로 실행돼 비용 예측이 어렵다.
• 개인 예산에 넘을 수 없는 한도가 있거나 다음 결제 주기까지 작업을 미룰 수 있다.
• 다른 포함 풀이 아직 남아 있고 현재 작업에 적합한 모델이 있다.

온디맨드를 켠다고 모델 사용이 “무제한”으로 돌아오는 것은 아닙니다. 포함 사용량 이후에도 종량 과금을 받아들이고 작업을 이어가는 설정입니다. 연속성은 해결하지만 비용 통제까지 자동으로 해결하지는 않습니다.

추측 없이 지출 상한을 정하는 방법

가장 안전한 상한은 플랫폼이 추천한다고 가정한 숫자가 아니라, 현재 결제 주기에 추가로 지불할 의사가 있는 최대 금액입니다. 온디맨드를 켜면 dashboard의 Spending에서 개인 월간 한도를 설정할 수 있습니다. Cursor의 지출 상한 문서는 No Limit을 선택하면 상한이 제거된다고 명시합니다.

첫 상한은 다음 방식으로 정하세요.

1. 단순히 남은 날짜가 아니라 이번 결제 주기에 예정된 무거운 개발 세션 수를 셉니다.
2. 감당 가능한 추가 총액을 정합니다.
3. 그 금액을 남은 무거운 세션 수로 나눠 검토 기준을 만듭니다.
4. Cursor에는 월간 총 상한을 설정하고, 매 세션 후 실제 사용량을 검토 기준과 비교합니다.

예를 들어 추가 비용을 최대 40달러까지 허용하고 초기화 전에 무거운 Agent 세션이 10번 남았다면, 세션당 4달러를 수동 검토 기준으로 사용할 수 있습니다. 이는 Cursor의 세션별 한도나 가격 보장이 아니라, 비정상적으로 비싼 작업을 조기에 찾기 위한 경고선입니다.

지출 상한 적용에는 두 가지 주의점이 있다

첫째, 한도 변경은 즉시 반영되지만 차단 집행은 순간적으로 이뤄지지 않습니다. Cursor는 시스템이 상한 도달을 인식하기 전에 사용량이 잠시 한도를 넘을 수 있다고 설명합니다. 집행 전의 제한적인 초과분은 임시 spend-limit credit으로 처리되고, 청구는 현재 한도까지로 제한됩니다.

둘째, 같은 결제 주기 안에서 한도를 올리면 Cursor가 이전에 credit 처리한 일부 또는 전부를 새 한도까지 청구할 수 있습니다. credit을 유지하려면 기존 한도를 그대로 두거나 온디맨드를 끄세요.

1인 개발자에게는 대개 No Limit보다 유한한 상한이 안전합니다. 남은 주기 동안 이 통제 장치로 제한되지 않는 추가 지출을 명확히 받아들이고, 청구 내역을 계속 모니터링할 때만 상한을 제거하는 편이 좋습니다.

계속 결제할지, 개발 워크플로를 바꿀지 결정하는 법

결정은 어느 풀이 줄고 있는지, 작업이 얼마나 긴급한지, 이런 소비가 일회성인지 매달 반복되는지에 따라 달라집니다.

현재 상황	우선할 행동	이유
Cursor Models가 거의 소진됐고 Other Models에는 여유가 있다	적합한 어려운 작업만 서드파티 모델로 옮기고, 일상 작업은 Cursor Models에 남긴다	두 번째 풀을 활용할 수 있지만 서드파티 모델은 자체 API 가격으로 소비된다
Other Models가 거의 소진됐고 Cursor Models에는 여유가 있다	일상 코딩, 재작성, 탐색을 Grok 또는 Composer로 옮긴다	남은 포함 풀을 쓰고 비싼 모델은 정말 필요한 작업에 남길 수 있다
두 풀이 모두 한도에 가깝고 짧은 마감 작업 하나가 남았다	유한한 월간 상한과 함께 온디맨드를 켠다	연속 작업의 가치가 분명하고 비용 위험에 경계를 만들 수 있다
매달 초 두 풀이 빨리 줄고 병렬 Agent나 자동화를 자주 사용한다	병렬 수를 줄이고 컨텍스트를 짧게 하며 한 주기 동안 작업을 묶어 실행한다	반복되는 워크플로 문제는 한 번의 상한 인상만으로 해결되기 어렵다
대부분 자동 완성, 기계적 수정, 로컬 편집이다	Tab과 작은 범위의 작업을 우선한다	Ultra에는 unlimited Tab completions가 포함되므로 Agent를 복잡한 판단에 남길 수 있다

같은 공식 페이지에서 Cursor는 대략적인 사용 가이드도 제시합니다. 매일 Tab을 쓰는 사용자는 보통 포함 사용량 안에 머물고, Agent를 제한적으로 쓰는 사용자도 대체로 그렇습니다. 매일 Agent를 쓰는 사용자는 월 60~100달러의 총사용량을 만드는 경우가 많고, 여러 Agent나 자동화를 쓰는 파워 유저는 월 200달러 이상인 경우가 많다고 설명합니다. 이는 넓은 사용자 유형이지 개인 청구서 예측이 아닙니다. 실제 온디맨드 비용은 모델, 토큰 수, 컨텍스트 길이, 작업 방식에 따라 달라집니다.

이미 낸 200달러가 아니라 작업 가치로 판단한다

Ultra 구독료는 이미 지출된 비용입니다. 그것만을 이유로 추가 종량 과금을 계속해서는 안 됩니다. 무거운 작업마다 다음 세 질문을 하세요.

1. 지금 완료하면 얼마나 많은 수작업 시간 또는 지연 비용을 줄일 수 있는가?
2. 다른 포함 풀의 모델이 받아들일 수 없는 품질 저하 없이 작업할 수 있는가?
3. 추가 유료 시도에도 작업이 끝나지 않으면 어느 금액에서 멈출 것인가?

세 답이 모두 명확하면 상한이 있는 온디맨드가 갑작스러운 중단보다 합리적일 수 있습니다. 세 번째 답이 없다면 먼저 워크플로를 바꾸는 편이 안전합니다.

오늘 바로 적용할 실행 순서

진단보다 결제가 먼저 시작되지 않도록 다음 순서를 지키세요.

1. 경고의 출처를 확인한다: Cursor Models, Other Models, Grok Bot, 결제 페이지 중 어디인지 구분한다.
2. 두 월간 풀을 기록한다: 퍼센트와 초기화 날짜를 저장하고 하나의 통합 수치처럼 보지 않는다.
3. 모델과 작업을 연결한다: 최근 무거운 작업의 선택 모델, 병렬 Agent, 긴 컨텍스트를 찾는다.
4. 결제 분류를 확인한다: Included Usage와 On-Demand Usage가 이미 따로 증가하는지 본다.
5. 스위치보다 예산을 먼저 정한다: 이번 주기의 최대 추가 금액을 결정하고 유한한 상한으로 온디맨드를 켠다.
6. 범위가 작은 테스트를 한다: 명확한 작업 하나를 끝낸 뒤 두 풀과 결제를 다시 확인한다.
7. 검토 후에만 확대한다: 결과와 소비가 모두 수용 가능할 때만 작업 크기나 상한을 올린다.

성공은 경고가 사라지는 것만을 뜻하지 않습니다. 어느 풀이 소비되는지, 추가 비용이 왜 증가하는지, 어느 금액에서 작업을 멈춰야 하는지 설명할 수 있어야 합니다.

Cursor Ultra 한도에 대한 자주 묻는 질문

Grok Bot이 90%면 Ultra도 거의 다 쓴 것인가요?

반드시 그렇지는 않습니다. Grok Bot의 주간 한도와 Cursor Models 및 Other Models의 월간 풀은 서로 다른 카운터입니다. Ultra의 포함 사용량이 거의 소진됐다고 결론 내리기 전에 usage dashboard에서 두 풀을 모두 확인하세요.

No Limit은 Cursor를 무제한으로 만든다는 뜻인가요?

아닙니다. No Limit은 온디맨드 지출의 월간 상한만 제거합니다. 포함 사용량을 넘긴 요청은 해당 요율로 계속 청구됩니다. Ultra의 unlimited Tab completions 역시 모든 Agent 또는 모델 요청이 무료이면서 무제한이라는 의미가 아닙니다.

지출 상한에 도달한 뒤에도 사용량이 늘 수 있나요?

Cursor는 집행이 즉시 이뤄지지 않기 때문에 잠깐의 초과가 가능하다고 설명합니다. 제한적인 초과분은 임시 credit으로 처리되고 현재 한도까지 청구됩니다. 같은 주기에 상한을 높이면 그 credit의 일부 또는 전부가 새 한도까지 청구 대상이 될 수 있습니다.

사용한 퍼센트만으로 남은 작업량을 계산할 수 있나요?

신뢰성 있게 계산하기 어렵습니다. 모델의 API 가격, 컨텍스트 길이, 출력 길이, 병렬 실행이 소비를 바꿉니다. 작은 범위의 작업을 하나 실행한 뒤 dashboard 변화를 확인하는 편이 더 유용합니다.

기억할 결정 원칙

종량 사용을 켜기 전에 풀을 확인하고, 한도를 올리기 전에 예산을 정하세요. Cursor를 많이 쓰는 1인 개발자에게 가장 통제하기 쉬운 기본값은 유한한 상한, 가치가 높은 작업을 알맞은 풀에 배치하는 것, 비싼 작업 뒤마다 사용량을 검토하는 것입니다. 처음부터 No Limit으로 바꾸는 것이 아닙니다.