Claude Platform su AWS: I limiti di velocità in questa pagina si applicano a Claude Platform su AWS. La fatturazione e i limiti di spesa differiscono: i limiti di spesa non sono disponibili e la fatturazione avviene tramite AWS Marketplace (non tramite acquisti di crediti Anthropic). Le organizzazioni su Claude Platform su AWS sono collocate nel livello Start e non passano automaticamente tra i livelli di utilizzo. Per richiedere limiti più elevati, contatta il tuo referente Anthropic. La configurazione dei limiti di velocità per workspace e la modalità veloce non sono disponibili su Claude Platform su AWS.
Esistono due tipi di limiti:
L'API applica limiti configurati dal servizio a livello di organizzazione, ma puoi anche impostare limiti configurabili dall'utente per i workspace della tua organizzazione.
Ciascuno dei livelli Start, Build e Scale prevede un tetto di spesa mensile, che è il massimo che la tua organizzazione può spendere per l'API in ogni mese di calendario. Una volta raggiunto il tetto di spesa del tuo livello, l'utilizzo dell'API viene sospeso fino al mese successivo, a meno che tu non richieda un limite più elevato. Puoi visualizzare il tetto di spesa mensile della tua organizzazione nella pagina Limits.
| Livello di utilizzo | Tetto di spesa mensile |
|---|---|
| Start | $500 |
| Build | $1,000 |
| Scale | $200,000 |
Le organizzazioni nel livello Custom non hanno un tetto di spesa mensile; i limiti sono concordati con il loro account team.
Puoi anche impostare un tuo limite di spesa inferiore al tetto del tuo livello per controllare i costi:
Vai alla pagina Limits
Vai su Settings > Limits nella Claude Console.
Apri l'editor del limite di spesa
Nella sezione Spend limits, fai clic su Change Limit (o Set spend limit se non è attualmente impostato alcun limite).
Regola il tuo limite di spesa
Inserisci un nuovo valore. Il tuo limite di spesa non può superare il tetto del tuo livello attuale.
I limiti di velocità per la Messages API sono misurati in richieste al minuto (RPM), token di input al minuto (ITPM) e token di output al minuto (OTPM) per ciascuna classe di modello.
Se superi uno qualsiasi dei limiti di velocità riceverai un errore 429 che descrive quale limite di velocità è stato superato, insieme a un header retry-after che indica quanto tempo attendere.
Potresti anche riscontrare errori 429 a causa dei limiti di accelerazione sull'API se la tua organizzazione ha un forte aumento dell'utilizzo. Per evitare di raggiungere i limiti di accelerazione, aumenta il tuo traffico gradualmente e mantieni modelli di utilizzo coerenti.
Molti fornitori di API utilizzano un limite combinato di "token al minuto" (TPM) che può includere tutti i token, sia in cache che non in cache, di input e di output. Per la maggior parte dei modelli Claude, solo i token di input non in cache contano ai fini dei tuoi limiti di velocità ITPM. Questo è un vantaggio chiave che rende i limiti di velocità effettivamente più elevati di quanto potrebbero inizialmente sembrare.
I limiti di velocità ITPM vengono stimati all'inizio di ogni richiesta e la stima viene aggiustata durante la richiesta per riflettere il numero effettivo di token di input utilizzati.
Ecco cosa conta ai fini dell'ITPM:
input_tokens (token dopo l'ultimo breakpoint della cache) ✓ Contano ai fini dell'ITPMcache_creation_input_tokens (token in fase di scrittura nella cache) ✓ Contano ai fini dell'ITPMcache_read_input_tokens (token letti dalla cache) ✗ NON contano ai fini dell'ITPM per la maggior parte dei modelliIl campo input_tokens rappresenta solo i token che appaiono dopo il tuo ultimo breakpoint della cache, non tutti i token di input nella tua richiesta. Per calcolare il totale dei token di input:
total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokensCiò significa che quando hai contenuti in cache, input_tokens sarà tipicamente molto più piccolo del tuo input totale. Ad esempio, con un documento in cache da 200k token e una domanda dell'utente da 50 token, vedresti input_tokens: 50 anche se l'input totale è di 200.050 token.
Ai fini dei limiti di velocità sulla maggior parte dei modelli, solo input_tokens + cache_creation_input_tokens contano per il tuo limite ITPM, rendendo la cache dei prompt un modo efficace per aumentare il tuo throughput effettivo.
Esempio: Con un limite ITPM di 2.000.000 e un tasso di cache hit dell'80%, potresti effettivamente elaborare 10.000.000 di token di input totali al minuto (2M non in cache + 8M in cache), perché i token in cache non contano ai fini del tuo limite di velocità.
Claude Haiku 3.5 (contrassegnato con † nelle seguenti tabelle dei limiti di velocità) conta anche cache_read_input_tokens ai fini dei limiti di velocità ITPM.
Per tutti i modelli senza il contrassegno †, i token di input in cache non contano ai fini dei limiti di velocità e vengono fatturati a una tariffa ridotta (10% del prezzo base dei token di input). Ciò significa che puoi ottenere un throughput effettivo significativamente più elevato utilizzando la cache dei prompt.
Massimizza i tuoi limiti di velocità con la cache dei prompt
Per ottenere il massimo dai tuoi limiti di velocità, usa la cache dei prompt per contenuti ripetuti come:
Con una cache efficace, puoi aumentare drasticamente il tuo throughput effettivo senza aumentare i tuoi limiti di velocità. Monitora il tuo tasso di cache hit nella pagina Usage per ottimizzare la tua strategia di caching.
I limiti di velocità OTPM vengono valutati in tempo reale man mano che i token di output vengono prodotti, contando solo i token effettivamente generati. Il parametro max_tokens non influisce sui calcoli dei limiti di velocità OTPM, quindi non c'è alcuno svantaggio in termini di limiti di velocità nell'impostare un valore max_tokens più elevato.
I limiti di velocità vengono applicati separatamente per ciascun modello; pertanto puoi utilizzare modelli diversi fino ai rispettivi limiti contemporaneamente. Puoi verificare i tuoi limiti di velocità attuali e il loro comportamento nella Claude Console, oppure leggere i limiti configurati in modo programmatico con la Rate Limits API.
I limiti di velocità sono attualmente condivisi tra tutti i valori di inference_geo. Le richieste con inference_geo: "us" e inference_geo: "global" attingono dallo stesso pool di limiti di velocità.
* - Il limite di velocità di Opus è un limite totale che si applica al traffico combinato tra Claude Opus 4.8, Opus 4.7, Opus 4.6 e Opus 4.5.
** - Il limite di velocità di Sonnet 4.x è un limite totale che si applica al traffico combinato tra Sonnet 4.6 e Sonnet 4.5. Claude Sonnet 5 ha un limite di velocità separato e non fa parte di questo bucket combinato.
† - Il limite conta cache_read_input_tokens ai fini dell'utilizzo ITPM.
La Message Batches API ha un proprio insieme di limiti di velocità che sono condivisi tra tutti i modelli. Questi includono un limite di richieste al minuto (RPM) per tutti gli endpoint API e un limite sul numero di richieste batch che possono trovarsi contemporaneamente nella coda di elaborazione. Una "richiesta batch" qui si riferisce a una parte di un Message Batch. Puoi creare un Message Batch contenente migliaia di richieste batch, ognuna delle quali conta ai fini di questo limite. Una richiesta batch è considerata parte della coda di elaborazione quando non è ancora stata elaborata con successo dal modello.
Gli endpoint di Claude Managed Agents hanno limiti di velocità per organizzazione. Questi limiti sono separati dai limiti di velocità della Messages API sopra indicati.
| Operazione | Limite |
|---|---|
| Endpoint di creazione (ad esempio, agenti, sessioni ed environment) | 300 richieste al minuto |
| Endpoint di lettura (ad esempio, recupero, elenco e stream) | 1.200 richieste al minuto |
Quando utilizzi la modalità veloce (anteprima di ricerca) con speed: "fast" su Claude Opus 4.8 o Opus 4.7, si applicano limiti di velocità dedicati che sono separati dai limiti di velocità standard di Opus. Quando i limiti di velocità della modalità veloce vengono superati, l'API restituisce un errore 429 con un header retry-after. La modalità veloce non è disponibile su Claude Opus 4.6: le richieste a claude-opus-4-6 con speed: "fast" vengono eseguite a velocità standard. Consulta Modalità veloce.
La risposta include header anthropic-fast-* che indicano lo stato del tuo limite di velocità della modalità veloce. Consulta Modalità veloce per i dettagli su questi header.
Puoi monitorare l'utilizzo dei tuoi limiti di velocità nella pagina Usage della Claude Console.
Oltre a fornire grafici di token e richieste, la pagina Usage fornisce due grafici separati sui limiti di velocità. Usa questi grafici per vedere quale margine di crescita hai, quando potresti raggiungere il picco di utilizzo, comprendere meglio quali limiti di velocità richiedere o come puoi migliorare i tuoi tassi di caching. I grafici visualizzano una serie di metriche per un determinato limite di velocità (ad esempio, per modello):
Per richiedere limiti di velocità più elevati o un tetto di spesa mensile più alto, usa Request rate limit increase nella pagina Limits.
Anche il supporto può aumentare i limiti. Per esigenze urgenti, contatta il supporto.
Per maggiori informazioni sui workspace, consulta Workspace.
Per proteggere i Workspace della tua Organizzazione da un potenziale utilizzo eccessivo, puoi impostare limiti di spesa e di velocità personalizzati per ciascun Workspace.
Esempio: Se il limite della tua Organizzazione è di 40.000 token di input al minuto e 8.000 token di output al minuto, potresti limitare un Workspace a 30.000 token di input al minuto. Questo protegge gli altri Workspace da un potenziale utilizzo eccessivo e garantisce una distribuzione più equa delle risorse nella tua Organizzazione. I restanti token al minuto non utilizzati (o di più, se quel Workspace non utilizza il limite) sono quindi disponibili per l'uso da parte degli altri Workspace.
Nota:
Per leggere in modo programmatico i limiti di velocità attuali della tua organizzazione e dei workspace, usa la Rate Limits API.
La risposta dell'API include header che mostrano il limite di velocità applicato, l'utilizzo attuale e quando il limite verrà azzerato.
Vengono restituiti i seguenti header:
| Header | Descrizione |
|---|---|
retry-after | Il numero di secondi da attendere prima di poter ritentare la richiesta. Tentativi anticipati falliranno. |
anthropic-ratelimit-requests-limit | Il numero massimo di richieste consentite entro qualsiasi periodo di limite di velocità. |
anthropic-ratelimit-requests-remaining | Il numero di richieste rimanenti prima di essere soggetti al limite di velocità. |
anthropic-ratelimit-requests-reset | Il momento in cui il limite di velocità delle richieste sarà completamente reintegrato, fornito in formato RFC 3339. |
anthropic-ratelimit-tokens-limit | Il numero massimo di token consentiti entro qualsiasi periodo di limite di velocità. |
anthropic-ratelimit-tokens-remaining | Il numero di token rimanenti (arrotondato al migliaio più vicino) prima di essere soggetti al limite di velocità. |
anthropic-ratelimit-tokens-reset | Il momento in cui il limite di velocità dei token sarà completamente reintegrato, fornito in formato RFC 3339. |
anthropic-ratelimit-input-tokens-limit | Il numero massimo di token di input consentiti entro qualsiasi periodo di limite di velocità. |
anthropic-ratelimit-input-tokens-remaining | Il numero di token di input rimanenti (arrotondato al migliaio più vicino) prima di essere soggetti al limite di velocità. |
anthropic-ratelimit-input-tokens-reset | Il momento in cui il limite di velocità dei token di input sarà completamente reintegrato, fornito in formato RFC 3339. |
anthropic-ratelimit-output-tokens-limit | Il numero massimo di token di output consentiti entro qualsiasi periodo di limite di velocità. |
anthropic-ratelimit-output-tokens-remaining | Il numero di token di output rimanenti (arrotondato al migliaio più vicino) prima di essere soggetti al limite di velocità. |
anthropic-ratelimit-output-tokens-reset | Il momento in cui il limite di velocità dei token di output sarà completamente reintegrato, fornito in formato RFC 3339. |
anthropic-priority-input-tokens-limit | Il numero massimo di token di input del Priority Tier consentiti entro qualsiasi periodo di limite di velocità. (Solo Priority Tier) |
anthropic-priority-input-tokens-remaining | Il numero di token di input del Priority Tier rimanenti (arrotondato al migliaio più vicino) prima di essere soggetti al limite di velocità. (Solo Priority Tier) |
anthropic-priority-input-tokens-reset | Il momento in cui il limite di velocità dei token di input del Priority Tier sarà completamente reintegrato, fornito in formato RFC 3339. (Solo Priority Tier) |
anthropic-priority-output-tokens-limit | Il numero massimo di token di output del Priority Tier consentiti entro qualsiasi periodo di limite di velocità. (Solo Priority Tier) |
anthropic-priority-output-tokens-remaining | Il numero di token di output del Priority Tier rimanenti (arrotondato al migliaio più vicino) prima di essere soggetti al limite di velocità. (Solo Priority Tier) |
anthropic-priority-output-tokens-reset | Il momento in cui il limite di velocità dei token di output del Priority Tier sarà completamente reintegrato, fornito in formato RFC 3339. (Solo Priority Tier) |
Gli header anthropic-ratelimit-tokens-* mostrano i valori del limite più restrittivo attualmente in vigore. Ad esempio, se hai superato il limite di token al minuto del Workspace, gli header conterranno i valori del limite di velocità dei token al minuto del Workspace. Se i limiti del Workspace non si applicano, gli header restituiranno il totale dei token rimanenti, dove il totale è la somma dei token di input e di output. Questo approccio garantisce che tu abbia visibilità sul vincolo più rilevante per il tuo attuale utilizzo dell'API.
Was this page helpful?