Introduzione
Un endpoint di chat compatibile con OpenAI per Grok 4.6 di xAI, dove uno screenshot e la domanda che lo riguarda arrivano nello stesso turno.
Grok 4.6 arriva da xAI e risponde su POST https://api.spicyapi.ai/v1/chat/completions con il nome di modello xai/grok-4.6. La richiesta ha la forma consueta: un array messages con al massimo 256 turni ordinati, un tetto di output, due manopole di campionamento, un elenco di strumenti, un formato di risposta e reasoning_effort per dire quanto il modello lavora prima di scrivere. La finestra tiene 500.000 token e una sola risposta può prenderne 450.000, quindi la fetta più grande del budget sta dal lato della risposta e non dal lato del prompt. Il contenuto accetta parti text e image_url; su questo endpoint non esiste una parte file o PDF, e la modalità è testo e immagini in ingresso, testo in uscita.
Caratteristiche principali
Un'immagine e la frase che la riguarda, nello stesso turno
Il contenuto può essere una stringa semplice o un array di parti, e una parte immagine porta una url più un parametro detail tra auto, low e high. Lo scatto e la domanda arrivano insieme, quindi il modello legge i pixel invece della tua descrizione dei pixel: è tutta lì la differenza quando la risposta dipende da un asse etichettato male, da uno stack trace tagliato sul bordo o da un layout che si rompe solo a una larghezza. Il contenuto delle immagini è conteggiato dentro la finestra da 500.000 token e non accanto ad essa, quindi diversi scatti grandi e una cronologia lunga si contendono lo stesso budget.
Quasi tutto il budget può andare nella risposta
Una sola risposta arriva a 450.000 token, una forma insolita per un modello di chat: gran parte della finestra si può spendere per scrivere invece che per leggere. max_tokens resta comunque a 4.096 come predefinito, quindi una generazione lunga la chiedi e non ci finisci dentro per caso, e un taglio al valore predefinito arriva senza avvisi. reasoning_effort accetta low, medium, high o xhigh e parte da high; lo sforzo si paga in token di output, perciò pesa insieme sul tuo tetto e sulla tua fattura.
Sul percorso non c'è niente di nostro
Tra te e questo modello non mettiamo un classificatore di contenuti nostro. Quello che si rifiuta di scrivere è comportamento suo e non uno strato inserito qui, e quello che invii non viene ispezionato, valutato o riscritto lungo la strada. I diritti sul materiale che invii restano tuoi, e sei tu a rispondere dell'uso che viene fatto della risposta.
Parametri della richiesta
| Parametro | Obbligatorio | Nota |
|---|---|---|
messages | Sì | Al massimo 256 turni. Il contenuto può mescolare parti text e |
reasoning_effort | No | low, medium, high o xhigh; predefinito high. Lo sforzo si paga come output. |
max_tokens | No | Limita la risposta visibile a 450.000; il predefinito di 4.096 tronca in silenzio una risposta lunga. |
temperature | No | Da 0 a 2, predefinito 0,7. Usa 0 quando confronti due mockup o due esecuzioni. |
top_p | No | Da 0,01 a 1. Regola questo valore oppure temperature, non entrambi. |
tools | No | Fino a 128 definizioni di funzione per richiesta. al massimo 128 elementi |
parallel_tool_calls | No | true o false, predefinito true: il modello può chiedere più chiamate agli strumenti nello stesso turno. Predefinito: |
tool_choice | No | auto, none, required, oppure un oggetto che nomina la funzione da chiamare. |
response_format | No | Chiedi un oggetto JSON quando la risposta la legge il codice e non una persona. |
Prezzi
Input $2 / Output $6 per 1 milione di token; Prompt da 200K token in su: Input $4 / Output $12
L'input totale comprende i token in cache. Da 200.000 token di input in su le tariffe a contesto lungo si applicano a tutto l'input, all'input in cache e all'output della richiesta; sotto tale soglia valgono le tariffe standard. L'output comprende i token di ragionamento. Controlla il budget della richiesta prima di inviarla. L'importo bloccato all'inizio non tiene conto di risparmi da cache e il conguaglio restituisce la differenza rispetto all'uso misurato.
Casi d’uso
Fai esaminare uno scatto invece di descriverlo
Manda lo screenshot con detail high accanto alla domanda in un solo messaggio utente e il modello lavora sui pixel: l'etichetta d'asse sbagliata, la riga sparita, il fotogramma tagliato sul bordo. Due scatti a un'ora di distanza nello stesso turno ti lasciano chiedere quale numero si è mosso, invece di chiedere di un riassunto battuto a mano.
Scrivi qualcosa lungo come un libro in una sola chiamata
Porta max_tokens verso 450.000 e la guida alla migrazione, il rapporto lungo o l'intera suite di test torna come una risposta sola invece che come catena di continuazioni, ognuna delle quali perde un pezzo del filo. Con stream: true il testo arriva mentre lo si sta ancora scrivendo.
Tieni leggibile un ciclo con gli strumenti
Dichiara fino a 128 definizioni di funzione, abbinale a tool_choice e restituisci ogni risultato nel turno successivo come messaggio con ruolo tool. Tieni fermo reasoning_effort per tutto il ciclo e tra un'iterazione e l'altra cambia solo la conversazione: è questo che rende la traccia degna di lettura quando il ciclo va storto.
Consegna la risposta al codice, non a una persona
Chiedi un oggetto JSON con response_format e abbassa temperature a 0: la risposta torna come struttura che il tuo parser prende così com'è. Unisci il tutto a una parte immagine e hai l'estrazione diretta da uno scontrino, da un grafico o dallo scatto di un modulo, senza un passaggio di trascrizione in mezzo.
Consigli avanzati
Metti l'immagine dove sta la domanda
Tieni la parte text e le parti image_url dentro lo stesso messaggio utente invece di mandare prima l'immagine e poi la domanda. Di' che cosa vuoi che ne venga letto, se un numero, uno scarto o un verdetto, e nomina il pannello quando ce n'è più di uno: detail high compra risoluzione, non attenzione.
POST https://api.spicyapi.ai/v1/chat/completions
{
"model": "xai/grok-4.6",
"messages": [
{
"role": "user",
"content": [
{"type": "text", "text": "These two captures are an hour apart on the same dashboard. Which metric regressed, and what in the second image explains it?"},
{"type": "image_url", "image_url": {"url": "https://cdn.spicyapi.ai/models/examples/inputs/c681580c3c6a0b63.jpeg", "detail": "high"}},
{"type": "image_url", "image_url": {"url": "https://cdn.spicyapi.ai/models/examples/inputs/59f0bc6291069978.jpeg", "detail": "high"}}
]
}
],
"reasoning_effort": "high",
"max_tokens": 4000
}
Spendi lo sforzo dove cambia la risposta
reasoning_effort parte da high, quindi un campo omesso ti fa già pagare un'impostazione più ponderata e i token di output che la accompagnano. Tieni xhigh per il lavoro che deve essere giusto al primo colpo, usa medium per la revisione ordinaria e scendi a low nei turni brevi e meccanici. Lo sforzo è fatturato come output e condivide il tetto con la risposta stessa, perciò un tetto generoso su xhigh è una richiesta grande in tutti e due i sensi.
Guarda in quale fascia cade la richiesta
Input e input in cache si sommano, e da 200.000 token l'intera richiesta rientra nella fascia a contesto lungo, non solo la parte sopra la soglia. Ridurre una cronologia da 210.000 token a 190.000 cambia quindi più del costo dei token che hai tolto. L'importo bloccato prima della chiamata non presuppone alcun risparmio da cache e il conguaglio restituisce la differenza rispetto al consumo misurato: il numero che vedi all'inizio è un tetto, non il prezzo.
Avvio rapido dell’API
curl --fail-with-body -sN https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"model": "xai/grok-4.6/chat",
"messages": [
{
"role": "user",
"content": "Summarise the following release notes into three bullet points."
}
],
"stream": true
}' \
| jq --unbuffered -Rrj 'select(startswith("data: ")) | .[6:] | select(. != "[DONE]") | fromjson | if .error then "\n[error] \(.error.message)\n" else (.choices[0].delta.content? // empty) end'
Nel riferimento dell’API trovi autenticazione, schema completo, polling e gestione degli errori.
