xAI descrive Grok 4.7 come il suo modello di frontiera per coding, compiti agentici e lavoro della conoscenza, con una finestra di contesto da 500K token. Secondo l’attuale pagina prezzi di xAI, le tariffe dirette dell’API sotto i 200.000 token di prompt sono $2.00 per milione di token di input, $0.50 per milione di token in cache e $6.00 per milione di token di output. Quando un prompt raggiunge 200.000 token o più, xAI indica rispettivamente $4.00, $1.00 e $12.00. Queste sono tariffe dirette xAI, non un prezzo universale valido sulle piattaforme di terze parti.
La spesa effettiva dipende da più fattori rispetto alla tariffa di input principale. Input nuovo, input in cache, output, retry, chiamate agli strumenti e numero di chiamate al modello in un workflow agentico possono tutti influenzare il conto. La soglia dei 200K token di prompt è particolarmente importante perché sia xAI sia CometAPI pubblicano tariffe long-context più alte una volta superato quel limite.
Questa guida stabilisce innanzitutto il baseline dei prezzi xAI, quindi confronta l’attuale scheda CometAPI Grok 4.7. Al 28 settembre 2026, CometAPI indica $1.60 / $0.40 / $4.80 per milione di token rispettivamente per input nuovo, input in cache e output nel tier standard, e $3.20 / $0.80 / $9.60 nel tier long-context—un 20% in meno rispetto alle corrispondenti tariffe dirette xAI. Le sezioni successive spiegano come calcolare il costo del carico di lavoro, ridurre gli sprechi e accedere al modello tramite CometAPI. Tutti i prezzi sono istantanee datate e vanno ricontrollati prima dell’uso in produzione.
Prezzi xAI diretti vs. CometAPI Grok 4.7
Tariffe xAI dirette (USD per 1M token)
| Categoria di token | Sotto 200K token di prompt | Contesto lungo (≥200K) |
|---|---|---|
| Input nuovo | $2.00 | $4.00 |
| Input in cache | $0.50 | $1.00 |
| Output | $6.00 | $12.00 |
Tariffe CometAPI (USD per 1M token)
| Categoria di token | CometAPI: sotto 200K token di prompt | CometAPI: tier long-context |
|---|---|---|
| Input nuovo | $1.60 / 1M token | $3.20 / 1M token |
| Input in cache | $0.40 / 1M token | $0.80 / 1M token |
| Output | $4.80 / 1M token | $9.60 / 1M token |
La soglia dei 200K token di prompt conta perché entrambe le piattaforme attualmente indicano tariffe long-context pari al doppio delle rispettive tariffe del tier standard per Grok 4.7. Si tratta di una regola di prezzo stabilita da ciascuna piattaforma API, non di un cambiamento nelle capacità del modello. Una richiesta diventa più costosa quando un’applicazione invia ripetutamente prompt lunghi o lascia crescere senza controllo la cronologia dell’agente—non semplicemente perché Grok 4.7 supporta una finestra di contesto da 500K.
Per il budgeting, trattate come long-context qualsiasi richiesta prevista in prossimità della soglia finché non si verifica il comportamento di fatturazione attivo. La disponibilità del modello e i prezzi possono cambiare; pertanto i calcolatori di produzione dovrebbero ricontrollare sia il pricing diretto xAI sia la pagina modello CometAPI attuale invece di inserire valori permanenti hard-coded.
La formula per stimare il costo di Grok 4.7
Stimate una richiesta valutando separatamente ciascuna categoria di token:
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
Quindi convertite la stima della richiesta in una stima del carico di lavoro:
monthly cost = request cost × requests per user × active users × days in billing period
Usate un percentile realistico anziché una sola media. Una stima p50 descrive una richiesta normale, ma le lunghezze p95 di input e output evidenziano la coda costosa che spesso guida il conto. Per i workflow agentici, moltiplicate per il numero previsto di chiamate al modello per task completato. Un workflow a cinque passaggi equivale a cinque chiamate fatturabili, non a una.
Esempio pratico 1: un copilot di supporto
Si supponga che una richiesta di supporto invii 6.000 token di input nuovo e generi 800 token di output. Rimane sotto la soglia dei 200K e non beneficia di uno sconto di cache.
- Input: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
- Output: 800 × $4.80 ÷ 1,000,000 = $0.00384
- Totale: $0.01344 per richiesta
A 100.000 richieste al mese, il costo stimato dei token è $1,344. Se la valutazione mostra che una risposta da 400 token rende quanto una da 800 token, la stima scende a $0.01152 per richiesta, ovvero $1,152 al mese. Questo singolo cap dell’output fa risparmiare circa $192 al mese, pari al 14,3%, senza cambiare modello.
Ecco perché il controllo dell’output merita attenzione. Alle tariffe CometAPI indicate, i token di output costano tre volte quelli di input nuovo nello stesso tier.
Esempio pratico 2: riuso di un prefisso stabile da 20K token
Si supponga che ogni richiesta contenga un manuale prodotto da 20.000 token, 2.000 token di nuovo contesto conversazionale e una risposta da 600 token.
Senza cache hit, la stima è:
- 22,000 token di input nuovo: $0.03520
- 600 token di output: $0.00288
- Totale: $0.03808 per richiesta
Se il prefisso stabile da 20.000 token viene fatturato come input in cache mentre solo 2.000 token restano nuovi, la stima diventa:
- 20,000 token di input in cache: $0.00800
- 2,000 token di input nuovo: $0.00320
- 600 token di output: $0.00288
- Totale: $0.01408 per richiesta
A 100.000 richieste, ciò equivale a $1,408 anziché $3,808—un risparmio stimato di $2,400, pari al 63,0%. Il risparmio non è automatico: la prima richiesta, un prefisso modificato o un instradamento che non produce un cache hit possono ancora essere fatturati alla tariffa di input nuovo. Confermate il conteggio dei token in cache nei dati d’uso reali prima di considerare la stima come risparmio conseguito.
Esempio pratico 3: il costo di superare i 200K
Si consideri una richiesta agentica di lunga durata con 210.000 token di prompt e 2.000 token di output. Usando le tariffe long-context indicate:
- 210,000 token di input nuovo: $0.67200
- 2,000 token di output: $0.01920
- Totale: $0.69120 per esecuzione
Se compattazione del contesto, filtraggio del retrieval e checkpoint di sintesi riducono il prompt a 180.000 token preservando lo stesso output di 2.000 token, la stima del tier standard è:
- 180,000 token di input nuovo: $0.28800
- 2,000 token di output: $0.00960
- Totale: $0.29760 per esecuzione
La differenza è $0.39360 per esecuzione, ovvero circa il 56,9%. Su 10.000 esecuzioni, il risparmio stimato è $3,936. La lezione non è eliminare contesto utile. È mantenere solo il contesto che cambia la risposta e sintetizzare o recuperare il resto prima che la richiesta superi una soglia di prezzo.
Un calcolatore Python per stime pre-call
La funzione seguente usa le tariffe attualmente indicate da CometAPI per Grok 4.7. Applica in modo conservativo il tier long-context quando il prompt totale raggiunge 200.000 token.
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")
Questa è una guardia di pianificazione, non una fattura. Il costo finale dipende da input effettivo, input in cache, output, retry, chiamate agli strumenti e dal prezzo attivo al momento dell’esecuzione. Dopo ogni risposta, archiviate l’uso dei token restituiti, l’ID del modello, lo stato della richiesta e l’esito del task. Riconciliate tali valori con i registri di fatturazione del provider.
Cinque leve di costo per Grok 4.7, ordinate per probabile impatto
1. Mantieni stabile il contesto ripetuto per abilitarne la cache
Inserisci istruzioni statiche, documentazione di prodotto, schemi ed esempi riutilizzabili prima dei contenuti specifici della richiesta. Evita di cambiare timestamp, ID, whitespace o ordinamento all’interno di un grande prefisso condiviso a meno che non sia necessario. Le linee guida di xAI per Grok 4.7 raccomandano identificatori di instradamento cache stabili per le conversazioni; quando usi un instradamento intermedio, verifica quali controlli di cache e campi di utilizzo sono supportati prima di farvi affidamento.
Misura i token con cache hit e il tasso di cache hit per carico di lavoro. Uno sconto teorico della cache non vale nulla se l’applicazione muta continuamente il prefisso.
2. Tratta i 200K come un budget ingegneristico, non come un obiettivo
Riserva margine sotto la soglia per istruzioni di sistema, passaggi recuperati, risultati degli strumenti e il turno utente successivo. Per un agente, compatta i turni vecchi in una sintesi validata e conserva il transcript grezzo fuori dal contesto del modello. Per il retrieval, classifica e deduplica i passaggi prima di inserirli invece di inviare ogni corrispondenza.
Traccia le distribuzioni della lunghezza del prompt e genera avvisi prima che la p95 si avvicini alla soglia. Secondo il listino ufficiale di xAI, una volta che un prompt raggiunge i 200K token, le tariffe long-context si applicano a tutti i token di quella richiesta. Anche CometAPI indica un tier long-context separato e più alto per Grok 4.7. Si tratta di termini di prezzo della piattaforma, non di capacità del modello.
3. Limita l’output e calibra lo sforzo di reasoning su un set di valutazione
Imposta un cap dell’output a livello di applicazione coerente con il prodotto. Un risultato di classificazione può richiedere decine di token; una risposta di supporto può richiederne alcune centinaia; un report di ricerca può richiederne di più. Questo cap è un controllo di budget e di esperienza utente, non un limite rigido del modello Grok 4.7. Le note di rilascio di xAI del 21 settembre affermano che Grok 4.7 non ha un limite di output testuale; ciò non impedisce a un’applicazione o a una specifica rotta API di far rispettare un cap di richiesta proprio. Conferma eventuali limiti di richiesta imposti dall’endpoint o dall’SDK con la rotta che utilizzi effettivamente.
Grok 4.7 supporta più livelli di sforzo di reasoning. Usa il livello più basso che supera un set di valutazione rappresentativo e riserva livelli più alti ai task in cui producono un miglioramento misurabile. Ridurre reasoning o output senza controlli di qualità può generare retry e annullare il risparmio.
4. Rifiuta o rimodella richieste costose prima della chiamata API
Stima un upper bound a partire dalla dimensione dell’input e dal cap di output configurato. Se la richiesta supera il budget di prodotto, l’applicazione può chiedere all’utente di restringere il task, sintetizzare il materiale caricato, ridurre il contesto recuperato o spostare il job su un workflow asincrono approvato. Questo è più prevedibile che scoprire il costo dopo la generazione.
Una stima approssimativa caratteri→token può essere utile come guardia iniziale, ma non dovrebbe sostituire un tokenizer o i dati d’uso reali. Lingue, codice, JSON e formattazione possono generare densità di token molto diverse.
5. Ottimizza il costo per task riuscito, non il costo per chiamata
Una chiamata più economica che fallisce due volte la validazione può costare più di una chiamata riuscita. Traccia:
- costo per risposta accettata;
- costo per task agentico completato;
- costo di retry e fallback;
- tasso di cache hit e quota di token in cache;
- token di prompt e output p50 e p95;
- punteggio di qualità, latenza e tasso di escalation umana.
Se il traffico di routine non richiede la qualità o la capacità di contesto di Grok 4.7, il catalogo unificato di modelli di CometAPI può facilitare uno switch di modello gestito dall’applicazione. Mantieni esplicita la regola di routing, valuta ogni modello sullo stesso set di task e invia a questa rotta solo le richieste che traggono beneficio da Grok 4.7.
Una revisione pratica mensile dei costi
Una volta a settimana, raggruppa il traffico per funzionalità e confronta il costo stimato con l’uso effettivo. Inizia con le funzionalità responsabili del maggior numero di token di output, dei prompt più grandi e del tasso di cache hit più basso. Quindi esamina gli outlier costosi invece di ottimizzare alla cieca la richiesta mediana.
| Segnale | Problema probabile | Prima azione |
|---|---|---|
| Quota bassa di token in cache | Il prefisso condiviso cambia troppo spesso | Stabilizza e versiona il contesto riutilizzabile |
| Prompt addensati vicino a 200K | Cronologia o retrieval senza limiti | Compatta, classifica e riserva margine |
| L’output domina la spesa | Le risposte sono più lunghe del necessario | Abbassa il cap e testa la qualità delle risposte |
| Alto costo di retry | Validazione, timeout o prompt instabili | Correggi la modalità di failure alla prima chiamata |
| Basso costo ma scarsa riuscita | L’ottimizzazione ha ridotto qualità utile | Misura il costo per risultato accettato |
Il ruolo di CometAPI nel modello di costo di Grok 4.7
Il ruolo di CometAPI in questo workflow è a livello di piattaforma API: fornisce accesso a Grok 4.7, pubblica le proprie tariffe per token e documenta un punto d’ingresso compatibile con OpenAI. Non cambia le capacità sottostanti del modello Grok 4.7. I team che già usano un client in stile OpenAI possono spesso mantenere lo stesso pattern di client cambiando API key, base URL e ID modello, nel rispetto della compatibilità dell’endpoint.
Al 28 settembre 2026, le tariffe indicate da CometAPI per Grok 4.7 sono inferiori del 20% rispetto alle corrispondenti tariffe dirette xAI sia nel tier standard sia nel tier long-context. Si tratta di un confronto di prezzo tra piattaforme, non di un’affermazione sulla qualità del modello. Prima del rollout in produzione, i team dovrebbero inoltre verificare l’ID modello attivo, i parametri dell’endpoint, il comportamento della cache, i rate limit, l’affidabilità, il supporto e i termini di fatturazione.
Per testare il modello, consulta i prezzi e i dettagli di accesso aggiornati sulla pagina del modello CometAPI Grok 4.7. Mantieni la tabella dei prezzi in configurazione, registra l’uso effettivo dopo ogni chiamata e riesegui le stime del carico di lavoro ogni volta che cambiano il modello o il comportamento del prodotto.
FAQ
Qual è il prezzo per token di Grok 4.7 su CometAPI?
Per prompt sotto i 200K token, CometAPI attualmente indica $1.60 per milione di token di input nuovo, $0.40 per milione di token di input in cache e $4.80 per milione di token di output. Le tariffe long-context indicate sono rispettivamente $3.20, $0.80 e $9.60 per milione di token.
Quanto costa una singola richiesta API di Grok 4.7?
Dipende da input nuovo, input in cache, output e dal tier di contesto attivo. Moltiplica ogni conteggio di token per la relativa tariffa per milione, somma i risultati e dividi per un milione. Includi anche i retry e ogni chiamata al modello in un workflow multi-step.
Qual è il modo più semplice per ridurre i costi dell’API di Grok 4.7?
Inizia dal driver di costo più grande misurato. Istruzioni lunghe ripetute di solito beneficiano della cache; cronologie agentiche crescenti beneficiano della compattazione; risposte verbose beneficiano di un cap di output più basso. Conferma che la qualità resti accettabile dopo ogni modifica.
Una finestra di contesto da 500K significa che dovrei inviare 500K token?
No. La finestra di contesto è un limite di capacità, non una raccomandazione. Sia i prezzi diretti xAI sia l’attuale listing di CometAPI applicano tariffe long-context più alte alla soglia dei 200K token di prompt, quindi le applicazioni dovrebbero inviare solo il contesto necessario al task.
Posso stimare il costo prima di chiamare Grok 4.7?
Sì. Stima i token di input, scegli il tier di contesto corretto, aggiungi un cap di output realistico e calcola l’upper bound. Dopo la chiamata, sostituisci la stima con i dati d’uso effettivi per reporting e ottimizzazione.