HiAPI
Blog

Guida all'uso

Ricette di prompt per gpt-6.1-sol: coding, ragionamento, JSON e chiamata di strumenti (con output reali)

Oct 17, 2026
Ricette di prompt per gpt-6.1-sol: coding, ragionamento, JSON e chiamata di strumenti (con output reali)

gpt-6.1-sol è un modello testuale di livello ragionamento su hiapi — conversazione, coding e ragionamento passo passo, tutto erogato tramite la Responses API (POST /v1/responses). Se sai già come chiamarlo, questa pagina è il passo successivo: una serie di ricette di prompt da copiare e incollare, che coprono i quattro tipi di attività che le persone usano davvero più spesso — coding, ragionamento, JSON rigoroso e chiamata di strumenti — e ogni ricetta è accompagnata dall'output esatto che abbiamo ottenuto eseguendola realmente per questo articolo. Per autenticazione, streaming e parsing SSE, parti dalla guida alla configurazione; qui ci concentriamo solo sui prompt stessi.

Ogni ricetta qui sotto è un corpo di richiesta che puoi inserire direttamente in quella configurazione. Il prompt è veicolato da due campi: instructions di primo livello (impostazione del ruolo e regole di formato) e l'array input (l'attività stessa). Qui non c'è nulla di teorico — gli output sono incollati così come sono dagli eventi reali response.completed.

Tre leve che influenzano come scrivi i prompt per gpt-6.1-sol

Prima di entrare nelle ricette, tre cose su questo modello plasmano ogni prompt che scrivi. Tutte e tre sono state confermate rispetto al contratto live del modello su hiapi.

  1. Niente temperature, niente top_p. Questa configurazione di esecuzione li disabilita entrambi (così come max_output_tokens). Non puoi regolare la determinismo o la creatività tramite il campionamento — le uniche manopole disponibili sono i tuoi instructions, il tuo input e reasoning.effort. Se vuoi output concisi e apparentemente deterministici, dichiaralo in instructions; non puoi impostare temperature: 0.
  2. reasoning.effort ha cinque livelli: low, medium, high, xhigh, max (predefinito medium). Un effort più alto consuma più token di ragionamento nascosti — e questi vengono fatturati come token di output. La ricetta 2 mostra la curva reale.
  3. Finestra di contesto di circa 1,05M token (output massimo 128K). La fatturazione per token è a scaglioni: una volta che l'input di una singola richiesta supera i 272K token, le tariffe di input/output raddoppiano circa. Per i prompt quotidiani sei molto lontano da questa soglia; per attività a contesto lungo (ricetta 5), vale la pena saperlo.

Ricetta 1 — Coding: generare una funzione da una specifica

Metti il ruolo di ingegnere e la forma dell'output in instructions, e la specifica in input. Il vincolo sulla forma ("un singolo blocco di codice racchiuso, poi una frase") è esattamente ciò che impedisce a un modello di ragionamento di avvolgere il codice in tre paragrafi di premessa.

{
  "model": "gpt-6.1-sol",
  "instructions": "Sei un ingegnere Python senior. Restituisci un singolo blocco di codice Python racchiuso, poi spiega la complessità in una frase. Nessun preambolo.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "Scrivi `merge_intervals(intervals: list[list[int]]) -> list[list[int]]`, che unisce intervalli chiusi sovrapposti e li restituisce ordinati per punto di inizio. Gestisci la lista vuota. Includi una docstring." }
    ] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

Cosa restituisce (così com'è):

def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
    """Unisce intervalli chiusi sovrapposti e li restituisce ordinati per punto di inizio.

    La lista di input e gli intervalli al suo interno non vengono modificati.
    """
    if not intervals:
        return []

    ordered = sorted(intervals, key=lambda interval: interval[0])
    merged = [ordered[0].copy()]

    for start, end in ordered[1:]:
        if start <= merged[-1][1]:
            merged[-1][1] = max(merged[-1][1], end)
        else:
            merged.append([start, end])

    return merged

Complessità temporale O(n log n), complessità spaziale O(n).

Nota cosa ha prodotto il vincolo: gestisce correttamente il caso della lista vuota, copia ogni intervallo prima di modificarlo (ordered[0].copy()), quindi i dati del chiamante non vengono alterati, e si ferma esattamente dopo una frase di analisi. Per questo tipo di coding meccanico, effort: low è sufficiente — ha usato zero token di ragionamento e ha comunque generato codice corretto e non in-place.

Ricetta 2 — Ragionamento: controllare il budget di pensiero con effort

Poiché non puoi impostare temperature, reasoning.effort è la tua manopola principale per i problemi difficili. Mantieni lo stesso prompt e cambia solo effort:

{
  "model": "gpt-6.1-sol",
  "instructions": "Pensa passo passo, poi termina con una riga `Answer: <value>`.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "Una panetteria vende biscotti in confezioni da 6 e da 11. Qual è il numero massimo di biscotti che non si può comprare esattamente? Mostra il ragionamento." }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

Abbiamo eseguito lo stesso prompt su tutti e cinque i livelli di effort. Ogni livello ha restituito la risposta corretta 49. Ciò che cambia è quanto pensiero ha impiegato per arrivarci:

reasoning.effort Token di ragionamento Token di output totali Costo approssimativo*
low 76 305 ≈ $0.0008
medium 121 380 ≈ $0.0010
high 209 427 ≈ $0.0011
xhigh 626 845 ≈ $0.0021
max 622 813 ≈ $0.0021

*Secondo le tariffe di base ($0.50 / 1M input, $2.50 / 1M output); i token di ragionamento sono fatturati come output. Dati da questa esecuzione, aggiornati a 2026-10. Per le tariffe attuali consulta la pagina dei prezzi.

La lezione pratica è nelle ultime due righe: l'effort sale gradualmente da low a high, poi entra in plateau — xhigh e max si attestano entrambi intorno ai 620 token di ragionamento, perché questo problema semplicemente non è abbastanza difficile da richiedere più pensiero. Portare al massimo l'effort su un prompt semplice non produce risposte migliori; costa solo circa 2,5 volte più token di output per lo stesso "49". Fai corrispondere effort alla difficoltà: low/medium per la maggior parte dei prompt, high e oltre solo quando il compito richiede davvero una ricerca più profonda.

Ecco l'output di medium, così vedi che forma ha prodotto il prompt:

Il numero più grande è 49 biscotti.

1. Dimostrare che 49 non può essere comprato esattamente. Supponiamo 49 = 6a + 11b, con a, b interi non negativi. Prendendo il modulo 6 di entrambi i lati otteniamo 5b ≡ 1 (mod 6), quindi b ≡ 5 (mod 6). Quindi b è almeno 5, ma cinque confezioni da 11 contengono già 55 biscotti. Impossibile.

2. Dimostrare che ogni numero sopra 49 può essere comprato. …Ogni intero almeno pari a 50 è uno dei sei totali raggiungibili consecutivi più un multiplo non negativo di 6.

Answer: 49

La riga Answer: <value> in instructions fa davvero il suo lavoro: ti permette di analizzare semplicemente l'ultima riga (text.rsplit("Answer:", 1)[-1].strip()) senza costringere il modello a scartare il suo processo di ragionamento.

Ricetta 3 — JSON rigoroso con schema

Non chiedere JSON in prosa e poi sperare. gpt-6.1-sol supporta gli output strutturati rigorosi: passa un text.format con json_schema e il modello sarà vincolato a produrre JSON conforme — niente blocchi di codice, niente prosa superflua.

{
  "model": "gpt-6.1-sol",
  "instructions": "Classifica il ticket di supporto. Rispondi solo con l'oggetto JSON.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "Ticket: 'Da stamattina l'endpoint di upscale 4K restituisce 500 a ogni chiamata. Domani pubblichiamo e questo ci blocca.'" }
    ] }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "ticket",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
          "topics": { "type": "array", "items": { "type": "string" } },
          "action_required": { "type": "boolean" }
        },
        "required": ["sentiment", "topics", "action_required"],
        "additionalProperties": false
      }
    }
  },
  "reasoning": { "effort": "low" },
  "stream": true
}

Cosa restituisce (così com'è, su una sola riga):

{"action_required":true,"sentiment":"negative","topics":["4K upscale endpoint","HTTP 500 errors","Service outage","Launch blocker","Urgent support"]}

Due cose da interiorizzare. Primo, strict: true garantisce tipi e chiavi obbligatorie, ma non garantisce l'ordine delle chiavi — nota che action_required appare per primo, anche se nello schema è elencato per ultimo, quindi analizza per chiave, mai per posizione. Secondo, devi comunque accumulare la risposta dai blocchi response.output_text.delta come per qualsiasi altra risposta; lo schema plasma il contenuto, non il trasporto.

Ricetta 4 — Chiamata di strumenti e continuazione con il risultato

gpt-6.1-sol può chiamare funzioni e — cosa importante — continuare dopo che restituisci il risultato. Dichiara un array tools; quando il modello decide di chiamare, emette un elemento function_call invece di testo.

{
  "model": "gpt-6.1-sol",
  "instructions": "Puoi chiamare strumenti. Quando l'utente chiede di un'attività, chiama get_task_status.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "Puoi controllare come sta task_abc123? È in pending da molto tempo." }
    ] }
  ],
  "tools": [
    {
      "type": "function",
      "name": "get_task_status",
      "description": "Interroga lo stato di un'attività di generazione asincrona di immagini/video tramite id.",
      "parameters": {
        "type": "object",
        "properties": { "task_id": { "type": "string", "description": "Id dell'attività, ad esempio 'task_abc123'." } },
        "required": ["task_id"],
        "additionalProperties": false
      }
    }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

La risposta non contiene testo — solo una chiamata di strumento, veicolata come elemento function_call nell'evento finale (i suoi argomenti arrivano in streaming tramite blocchi response.function_call_arguments.delta):

{
  "type": "function_call",
  "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b",
  "name": "get_task_status",
  "arguments": "{\"task_id\":\"task_abc123\"}"
}

Ora la seconda metà che la configurazione di base non copre: esegui la tua funzione, poi restituisci il risultato — aggiungi il function_call del modello e il tuo function_call_output (associato con lo stesso call_id) all'array input, poi chiama di nuovo:

{
  "model": "gpt-6.1-sol",
  "instructions": "Puoi chiamare strumenti. Riassumi il risultato dello strumento per l'utente in una o due frasi.",
  "input": [
    { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "Puoi controllare come sta task_abc123? È in pending da molto tempo." } ] },
    { "type": "function_call", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "name": "get_task_status", "arguments": "{\"task_id\":\"task_abc123\"}" },
    { "type": "function_call_output", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "output": "{\"status\":\"failed\",\"error\":\"INVALID_REQUEST: image url could not be downloaded\",\"created_at\":\"2026-10-17T06:12:00Z\"}" }
  ],
  "tools": [ { "type": "function", "name": "get_task_status", "description": "Interroga lo stato di un'attività di generazione asincrona tramite id.", "parameters": { "type": "object", "properties": { "task_id": { "type": "string" } }, "required": ["task_id"], "additionalProperties": false } } ],
  "reasoning": { "effort": "low" },
  "stream": true
}

Una volta ottenuto il risultato, risponde in linguaggio naturale (così com'è):

L'attività task_abc123 non è più in stato pending — è fallita perché l'URL dell'immagine non poteva essere scaricato (INVALID_REQUEST). Verifica che l'URL dell'immagine sia accessibile pubblicamente, poi invia di nuovo l'attività.

call_id è il collante: il tuo function_call_output deve riportare esattamente il call_id del function_call del modello, altrimenti il turno successivo non vi si lega.

Ricetta 5 — Risposte fondate su contesto lungo

La finestra da 1,05M token serve a nutrire materiale reale — log, changelog, documenti di specifica — e a rispondere a domande in base a esso. Il modello di prompt che lo mantiene onesto sta in instructions: obbligalo a rispondere solo in base al testo fornito e a citare la fonte di ogni fatto.

{
  "model": "gpt-6.1-sol",
  "instructions": "Rispondi rigorosamente in base al CHANGELOG fornito. Se un fatto non esiste, scrivi 'not in the changelog'. Cita la data di ogni fatto che usi.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "<incolla qui il CHANGELOG>\nDomanda: l'URL di output di un'attività video mi ha restituito il file ieri, ma oggi dà 404, e in più le chiamate immagine hanno appena iniziato a restituire 402. Quali due voci di changelog spiegano questo, e cosa dovrei cambiare?" }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

Dato un breve changelog della piattaforma, ha estratto accuratamente le due voci rilevanti, ne ha citato le date e ha separato "cosa è successo" da "cosa cambiare" (così com'è):

Due voci spiegano i problemi:

1. 2026-10-02 — Gli URL di output temporanei scadono. Gli URL di output su temp.hiapi.ai sono validi per 7 giorni, dopodiché restituiscono 404… Cosa cambiare: scarica subito i byte e conserva una tua copia; non fare hotlink. Usa expireAt per tracciare la scadenza.

2. 2026-09-20 — Saldo a zero attiva 402 sui modelli immagine. Gli account con saldo completamente a zero ora ricevono HTTP 402 su tutti i modelli immagine… Cosa cambiare: verifica se il saldo del tuo account è completamente a zero e, in tal caso, ricarica.

L'istruzione "cita le date" è un trucco economico per la fondatezza: rende visibili le allucinazioni (un fatto senza data da indicare è un fatto inventato) e rende le risposte verificabili. Tieni presente la tariffazione a scaglioni — i prompt con input oltre i 272K token sono fatturati alla tariffa più alta per contesto lungo.

Una trappola di questa esecuzione: decodificare lo stream come UTF-8

I modelli di ragionamento amano le em dash e le virgolette curve. Al momento della scrittura, il nostro primo lettore SSE divideva i caratteri UTF-8 multibyte tra due chunk di rete, trasformando una bella em dash ("—") in caratteri corrotti ("â"). L'output del modello andava bene; era il client a decodificare per riga troppo frettolosamente. La correzione è memorizzare i byte grezzi, dividere sui newline e decodificare ogni riga completa in UTF-8 — non decodificare blocchi incompleti. Se nell'output di gpt-6.1-sol compaiono caratteri sparsi Ã/â, la causa è qui, non il modello.

Domande frequenti

In cosa è diverso dalla guida alla configurazione di gpt-6.1-sol? La guida alla configurazione parla di come chiamare il modello — autenticazione, perché lo streaming è obbligatorio, parsing SSE. Questa pagina parla di come promptarlo — pattern di instructions/input/effort per attività concrete, e gli output che producono.

Posso semplicemente portare reasoning.effort a max per ottenere le risposte migliori? Non è gratis, e spesso non è nemmeno per il meglio. Sul nostro problema di test, xhigh e max sono entrambi entrati in plateau intorno ai 620 token di ragionamento, restituendo la stessa risposta di high. I token di ragionamento sono fatturati come output, quindi portare al massimo un prompt semplice costa di più per lo stesso risultato. Riserva high+ ai ragionamenti davvero difficili.

Come forzo un JSON valido invece di chiederlo nel prompt? Passa un text.format con un json_schema strict (ricetta 3). Il modello sarà vincolato ai tipi e alle chiavi obbligatorie dello schema. Analizza per nome di chiave, perché strict non fissa l'ordine delle chiavi.

Perché non posso impostare temperature o top_p? Questa configurazione di esecuzione li disabilita entrambi (così come max_output_tokens). Plasma invece l'output tramite instructions, il tuo input e reasoning.effort.

La chiamata di strumenti funziona allo stesso modo dei modelli di chat? Il contratto è leggermente diverso: gli strumenti sono dichiarati nell'array tools di primo livello, il modello risponde con un elemento function_call (non un messaggio), e tu continui aggiungendo un function_call_output con call_id corrispondente (ricetta 4).

gpt-6.1-sol è uguale a gpt-5.6-sol? Appartengono alla stessa famiglia Sol e condividono questo contratto Responses-API, solo streaming; gpt-6.1-sol è una generazione più recente. Vedi il confronto tra gpt-6 Astra e gpt-5.6 Sol per capire come si corrispondono le varie generazioni.

Da dove iniziare

Copia qualsiasi ricetta qui sopra nel corpo della richiesta della guida alla configurazione, sostituisci con la tua attività e regola reasoning.effort in base alla difficoltà. La presentazione delle capacità e la casella di prova online sono nella pagina del modello gpt-6.1-sol; l'endpoint e il formato di richiesta condiviso sono nella documentazione API; le tariffe per token sono nella pagina dei prezzi. Una chiave hiapi dà accesso a gpt-6.1-sol e a tutti gli altri modelli della piattaforma.

Inizia a creare con artefatti IA persistenti

Ottieni la tua chiave API e chiama modelli di immagini, video e audio tramite un'unica API basata sui task.

Leggi la documentazione API