Claude usage limit: Ano ang gagawin kapag naabot ito

Ano ang mga limitasyon sa paggamit ng Claude?

May dalawang magkahiwalay na sistema ang mga limitasyon sa paggamit ng Claude. Ang unang hakbang ay tukuyin kung alin sa mga ito ang pumigil sa iyo. Ang Claude subscription (Pro, Max, Team, o Enterprise) ay nagbibigay ng rolling usage allowance na pinagsasaluhan ng mga model at ng Claude chat. Kapag naabot mo ito, makakakita ka ng mensaheng gaya ng You've hit your session limit · resets 3:45pm. Iba naman ang sinusukat ng Claude API: kung gaano kabilis kang nagpapadala ng mga request at token, na binibilang bawat minuto. Kapag lumampas ka rito, magbabalik ito ng HTTP 429 error na may type na rate_limit_error at retry-after header na nagsasaad kung ilang segundo ang dapat hintayin.

Magkaiba nang lubos ang paraan ng pag-aayos sa mga ito. Ang subscription limit ay nakabatay sa dami ng nagamit mo sa loob ng isang window. Hintayin ang reset o bumili ng karagdagang usage. Ang API rate limit naman ay nakabatay sa bilis ng pagpapadala mo sa kasalukuyan. Karaniwan itong nawawala pagkalipas ng ilang segundo kapag binawasan mo ang bilis.

Madalas magbago ang plan allowance at mga numero ng rate-limit tier. Mas masama ang maling numero kaysa sa walang numero, kaya walang inilista rito. Basahin ang sarili mong limit gamit ang mga command sa ibaba.

Aling limit ang naabot mo? Basahin ang eksaktong mensahe

Inilalagay ng Claude Code sa naka-print nitong text ang pangalan ng system. Itugma ito sa iyong system bago ka magbago ng anuman.

• You've hit your session limit · resets 3:45pm ay limitasyon ng subscription. Naubos na ang rolling allowance ng iyong plan para sa window na ito.
• You've hit your weekly limit · resets Mon 12:00am ay kaparehong system sa mas mahabang window.
• You've hit your Opus limit · resets 3:45pm ay limitasyon ng subscription na para lamang sa mga request sa Opus. Ito ang tanging sitwasyon kung kailan makatutulong ang paglipat ng model.
• API Error: Request rejected (429) · this may be a temporary capacity issue. If it persists, check https://status.claude.com. ay API rate limit. Naabot mo ang limitasyong naka-configure para sa iyong API key, o para sa iyong Amazon Bedrock o Google Cloud project. Alin dito ang naaangkop ay depende sa kung paano nag-a-authenticate ang client, dahil ang Bedrock o Vertex client ay sinusukat laban sa quota ng iyong cloud project sa halip na sa isang Anthropic organization.
• API Error: Server is temporarily limiting requests (not your usage limit) ay panandaliang throttle na walang kaugnayan sa quota ng iyong plan. Awtomatikong nire-retry ito ng Claude Code na may backoff bago nito ipakita sa iyo ang linyang iyon.

Mga limitasyon ng subscription: session, lingguhan, at window ng Opus

May rolling usage allowance ang isang subscription plan. Kapag naubos ito, bina-block ni Claude Code ang mga susunod na request hanggang sa reset time na nakasaad sa mensahe. Dalawang property ng allowance na ito ang karaniwang sanhi ng kalituhan.

• Shared ito sa Claude chat. Ang mga ginagawa mo sa claude.ai ay ibinabawas sa parehong allowance na ginagamit sa terminal. Kaya kapag matindi ang paggamit mo sa chat sa hapon, mas maikli ang oras na magagamit mo sa coding sa gabi. Lahat ng surface na ginagamit mo para mag-sign in gamit ang account na iyon ay kumukuha sa parehong pool. Kaya sa Linux, ang beta desktop app at Claude Code CLI ay parehong gumagamit ng isang allowance, hindi tig-isa.
• Shared ito sa lahat ng model. Walang hiwalay na budget bawat model ang session at weekly limits, maliban sa Opus limit.

Sa Claude for Teams at Enterprise, ang dokumentadong setup ay per-seat allowance na nagre-reset sa rolling five-hour window at weekly window. Shared ito sa Claude chat at Cowork, at nakadepende ang laki nito sa seat tier (Standard o Premium). Sa Pro at Max, ang reset time na nakalimbag sa mensahe at ang sarili mong /usage bars ang maaasahang batayan, hindi ang numerong kinopya mula sa isang blog post. Kung pumipili ka pa ng tier, ikinukumpara sa kung aling Claude plan ang kailangan mo kung ano ang nililimitahan ng bawat isa.

Bakit hindi ibinabalik ng paglipat ng model gamit ang /model ang access

Ito ang pinakakaraniwang maling hakbang, at malinaw dito ang dokumentasyon: magkakapareho ang session at weekly limits para sa lahat ng model, kaya hindi ibinabalik ng paglipat ng model ang access. Kapag pumili ka ng mas maliit na model matapos maubos ang session window, binabago nito kung aling model ang sasagot. Hindi nito binabago kung gaano kalaking allowance ang natitira, dahil hindi naman itinakda ang allowance bawat model. Kaya walang mailalabas ang paglipat.

Ang exception ay ang Opus limit, isang limitasyong partikular talaga sa model. Kung ganito ang nakasaad sa mensahe: You've hit your Opus limit, ang tamang fix ay /model. Lumipat sa ibang model at ipagpatuloy ang trabaho, dahil mga request lang sa Opus ang na-block.

Ang pagtrato sa limit bilang bug ang ikalawang maling hakbang. Walang mababago sa pagre-reinstall o muling pag-authenticate. Bumabalik ang allowance kapag nag-reset ang window o kapag bumili ka ng usage credits.

Ano ang gagawin kapag naabot mo ang subscription limit

1. Basahin ang oras ng reset. Maikli ang session window. Ang weekly window ay hindi kailangang hintayin sa harap ng desk.
2. Kung Opus limit ito, patakbuhin ang /model at pumili ng ibang model.
3. Patakbuhin ang /usage upang makita ang mga limit ng iyong plan, ang mga bar nito, at kung kailan magre-reset ang mga ito. Alias ang /cost para sa parehong screen.
4. Patakbuhin ang /usage-credits upang magpatuloy sa pagtatrabaho lampas sa ceiling. Sa Pro at Max, binubuksan nito ang iyong billing settings. Sa Team at Enterprise, binubuksan nito ang usage settings ng iyong organization, o nagpapadala ng request sa iyong mga admin kung wala kang billing access.
5. Kung pareho mong naaabot ang limit bawat linggo, hindi angkop ang laki ng plan sa paraan ng pagtatrabaho mo. Sulit timbangin nang isang beses ang mga paraan para malampasan ang usage limit sa halip na gawin ito sa bawat reset.

Kailangan ng /usage-credits ang isang claude.ai subscription na naka-sign in sa pamamagitan ng /login. Hindi ito available sa API key authentication dahil walang plan allowance ang API key na maaaring i-extend.

May isang side effect ang usage credits na dapat mong malaman. Isang oras ang prompt cache lifetime kapag subscription ang gamit, at bumababa ito sa limang minuto kapag gumagamit ka ng credits. Dahil dito, mas maraming turn ang nagsisimula nang walang cache at tumataas ang paggamit ng Claude Code token para sa parehong trabaho.

Mga mensaheng mukhang usage limit pero hindi

Apat na Claude Code error ang naiuulat bilang usage limit, pero wala sa mga ito ang aktuwal na usage limit.

• Ang context o auto-compact warning ay hindi usage limit. Nagpi-print ang /context ng linyang gaya ng Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. kapag lumampas na ang conversation sa context window ng model. Sinu-summarize ang mas lumang history para magbakante ng space, at hindi naaapektuhan ang plan allowance mo.
• Ibig sabihin ng Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again., mismong /compact ang nag-fail dahil walang sapat na natitirang free context para maglaman ng summary na gagawin nito.
• Ibig sabihin ng Credit balance is too low, naubos na ng Console organization mo ang prepaid credits nito. Magdagdag ng credits sa platform.claude.com/settings/billing, na may auto-reload din.
• Ang API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context ay entitlement check, hindi quota na naubos. Piliin ang model variant na walang suffix na [1m], o i-set ang CLAUDE_CODE_DISABLE_1M_CONTEXT=1.

May isa pang error mula sa API. Ang 413 request_too_large ay size limit sa isang request, hindi rate limit.

Mga limitasyon sa API rate: ano talaga ang binibilang ng 429

Sinusukat ng Messages API ang tatlong bagay, nang magkahiwalay para sa bawat model class.

• requests per minute (RPM)
• input tokens per minute (ITPM)
• output tokens per minute (OTPM)

May spend limit din ang iyong organization. Iba ito: maximum na buwanang gastos para sa paggamit ng API. Kapag naabot mo ang spend cap ng iyong tier, pansamantalang hihinto ang paggamit ng API hanggang sa susunod na buwan, maliban kung humiling ka ng mas mataas na limit. Walang retry loop na makalulutas nito.

Apat na mekanismo ang tumutukoy kung kailan darating ang 429.

• Bawat model class ang may sariling limit. Hiwalay na ina-apply ang mga ito sa bawat model, kaya maaari kang gumamit ng magkakaibang model nang sabay-sabay hanggang sa kani-kanilang limit. May ilang model family na iisang bucket ang ginagamit: ang Opus rate limit ay kabuuan para sa Claude Opus 4.8, Opus 4.7, Opus 4.6 at Opus 4.5, samantalang sariling limit ang Claude Sonnet 5.
• Patuloy na napupunan ang capacity. Gumagamit ang API ng token bucket algorithm, kaya patuloy na nadaragdagan ang capacity sa halip na mag-reset sa isang takdang oras. Maaaring ipatupad ang limit na 60 requests per minute bilang isang request bawat segundo, kaya mabibigo pa rin ang 60 requests na sabay-sabay ipinadala.
• Ang uncached input lamang ang karaniwang ibinibilang sa ITPM. Ibinibilang ang input_tokens at cache_creation_input_tokens. Hindi ibinibilang ang cache_read_input_tokens sa karamihan ng Claude model; ang Claude Haiku 3.5 ang dokumentadong exception. Dahil dito, nagbibigay ang caching ng dagdag na headroom sa rate limit bukod sa discount. Sa output, hindi ibinabawas sa OTPM ang malaking max_tokens, dahil ang mga token na aktuwal na nagawa lamang ang ibinibilang ng OTPM.
• Sa organization level nakatakda ang mga limit. Maaaring bigyan ang isang workspace ng mas mababang limit, at laging nalalapat ang mga limit sa buong organization kahit lumampas sa halagang iyon ang pinagsama-samang workspace limits. Ang limit na hindi mo na-override sa isang workspace ay minamana mula sa organization; hindi ito itinuturing na unlimited.

Itinatakda ng mga tier na Start, Build, Scale at Custom ang aktuwal na mga numero. Awtomatikong ina-assign ang mga ito batay sa iyong history ng paggamit at status ng account. Maaaring magsimula ang mga bagong organization sa mas mababa sa karaniwang published limits, kaya maaaring dumating ang unang 429 nang mas maaga kaysa sa ipinapakita ng isang table. Nagti-trigger ng acceleration limits ang biglaang pagtaas ng paggamit. Nagbabalik ang mga ito ng 429 kahit nasa loob ka pa ng iyong tier, kaya unti-unting taasan ang traffic. Ang bawat published figure ay ceiling lamang: ang documented limits ay maximum na pinapayagang paggamit, hindi garantisadong minimum. Para humiling ng mas mataas na limit, gamitin ang control na "Request rate limit increase" sa Limits page ng Claude Console.

Pagbasa sa 429: retry-after, mga header, at SDK retries

Pare-pareho ang envelope ng bawat API error: isang nested na error object na naglalaman ng type at message, kasama ang top-level na request_id.

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "<names the rate limit you exceeded>"
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

Nasa mga header ang iba pang impormasyon.

• Ang retry-after ay bilang ng mga segundong dapat hintayin bago muling subukan ang request. Mabibigo ang mas maagang retry.
• Inilalarawan ng anthropic-ratelimit-requests-limit, anthropic-ratelimit-requests-remaining, at anthropic-ratelimit-requests-reset ang request budget mo.
• Ganoon din ang ginagawa ng anthropic-ratelimit-input-tokens-* at anthropic-ratelimit-output-tokens-* para sa ITPM at OTPM, gamit ang parehong suffix na limit, remaining, at reset.
• Ipinapakita ng anthropic-ratelimit-tokens-* ang mga value para sa pinakamas mahigpit na limit na kasalukuyang ipinapatupad.

Ang reset header ay mga timestamp na RFC 3339. Ni-round sa pinakamalapit na libo ang remaining token header, kaya gamitin ang mga ito bilang gauge. May sarili itong pool at sariling anthropic-fast-* header ang Fast mode. Basahin ang lahat ng ito mula sa anumang successful call:

curl -s -D - -o /dev/null https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}' \
  | grep -i 'ratelimit\|retry-after\|request-id'

May natatanging request-id header din ang bawat response, gaya ng req_018EeWyXxfu5pfWkrYcMdjWG. Lumilitaw ito bilang request_id sa mga error body at bilang _request_id sa mga response ng Python at TypeScript SDK. Isama ito kapag nakipag-ugnayan ka sa support.

Suriin muna kung kailangan mo talaga ng backoff loop bago ka gumawa nito. Awtomatikong nagre-retry ang official SDK para sa mga transient failure, kabilang ang connection error, rate limit, at 5xx server error, gamit ang exponential backoff. Dalawang beses itong ginagawa bilang default, at sinusunod ang retry-after header kapag naroon ito. Tumatanggap ang bawat client ng maximum-retries option upang baguhin o i-disable ang behavior na ito.

import anthropic

client = anthropic.Anthropic(max_retries=5)  # the SDK default is 2

try:
    msg = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "hello"}],
    )
except anthropic.RateLimitError as err:
    headers = err.response.headers
    print("still limited after retries; wait", headers.get("retry-after"), "seconds")
    print("request id:", headers.get("request-id"))

529 overloaded_error ay hindi iyong kasalanan

Ipinapahiwatig ng 429 na masyado kang mabilis nagpadala ng mga request. Ipinapahiwatig ng 529 overloaded_error na pansamantalang overloaded ang API. Maaari itong mangyari kapag mataas ang traffic sa API para sa lahat ng user. Walang kinalaman dito ang iyong key o code. Mag-retry gamit ang exponential backoff. Awtomatiko na itong ginagawa ng mga SDK para sa mga 5xx response. Kung hindi ito mawala, tingnan ang status.claude.com. Ang 500 api_error ay isang internal error na ire-retry mo sa parehong paraan. Hindi rate limit ang alinman sa dalawang ito.

Sa halip na umasa sa table, tingnan ang sarili mong limits

Sa isang subscription, /usage ang screen na mahalaga. Ipinapakita nito ang usage bars ng plan mo at ang breakdown ng mga gumamit sa mga ito. Ginagamit ang d o w para magpalipat-lipat sa huling 24 oras at huling 7 araw. May dalawang dapat tandaan. Ipinapakita ng Session block ang API token usage at para ito sa mga API user, kaya maaaring balewalain ng mga subscriber ang dollar figure nito. Mula sa local session history sa machine na iyon ang mga number, kaya hindi kasama ang usage mula sa ibang device o sa claude.ai.

Sa API side, nagpapakita ang Usage page sa Claude Console ng dalawang chart: "Rate Limit - Input Tokens" at "Rate Limit - Output Tokens". Ipinapakita ng input chart ang hourly maximum ng uncached input tokens bawat minuto kumpara sa kasalukuyan mong ITPM limit. Kasama rin dito ang cache rate, kaya namo-monitor mo ang paglapit sa limit bago ito maabot sa production.

Para programmatically basahin ang naka-configure mong limits:

curl -s https://api.anthropic.com/v1/organizations/rate_limits \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01"

Kailangan nito ng Admin API key. Ganoon din ang ginagawa ng GET /v1/organizations/workspaces/{workspace_id}/rate_limits para sa bawat workspace. Read-only ang dalawang ito. Para magpalit ng limit, gamitin ang Limits tab sa Console.

Paggamit ng mas kaunti para mas kaunti ang limit

Parehong bagay ang sinusukat ng dalawang system sa ilalim, kaya gumagana ang mga setting na ito sa alinman sa mga ito.

• Mas kaunting token bawat turn. Pinananatiling mainit ng tuloy-tuloy na mga session ang cache, at walang gastos ang /clear sa pagitan ng magkakahiwalay na task. Saklaw nang buo ng paggamit ng token sa Claude Code ang mga setting na ito.
• Bawasan ang effort. Ang mga level ay low, medium, high, xhigh at max. May ultracode din sa menu ng /effort, ngunit pinapataas nito ang gastos sa halip na bawasan ito. Walang pakinabang ang malalim na reasoning para sa mekanikal na pagpapalit ng pangalan.
• Bawasan ang concurrency pagkatapos ng 429. Ibaba ang CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY at iwasang magpatakbo ng maraming parallel subagent. Patakbuhin din ang /status: maaaring idaan ng nakaligtaang ANTHROPIC_API_KEY ang mga request sa low-tier key sa halip na sa subscription mo.
• Ilipat ang non-interactive na trabaho sa Message Batches API. Tumatakbo ito nang asynchronous para sa malalaking volume, na may 50% discount sa input at output token at sariling rate limit. Dahil dito, hindi na nakikipag-agawan ang nightly job sa session mo.

Pinakamahirap ito para sa trabahong nagbubuhos ng data sa context: kung sinusuri mo ang stocks at options batay sa live market data, mas kaunti ang gastos kapag kinukuha lamang ang kinakailangang bahagi para sa bawat tanong kaysa kapag ipinapasa ang buong table ng quotes at chains. Ang bursty na trabahong pinapatakbo ng program, hindi ng tao, ay dapat gumamit agad ng API key. Nagbabago rin ang paraan ng pagbabayad kapag lumipat ka roon, bukod sa paraan ng pagsukat sa paggamit, dahil walang free tier ang Claude API bukod sa maliit na credit na ibinibigay sa pag-sign up. Saklaw ng unang Claude API app mo sa VPS ang paghawak ng key at retries, at magpapatuloy ang mahabang agent run kahit maputol ang connection kapag pinananatili mong tumatakbo ang Claude Code sa VPS sa loob ng tmux.

FAQ

Bakit hindi naaayos ng pagpapalit ng model ang Claude usage limit ko?

Dahil pareho ang session at weekly limits para sa lahat ng model. Nakabatay ang allowance sa plan, hindi sa model. Binabago lamang ng /model kung aling model ang sasagot, hindi kung gaano karaming allowance ang natitira. Ang tanging exception ay ang You've hit your Opus limit, na para lamang sa mga request sa Opus. Sa ganitong sitwasyon, ang pagpapalit ng model ang dokumentadong solusyon.

Ano ang ibig sabihin ng 429 rate_limit_error, at gaano katagal ako dapat maghintay?

Ibig sabihin, naabot ng account mo ang rate limit para sa class ng model na iyon: requests per minute, input tokens per minute, o output tokens per minute. May retry-after header ang response na naglalaman ng bilang ng segundong dapat hintayin, at mabibigo ang mga mas maagang retry. Awtomatikong nagre-retry ang official SDKs kapag may rate limit at 5xx error, gamit ang exponential backoff nang dalawang beses bilang default at sinusunod ang header na iyon. Kung dumating ang 429 habang nasa loob ka pa ng limits ng tier mo, malamang acceleration limit ito na dulot ng biglaang pagtaas ng paggamit.

Paano ko makikita ang Claude usage limits ko at kung kailan magre-reset ang mga ito?

Sa Claude Code, patakbuhin ang /usage upang makita ang mga bar ng plan mo, reset time, at breakdown ng paggamit. Alias ang /cost, habang ang d o w ay nagpapalit sa pagitan ng huling 24 oras at huling 7 araw. Galing ang mga numerong ito sa local session history, kaya hindi kasama ang paggamit mula sa ibang device at mula sa claude.ai. Sa API, ipinapakita ng Console ang iyong rate limits, at ibinabalik ng GET /v1/organizations/rate_limits ang mga naka-configure na limit gamit ang Admin API key.

Maaari ba akong magpatuloy sa pagtatrabaho matapos maabot ang Claude plan limit ko?

Minsan. Patakbuhin ang /usage-credits upang bumili ng karagdagang usage lampas sa ceiling sa Pro at Max, o humiling nito sa admin sa Team at Enterprise. Kailangan nito ng claude.ai login sa pamamagitan ng /login, at hindi ito available kapag API key authentication ang ginagamit. Kung hindi, hintayin ang reset time, magpalit ng model kung Opus limit ang naabot, o ilipat ang trabaho sa API key, na sumusukat ng paggamit bawat minuto sa halip na bawat window.