Claude usage limit: Ano ang gagawin kapag naubos ito

Ano ang mga limitasyon sa paggamit ng Claude?

May dalawang magkahiwalay na sistema para sa mga limitasyon sa paggamit ng Claude, at ang unang hakbang ay tukuyin kung alin sa mga ito ang pumigil sa iyo. Ang Claude subscription (Pro, Max, Team, o seat-based Enterprise) ay nagbibigay ng rolling usage allowance na pinagsasaluhan ng mga model, maliban sa ilang ceiling para sa model family, at pinagsasaluhan din ng Claude chat. Kapag naubos ito, makakatanggap ka ng mensaheng gaya ng You've hit your session limit · resets 3:45pm. Ang kasalukuyang usage-based Enterprise plan ang eksepsiyon: wala itong kasamang allowance, at sinisingil ang lahat ng paggamit sa API rates mula sa unang token. Iba naman ang sinusukat ng Claude API: kung gaano kabilis kang nagpapadala ng requests at tokens, na binibilang bawat minuto. Hihinto ito at magbabalik ng HTTP 429 error na may type na rate_limit_error, karaniwang may retry-after header na nagsasaad kung ilang segundo ang dapat hintayin.

Walang kaugnayan ang mga paraan ng pag-aayos sa isa't isa. Ang subscription limit ay tungkol sa dami ng nagamit mo sa loob ng isang window, kaya kailangan mong hintayin ang reset, bumili ng karagdagang usage, o gamitin ang libreng limit reset kung iniaalok ito ng plan mo. Ang API rate limit naman ay tungkol sa bilis ng pagpapadala mo sa kasalukuyan, at nawawala ito 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 nakalista rito. Basahin ang sarili mong mga value gamit ang mga command sa ibaba.

Aling limit ang naabot mo? Basahin ang eksaktong mensahe

Tinutukoy ng Claude Code ang system sa text na ipinapakita nito. Itugma ang sa iyo bago ka magbago ng anuman.

• You've hit your session limit · resets 3:45pm ay subscription limit. Naubos na ang rolling allowance ng plan mo para sa window na ito.
• You've hit your weekly limit · resets Mon 12:00am ay parehong system para sa mas mahabang window.
• You've hit your Opus limit · resets 3:45pm ay subscription limit na nalalapat lamang sa mga request na gumagamit ng Opus. Kapag lumipat ka sa model na wala sa Opus family, makakapagpatuloy ka.
• You've hit your Sonnet limit · resets 3:45pm ay parehong uri ng model-family limit, ngunit para lamang sa mga request na gumagamit ng Sonnet. Kapag lumipat ka sa model na wala sa Sonnet family, makakapagpatuloy ka.
• Ang mensaheng nagsisimula sa Fable limit reached ay nangangahulugang nagamit mo na ang bahaging maaaring gamitin ng mga Fable model sa weekly allowance mo. Kapag nagpatuloy ka, sisingilin ang paggamit sa usage credits, kaya hinihiling muna ng Claude Code ang kumpirmasyon mo. Pumili ng ibang model gamit ang /model upang manatili sa loob ng plan mo.
• API Error: Request rejected (429) · this may be a temporary capacity issue. If it persists, check https://status.claude.com. ay API rate limit. Kapag Anthropic API key ang gamit, ito ang rate limit ng organization mo, o mas mababang limit na itinakda sa workspace na kinabibilangan ng key. Kapag Amazon Bedrock o Google Cloud ang gamit, ito ang quota ng cloud project mo. Depende sa kung paano nag-a-authenticate ang client kung alin sa mga ito ang nalalapat, dahil ang Bedrock o Vertex client ay binibilang laban sa quota ng cloud project mo sa halip na sa Anthropic organization.
• API Error: Server is temporarily limiting requests (not your usage limit) ay panandaliang throttle na walang kaugnayan sa plan quota mo. Awtomatiko itong nire-retry ng Claude Code gamit ang backoff bago nito ipakita sa iyo ang linyang iyon.

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

May rolling usage allowance ang Pro, Max, Team, o seat-based Enterprise plan. Kapag naubos ito, bina-block ng Claude Code ang mga kasunod na request hanggang sa reset time na ipinapakita sa mensahe. Dalawang property ng allowance na ito ang karaniwang nagdudulot ng kalituhan.

• Shared ito sa Claude chat. Ang ginagawa mo sa claude.ai ay kumokonsumo mula sa parehong allowance ng ginagawa mo sa terminal, kaya ang matagal na paggamit sa chat sa hapon ay nagpapababa sa coding time mo sa gabi. Lahat ng surface na ginagamit mong pag-sign in gamit ang account na iyon ay kumokonsumo mula sa iisang pool. Kaya sa Linux, ang beta desktop app at ang Claude Code CLI ay parehong kumokonsumo ng isang allowance, hindi tig-isa.
• Shared ito sa lahat ng model. Iisang pool ang session at weekly limits para sa bawat model. Ang mga exception ay ang model-family ceiling sa loob ng pool na iyon: ang Opus at Sonnet limits, at sa Max at Premium seats, ang Fable allocation na hanggang 50% ng weekly limits mo. Sa Pro at Standard seats, hindi kasama ang Fable sa plan limits at sisingilin ito sa usage credits mula sa unang request.

Sa Claude for Teams at seat-based Enterprise, ang documented na setup ay per-seat allowance na nagre-reset sa rolling five-hour window at weekly window. Shared ito sa Claude chat at Cowork, at nakabatay ang laki nito sa seat tier (Standard o Premium). Iba ang kasalukuyang usage-based Enterprise plans: walang included allowance na maaaring maubos, sinisingil ang usage ayon sa API rates, at ang ceiling ay nakabatay sa spend limits na itinakda ng mga admin sa organization level at para sa bawat user. Sa sales-assisted plan, ang usage na nahinto dahil sa spend limit ay magpapatuloy sa simula ng susunod na billing period, maliban kung itinaas muna ng owner ang limit. Sa self-serve plan, hihinto rin ang usage kapag naubos ang prepaid credit balance, hanggang sa bumili muli ang owner. Sa Pro at Max, ang reset time na naka-print sa mensahe at ang sarili mong /usage bars ang maaasahang batayan, hindi ang numerong kinopya mula sa blog post. Kung pumipili ka pa ng tier, ikinukumpara ng 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 session o weekly limit

Ito ang pinakakaraniwang maling hakbang, at malinaw ang dokumentasyon tungkol dito: pare-parehong ginagamit ng lahat ng model ang session at weekly limit, kaya hindi naibabalik ng paglipat ng model ang access. Kapag pumili ng mas maliit na model matapos maubos ang session window, nagbabago lamang kung aling model ang sasagot. Hindi nito binabago kung gaano karaming allowance ang natitira, dahil hindi nakatalaga sa bawat model ang session at weekly allowance. Kaya walang nare-release sa paglipat.

Ang mga exception ay ang mga ceiling ng model family. Kung ang mensahe ay You've hit your Opus limit o You've hit your Sonnet limit, /model ang tamang fix. Lumipat sa model na nasa labas ng family na iyon at magpatuloy sa pagtatrabaho, dahil ang mga request lamang ng family na iyon ang naka-block. Ganito rin ang Fable limit sa Max at Premium seat: lumipat sa ibang model upang magpatuloy sa loob ng iyong plan, o magpatuloy sa paggamit ng Fable gamit ang usage credits. Gayunman, mas mabilis gamitin ng Fable ang regular weekly limit ng iyong plan kaysa sa ibang model, at walang idinadagdag na allowance ang paglipat: kumukuha ang ibang model sa parehong kabuuang weekly limit, na patuloy na umiiral at maaari pa ring maabot.

Ang pagtrato sa limit bilang bug ang ikalawang maling hakbang. Walang mababago ang pag-reinstall o muling pag-authenticate. Bumabalik ang allowance kapag nag-reset ang window o kapag gumamit ka ng libreng limit reset. Hindi ito nire-refill ng pagbili ng usage credits: lilipat ang iyong mga request sa pay-as-you-go pricing gamit ang credits at magpapatuloy na gumana, habang ang mga kasamang limit ay nagre-reset pa rin ayon sa normal na schedule ng mga ito.

Ano ang gagawin kapag naabot mo ang limit ng subscription

1. Basahin ang oras ng reset. Maikli ang session window. Ang weekly window ay hindi kailangang hintayin sa harap ng desk. Sa Claude Code v2.1.234 o mas bago, maaaring hintayin ng /rate-limit-options ang reset at awtomatikong ipagpatuloy ang naantalang task.
2. Kung Opus, Sonnet, o Fable limit ito, patakbuhin ang /model at pumili ng model sa labas ng pamilyang iyon.
3. Patakbuhin ang /usage upang makita ang mga limit ng iyong plan, ang paggamit mo, at kung kailan magre-reset ang mga ito. Alias ang /cost para sa parehong screen.
4. Tingnan ang Settings > Usage sa claude.ai o sa Claude Desktop para sa seksyong Resets. Paminsan-minsan, inaalok sa mga kwalipikadong plan ang libreng pag-reset ng limit. Kapag na-click ang "Reset for free", ibinabalik agad sa full ang iyong five-hour session limit o weekly limit, depende sa limit na saklaw ng offer. Hindi available ang button sa Claude Code na tumatakbo sa terminal o IDE, o sa Claude Mobile, at may expiration ang bawat offer.
5. Patakbuhin ang /usage-credits upang magpatuloy sa pagtatrabaho lampas sa ceiling. Sa Pro at Max, bubuksan nito ang iyong billing settings. Sa Team at Enterprise, bubuksan nito ang usage settings ng iyong organization, o magpapadala ito ng request sa iyong admins kung wala kang billing access.
6. Kung pareho ang limit na naaabot mo bawat linggo, hindi tugma ang laki ng plan sa paraan ng paggamit mo. Mainam na suriin minsan ang mga paraan para malampasan ang usage limit sa halip na gawin ito sa bawat reset.

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

May isang side effect ang usage credits na dapat mong malaman. Bilang default, binibigyan ng Claude Code ang main conversation ng one-hour prompt cache habang nasa loob ka ng included usage ng subscription. Kapag gumagamit ka na ng credits, ibinababa nito ang cache sa five minutes. Dahil dito, mas maraming turn ang nagsisimula nang walang cache at tumataas ang paggamit ng token sa Claude Code para sa parehong task. Hiwalay ang mga subagent sa bucket ng main conversation, kaya five minutes ang cache nila kahit nasa loob ka pa ng plan usage. Kung ikaw mismo ang magtatakda ng TTL gamit ang promptCacheTtl setting o CLAUDE_CODE_PROMPT_CACHE_TTL sa Claude Code v2.1.242 o mas bago, mananatili ang one-hour lifetime habang gumagamit ka ng credits.

Mga mensaheng mukhang usage limit pero hindi

Apat na Claude Code error ang napagkakamalang usage limit, pero wala sa mga ito ang tunay 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, kasunod ang command na nagpapalaya ng espasyo, kapag lumampas na ang conversation sa context window ng model. Sini-summarize ng compacting ang mas lumang history para magpalaya ng espasyo, pero hindi ito libre: binabasa ng /compact ang conversation na sini-summarize nito, kaya ang pag-compact ng malaking context ay isa ring malaking request laban sa iyong plan. Kapag gusto mo ng panibagong simula sa halip na ipagpatuloy ang kasalukuyang context, walang bayad ang /clear.
• Ibig sabihin ng Prompt is too long · automatic compaction failed: <the underlying error> na nabigo mismo ang automatic compaction dahil sa error na tinutukoy nito. Patuloy na mabibigo ang /compact dahil sa error na iyon hanggang sa maresolba mo ito.
• Ibig sabihin ng Credit balance is too low na naubos na ng iyong Console organization ang prepaid credits nito, o ipinapadala ng Claude Code ang requests ng subscriber gamit ang Console API key; ipinapakita ng /status kung aling credential ang aktibo. Magdagdag ng credits sa platform.claude.com/settings/billing, na mayroon ding auto-reload.
• Ang API Error: Usage credits required for 1M context · run /usage-credits to turn them on (they take effect after you restart Claude Code), or /model to switch to standard context ay entitlement check, hindi naubos na quota. Kung pumili ka ng [1m] variant ng Opus 4.6 o Sonnet 4.6, piliin ang variant na walang [1m] suffix, o itakda ang CLAUDE_CODE_DISABLE_1M_CONTEXT=1. Kung lumitaw ito sa kalagitnaan ng conversation dahil lumampas ang context sa 200K tokens, awtomatikong nagco-compact ang Claude Code pabalik sa mas mababang standard limit. Ang Sonnet 5 at mga susunod na version, Opus 4.7 at mga susunod na version, Haiku 5.5, at ang Fable models ay tumatakbo gamit ang native na 1M window at walang suffix na kailangang alisin; ang variable na iyon ang naglilimita sa mga ito sa 200K.

May isa pang error na nagmumula 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 organization mo. Iba ito: maximum monthly cost ito para sa paggamit ng API. Kapag naabot mo ang spend cap ng tier mo, hihinto ang API usage hanggang sa susunod na buwan maliban kung humiling ka ng mas mataas na limit. Nagbabalik din ito ng 429 rate_limit_error, pero walang retry-after header at may enforced_spend_limit_reached sa error.details.error_code. Walang retry loop na makalulutas dito. Ang mas mababang spend limit na ikaw mismo ang nagtakda sa Console, para sa organization o workspace, ay lumalabas sa ibang paraan: nagbabalik ang requests ng HTTP 400 invalid_request_error na may mensaheng nagsisimula sa You have reached your specified API usage limits, o You have reached your specified workspace API usage limits para sa workspace. Kapag tinaasan o inalis ang limit, maibabalik ang access. Ang exception ay ang Claude Code workspace: ang Claude Code requests na lumampas sa spend limit ng workspace na iyon ay maaaring makatanggap ng 429 na may retry-after header.

Apat na mekanismo ang nagtatakda kung kailan darating ang 429.

• Bawat model class ang may sariling limit. Hiwalay itong ipinapatupad para sa bawat model, kaya maaari kang gumamit ng magkakaibang model hanggang sa kani-kanilang limit nang sabay. May ilang 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, habang may sarili namang 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 magfa-fail 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 models, at ang Claude Haiku 3.5 ang dokumentadong exception. Dahil dito, nakadaragdag ang caching sa headroom ng rate limit at nagbibigay rin ng discount. Sa output naman, hindi ibinibilang sa OTPM ang mataas na max_tokens, dahil ang OTPM ay ang aktuwal na tokens na nalikha lamang ang binibilang.
• Sa organization level nakatalaga ang mga limit. Maaaring bigyan ang workspace ng mas mababang limit, at palaging umiiral ang organization-wide limits kahit lumampas sa mga ito ang kabuuan ng workspace limits. Kapag hindi mo binago ang limit sa isang workspace, minamana nito ang limit mula sa organization; hindi ito awtomatikong nagiging unlimited.

Itinatakda ng mga tier na Start, Build, Scale at Custom ang aktuwal na mga numero. Awtomatikong itinatalaga ang mga ito batay sa usage history at standing ng account mo. Maaaring magsimula sa Evaluation tier ang mga bagong organization at ang mga may kaunting usage history. Mas mababa ito sa karaniwang published limits, kaya maaaring mas maagang dumating ang unang 429 kaysa sa inaasahan ng isang table. Nagti-trigger ang biglang pagtaas ng usage ng acceleration limits. Nagbabalik ang mga ito ng 429 kahit nasa loob ka pa ng tier mo, kaya unti-unting itaas ang traffic. Ceiling ang bawat published figure: ang documented limits ay maximum allowed usage, hindi garantisadong minimums. Para humiling ng mas mataas na limit, gamitin ang "Request tier increase" sa Rate limits page ng Claude Console.

Pagbasa ng 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, pati isang 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 segundo na dapat hintayin bago muling subukan ang request. Mabibigo ang mas maagang retry. Hindi lahat ng 429 ay may ganito, at hindi ito kailanman kasama sa spend-cap 429.
• Inilalarawan ng anthropic-ratelimit-requests-limit, anthropic-ratelimit-requests-remaining, at anthropic-ratelimit-requests-reset ang iyong request budget.
• Pareho ang ginagawa ng anthropic-ratelimit-input-tokens-* at anthropic-ratelimit-output-tokens-* para sa ITPM at OTPM, gamit ang parehong suffix para sa limit, remaining, at reset.
• Ipinapakita ng anthropic-ratelimit-tokens-* ang mga value para sa pinaka-restrictive na limit na kasalukuyang ipinapatupad.

Ang reset header ay mga timestamp na RFC 3339. Nira-round sa pinakamalapit na thousand ang remaining token header, kaya ituring ang mga ito bilang gauge. May sarili nitong pool at 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 nakikipag-ugnayan ka sa support.

Suriin muna kung kailangan mo talaga ng backoff loop bago gumawa nito. Awtomatikong nire-retry ng official SDK ang mga transient failure, kabilang ang connection error, rate limit, at 5xx server error, gamit ang exponential backoff, dalawang beses bilang default, at sinusunod ang retry-after header kapag mayroon ito. May maximum-retries option ang bawat client para 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.

Basahin ang sarili mong limit sa halip na umasa sa isang table

Sa isang subscription, /usage ang screen na mahalaga. Ipinapakita nito ang mga usage bar ng iyong plan at ang breakdown ng kumonsumo sa mga ito. Sa pamamagitan ng d o w, nagpapalit ka sa pagitan ng nakaraang 24 na oras at nakaraang 7 araw. May dalawang mahalagang paalala. Ipinapakita ng Session block ang paggamit ng API token at para ito sa mga API user, kaya maaaring balewalain ng mga subscriber ang dollar figure nito. Galing ang mga numero sa lokal na session history sa machine na iyon, kaya hindi kasama ang paggamit mula sa ibang device o mula sa claude.ai.

Sa panig ng API, gumuguhit 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. Ipinapakita rin nito ang cache rate sa tabi nito, kaya namo-monitor mo ang paglapit sa limit sa halip na hinihintay mo pang maabot ito sa production.

Para basahin ang iyong configured limits gamit ang program:

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 credentials: isang Admin API key, isang OAuth token na may org:admin scope, o isang personal o service account key na hindi naka-scope sa isang workspace. Hindi gumagana ang Workspace API keys. Pareho ang ginagawa ng GET /v1/organizations/workspaces/{workspace_id}/rate_limits para sa bawat workspace. Read-only ang dalawang ito. Para baguhin ang isang limit, gamitin ang Rate limits page sa Console.

Paggamit ng mas kaunti para mas kaunti ang limitasyong maabot

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

• Gumamit ng mas kaunting token bawat turn. Pinananatiling warm ng tuloy-tuloy na mga session ang cache, at walang gastos ang /clear sa pagitan ng magkakaugnay na task. Saklaw nang buo ng paggamit ng token sa Claude Code ang mga pamamaraang ito.
• Bawasan ang effort. Ang mga level ay low, medium, high, xhigh at max. Iniaalok din ng menu na /effort ang ultracode, na nagpapataas ng gastusin sa halip na magpababa nito. Walang pakinabang ang malalim na reasoning para sa simpleng 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 ipadala ng nakaligtaang ANTHROPIC_API_KEY ang mga request sa low-tier key sa halip na sa iyong subscription.
• Ilipat ang non-interactive na trabaho sa Message Batches API. Asynchronous nitong pinoproseso ang malalaking volume na may 50% discount sa input at output token, sa ilalim ng sarili nitong rate limits, kaya hindi na nakikipag-agawan ang nightly job sa iyong session.

Pinakamalakas itong nararamdaman sa mga trabahong naglalagay ng maraming data sa context: kung sinusuri mo ang stocks at options batay sa live market data, mas kaunting gastos ang pagkuha sa maliit na bahagi na kailangan ng bawat tanong kaysa pag-paste ng buong mga talahanayan ng quotes at chains. Ang bursty na trabahong pinapatakbo ng program sa halip na tao ay dapat gumamit agad ng API key. Binabago nito hindi lamang kung paano ka sini-suklian kundi pati kung paano sinusukat ang paggamit mo, dahil walang free tier ang Claude API. May kasamang buwanang API credits ang Max at Team plans para sa pagpapatakbo ng sarili mong app at agent kapag na-link mo ang isang Console organization. Hindi saklaw ng mga credit na iyon ang Claude Code at hindi nito binabago ang usage limits ng iyong plan. Saklaw ng iyong unang Claude API app sa isang VPS ang pamamahala ng key at mga retry, at magpapatuloy ang mahabang agent run kahit maputol ang connection kapag pinanatili mong tumatakbo ang Claude Code sa isang VPS sa loob ng tmux.

FAQ

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

Dahil magkakapareho ang session at weekly limits para sa lahat ng model. Nakalaan ang allowance na iyon sa plan, hindi sa isang model. Kaya binabago ng /model kung aling model ang sasagot, pero hindi nito binabago kung gaano karaming allowance ang natitira. Ang mga exception ay ang limits ng model family: ang You've hit your Opus limit at You've hit your Sonnet limit ay para lamang sa pamilyang iyon, at nililimitahan ng Fable limit sa Max at Premium seats ang Fable lamang. Sa mga sitwasyong ito, ang pagpapalit ng model ang nakadokumentong solusyon.

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

Karaniwan, ibig sabihin nito ay umabot sa rate limit para sa model class na iyon ang iyong organization: requests per minute, input tokens per minute, o output tokens per minute. Karaniwang may retry-after header ang response na nagsasaad kung ilang segundo ang dapat hintayin, at mabibigo ang mga naunang retry. Awtomatikong nagre-retry ang mga opisyal na SDK sa rate limits at 5xx errors gamit ang exponential backoff, dalawang beses bilang default, at sinusunod ang header kapag naroroon ito. Ang 429 na dumarating kahit nasa loob ka pa ng limits ng iyong tier ay nagpapahiwatig ng acceleration limit dahil sa biglaang pagtaas ng paggamit. Ang 429 na may enforced_spend_limit_reached sa error.details.error_code, na hindi kailanman may dalang retry-after header, ay monthly spend cap. Hindi ito maaayos sa paghihintay ng ilang minuto. Maaari ring makatanggap ng 429 ang Claude Code requests kapag umabot sa spend limit na itinakda para sa Claude Code workspace.

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

Sa Claude Code, patakbuhin ang /usage para makita ang plan bars, reset times, at breakdown ng paggamit. Alias ang /cost, at nagpapalit ang d o w sa pagitan ng huling 24 oras at huling 7 araw. Mula sa local session history ang mga figure na ito, kaya hindi kasama ang paggamit mula sa ibang device at mula sa claude.ai. Sa API, ipinapakita ng Console ang iyong rate limits. Ibinabalik naman ng GET /v1/organizations/rate_limits ang iyong configured limits gamit ang Admin API credentials, gaya ng Admin API key.

Maaari ba akong magpatuloy sa pagtatrabaho kapag naabot ko na ang Claude plan limit ko?

Minsan. Patakbuhin ang /usage-credits para bumili ng karagdagang usage lampas sa ceiling sa Pro at Max, o para hilingin ito sa isang 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, maghintay hanggang sa reset time, gumamit ng libreng limit reset kung nag-aalok nito ang Settings > Usage sa claude.ai o Claude Desktop, magpalit ng model kung Opus, Sonnet, o Fable limit ang naabot, o ilipat ang trabaho sa API key. Ang paggamit ng API key ay mino-monitor kada minuto sa halip na kada window.