Z.ai GLM 5.3 è un modello di ragionamento testuale su larga scala, progettato per ingegneria del software complessa e attività prolungate degli agenti. Il produttore afferma che utilizza lo stesso modello di base di GLM 5.2 e che i nuovi miglioramenti derivano dall'addestramento successivo. La versione si concentra su capacità potenziate di programmazione, operazioni da terminale e compiti più ampi che coinvolgono più passaggi dipendenti tra loro. Accetta testo e produce testo, inclusi codice, spiegazioni, piani e richieste di chiamata a strumenti in un'applicazione collegata a strumenti.
La modalità di ragionamento documentata è sempre attiva. GLM 5.3 offre tre livelli di impegno: low, high e max, con max come valore predefinito. Il produttore raccomanda max per la programmazione complessa; low offre un'opzione di ragionamento più leggera per i passaggi semplici. Usa il livello selezionato insieme a un elaborato finale chiaro e a criteri di completamento. Per esempio: «Esamina questi file e gli esiti negativi, risali alla causa nei moduli coinvolti, proponi una correzione che preservi l'interfaccia pubblica e spiega quali verifiche dimostrano la risoluzione della regressione».
Il produttore specifica una finestra di contesto di 1M token e una lunghezza massima di output di 128K token. Organizza il materiale esteso attorno alla relazione che il modello deve indagare. Conserva nomi dei file, definizioni pertinenti, etichette delle fonti e ordine delle osservazioni, lasciando spazio al ragionamento e alla risposta finale entro il contesto di lavoro applicabile. Una finestra ampia è utile per dipendenze tra moduli o lunghe sequenze di osservazioni di un agente; non trasforma un archivio privo di direzione e composto da materiale non correlato in un compito ben definito.
Per il lavoro su un repository, fornisci il comportamento atteso, il testo sorgente pertinente, le versioni delle dipendenze e l'output effettivo degli errori. Chiedi al modello di identificare il comportamento coinvolto prima di proporre una modifica. Per una ristrutturazione del codice, nomina l'interfaccia e le invarianti che devono rimanere intatte. Una risposta utile contiene il codice rivisto, il motivo per cui la modifica affronta il problema osservato e i casi necessari per verificarne l'esito. Riporta i risultati effettivi nel flusso collegato agli strumenti, affinché il passaggio successivo si basi sullo stato modificato anziché sulla proposta precedente.
Per il lavoro sulle prestazioni, fornisci un carico di lavoro, un riferimento iniziale e misurazioni come tempi, profili di esecuzione o registri delle allocazioni. Z.ai descrive compiti di addestramento che coinvolgono diagnosi dei colli di bottiglia, ottimizzazione, esperimenti e risultati che preservano la correttezza. Una richiesta pratica è: «Usa questo profilo per identificare il collo di bottiglia più rilevante, proponi una modifica misurabile e spiega quale risultato ne giustificherebbe il mantenimento». Distingui un'ipotesi sulle prestazioni da un miglioramento registrato. Mantieni lo stesso carico e le condizioni pertinenti nell'esaminare un risultato.
La versione sviluppa anche capacità di analisi delle vulnerabilità. Per una revisione difensiva del sorgente, fornisci il codice pertinente, i confini di fiducia previsti e le condizioni in cui viene eseguito. Richiedi un riscontro che colleghi un problema sospetto all'input interessato, al comportamento e a una correzione mirata. Distingui una debolezza potenziale da un difetto riprodotto e conserva l'osservazione usata per convalidarlo. Una relazione è più utile quando dà priorità a evidenze concrete e correzioni proposte, anziché trattare ogni schema sospetto come una vulnerabilità confermata.
Le chiamate a funzioni consentono a un'applicazione circostante di esporre operazioni esterne al modello. Definisci lo scopo, gli argomenti e il risultato atteso di ogni strumento, quindi restituisci l'osservazione effettiva dello strumento per il passaggio successivo. Il modello può ragionare su tale risultato e stabilire come cambi il compito. Mantieni distinguibili azioni proposte, operazioni eseguite e verifiche irrisolte. Il produttore documenta anche risposte in streaming che restituiscono separatamente frammenti di ragionamento e di risposta; ricomponi la risposta completa prima di considerarla la relazione finale o la spiegazione del codice.
La scheda locale del modello fornisce un dettaglio specifico sulla gestione della cronologia: il template di chat conserva il ragionamento per impostazione predefinita, mentre il produttore raccomanda di cancellare esplicitamente il ragionamento precedente negli scenari di chat ordinaria. Applica la struttura conversazionale adatta al caso d'uso, preservando le risposte effettivamente completate e i risultati degli strumenti necessari per proseguire. Evita di considerare intercambiabili le impostazioni di controllo del ragionamento di GLM 5.2 o delle edizioni separate GLM 5.3 Flash con i controlli low/high/max di questo modello.
Per risultati strutturati, specifica campi, tipi e regole relative alle fonti. Un elaborato utile può essere una tabella dei difetti, un piano di modifiche o un oggetto JSON che riepiloga le osservazioni. Convalida sia la struttura sia i valori prima che un'applicazione li utilizzi. Il risultato finale deve identificare la risposta o l'elaborato rivisto, le evidenze a sostegno e le ipotesi residue. Un maggiore impegno di ragionamento non dimostra che uno strumento sia stato eseguito, che una modifica proposta abbia superato le verifiche o che un'affermazione fattuale disponga di supporto oltre il materiale fornito.
", "aboutText": "Z.ai GLM 5.3 è un modello di ragionamento testuale su larga scala, progettato per ingegneria del software complessa e attività prolungate degli agenti. Il produttore afferma che utilizza lo stesso modello di base di GLM 5.2 e che i nuovi miglioramenti derivano dall'addestramento successivo. La versione si concentra su capacità potenziate di programmazione, operazioni da terminale e compiti più ampi che coinvolgono più passaggi dipendenti tra loro. Accetta testo e produce testo, inclusi codice, spiegazioni, piani e richieste di chiamata a strumenti in un'applicazione collegata a strumenti.\n\nLa modalità di ragionamento documentata è sempre attiva. GLM 5.3 offre tre livelli di impegno: low, high e max, con max come valore predefinito. Il produttore raccomanda max per la programmazione complessa; low offre un'opzione di ragionamento più leggera per i passaggi semplici. Usa il livello selezionato insieme a un elaborato finale chiaro e a criteri di completamento. Per esempio: «Esamina questi file e gli esiti negativi, risali alla causa nei moduli coinvolti, proponi una correzione che preservi l'interfaccia pubblica e spiega quali verifiche dimostrano la risoluzione della regressione».\n\nIl produttore specifica una finestra di contesto di 1M token e una lunghezza massima di output di 128K token. Organizza il materiale esteso attorno alla relazione che il modello deve indagare. Conserva nomi dei file, definizioni pertinenti, etichette delle fonti e ordine delle osservazioni, lasciando spazio al ragionamento e alla risposta finale entro il contesto di lavoro applicabile. Una finestra ampia è utile per dipendenze tra moduli o lunghe sequenze di osservazioni di un agente; non trasforma un archivio privo di direzione e composto da materiale non correlato in un compito ben definito.\n\nPer il lavoro su un repository, fornisci il comportamento atteso, il testo sorgente pertinente, le versioni delle dipendenze e l'output effettivo degli errori. Chiedi al modello di identificare il comportamento coinvolto prima di proporre una modifica. Per una ristrutturazione del codice, nomina l'interfaccia e le invarianti che devono rimanere intatte. Una risposta utile contiene il codice rivisto, il motivo per cui la modifica affronta il problema osservato e i casi necessari per verificarne l'esito. Riporta i risultati effettivi nel flusso collegato agli strumenti, affinché il passaggio successivo si basi sullo stato modificato anziché sulla proposta precedente.\n\nPer il lavoro sulle prestazioni, fornisci un carico di lavoro, un riferimento iniziale e misurazioni come tempi, profili di esecuzione o registri delle allocazioni. Z.ai descrive compiti di addestramento che coinvolgono diagnosi dei colli di bottiglia, ottimizzazione, esperimenti e risultati che preservano la correttezza. Una richiesta pratica è: «Usa questo profilo per identificare il collo di bottiglia più rilevante, proponi una modifica misurabile e spiega quale risultato ne giustificherebbe il mantenimento». Distingui un'ipotesi sulle prestazioni da un miglioramento registrato. Mantieni lo stesso carico e le condizioni pertinenti nell'esaminare un risultato.\n\nLa versione sviluppa anche capacità di analisi delle vulnerabilità. Per una revisione difensiva del sorgente, fornisci il codice pertinente, i confini di fiducia previsti e le condizioni in cui viene eseguito. Richiedi un riscontro che colleghi un problema sospetto all'input interessato, al comportamento e a una correzione mirata. Distingui una debolezza potenziale da un difetto riprodotto e conserva l'osservazione usata per convalidarlo. Una relazione è più utile quando dà priorità a evidenze concrete e correzioni proposte, anziché trattare ogni schema sospetto come una vulnerabilità confermata.\n\nLe chiamate a funzioni consentono a un'applicazione circostante di esporre operazioni esterne al modello. Definisci lo scopo, gli argomenti e il risultato atteso di ogni strumento, quindi restituisci l'osservazione effettiva dello strumento per il passaggio successivo. Il modello può ragionare su tale risultato e stabilire come cambi il compito. Mantieni distinguibili azioni proposte, operazioni eseguite e verifiche irrisolte. Il produttore documenta anche risposte in streaming che restituiscono separatamente frammenti di ragionamento e di risposta; ricomponi la risposta completa prima di considerarla la relazione finale o la spiegazione del codice.\n\nLa scheda locale del modello fornisce un dettaglio specifico sulla gestione della cronologia: il template di chat conserva il ragionamento per impostazione predefinita, mentre il produttore raccomanda di cancellare esplicitamente il ragionamento precedente negli scenari di chat ordinaria. Applica la struttura conversazionale adatta al caso d'uso, preservando le risposte effettivamente completate e i risultati degli strumenti necessari per proseguire. Evita di considerare intercambiabili le impostazioni di controllo del ragionamento di GLM 5.2 o delle edizioni separate GLM 5.3 Flash con i controlli low/high/max di questo modello.\n\nPer risultati strutturati, specifica campi, tipi e regole relative alle fonti. Un elaborato utile può essere una tabella dei difetti, un piano di modifiche o un oggetto JSON che riepiloga le osservazioni. Convalida sia la struttura sia i valori prima che un'applicazione li utilizzi. Il risultato finale deve identificare la risposta o l'elaborato rivisto, le evidenze a sostegno e le ipotesi residue. Un maggiore impegno di ragionamento non dimostra che uno strumento sia stato eseguito, che una modifica proposta abbia superato le verifiche o che un'affermazione fattuale disponga di supporto oltre il materiale fornito.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "4148765232c04c8a227806e7302a14987ca3c5dc4e97c9f0f2f0787173f96a4a", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "it", "methods": [ { "html": "z-ai/glm-5.3:batchZ.ai GLM 5.3 è un modello di ragionamento testuale per ingegneria del software complessa, lavoro da terminale e agenti impegnati in attività prolungate. Supporta un contesto di 1M token documentato dal produttore, un massimo di 128K token di output, chiamate a funzioni e livelli di ragionamento low/high/max, con il ragionamento sempre attivo.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
Z.ai GLM 5.3 è un modello di ragionamento testuale su larga scala, progettato per ingegneria del software complessa e attività prolungate degli agenti. Il produttore afferma che utilizza lo stesso modello di base di GLM 5.2 e che i nuovi miglioramenti derivano dall'addestramento successivo. La versione si concentra su capacità potenziate di programmazione, operazioni da terminale e compiti più ampi che coinvolgono più passaggi dipendenti tra loro. Accetta testo e produce testo, inclusi codice, spiegazioni, piani e richieste di chiamata a strumenti in un'applicazione collegata a strumenti.
La modalità di ragionamento documentata è sempre attiva. GLM 5.3 offre tre livelli di impegno: low, high e max, con max come valore predefinito. Il produttore raccomanda max per la programmazione complessa; low offre un'opzione di ragionamento più leggera per i passaggi semplici. Usa il livello selezionato insieme a un elaborato finale chiaro e a criteri di completamento. Per esempio: «Esamina questi file e gli esiti negativi, risali alla causa nei moduli coinvolti, proponi una correzione che preservi l'interfaccia pubblica e spiega quali verifiche dimostrano la risoluzione della regressione».
Il produttore specifica una finestra di contesto di 1M token e una lunghezza massima di output di 128K token. Organizza il materiale esteso attorno alla relazione che il modello deve indagare. Conserva nomi dei file, definizioni pertinenti, etichette delle fonti e ordine delle osservazioni, lasciando spazio al ragionamento e alla risposta finale entro il contesto di lavoro applicabile. Una finestra ampia è utile per dipendenze tra moduli o lunghe sequenze di osservazioni di un agente; non trasforma un archivio privo di direzione e composto da materiale non correlato in un compito ben definito.
Per il lavoro su un repository, fornisci il comportamento atteso, il testo sorgente pertinente, le versioni delle dipendenze e l'output effettivo degli errori. Chiedi al modello di identificare il comportamento coinvolto prima di proporre una modifica. Per una ristrutturazione del codice, nomina l'interfaccia e le invarianti che devono rimanere intatte. Una risposta utile contiene il codice rivisto, il motivo per cui la modifica affronta il problema osservato e i casi necessari per verificarne l'esito. Riporta i risultati effettivi nel flusso collegato agli strumenti, affinché il passaggio successivo si basi sullo stato modificato anziché sulla proposta precedente.
Per il lavoro sulle prestazioni, fornisci un carico di lavoro, un riferimento iniziale e misurazioni come tempi, profili di esecuzione o registri delle allocazioni. Z.ai descrive compiti di addestramento che coinvolgono diagnosi dei colli di bottiglia, ottimizzazione, esperimenti e risultati che preservano la correttezza. Una richiesta pratica è: «Usa questo profilo per identificare il collo di bottiglia più rilevante, proponi una modifica misurabile e spiega quale risultato ne giustificherebbe il mantenimento». Distingui un'ipotesi sulle prestazioni da un miglioramento registrato. Mantieni lo stesso carico e le condizioni pertinenti nell'esaminare un risultato.
La versione sviluppa anche capacità di analisi delle vulnerabilità. Per una revisione difensiva del sorgente, fornisci il codice pertinente, i confini di fiducia previsti e le condizioni in cui viene eseguito. Richiedi un riscontro che colleghi un problema sospetto all'input interessato, al comportamento e a una correzione mirata. Distingui una debolezza potenziale da un difetto riprodotto e conserva l'osservazione usata per convalidarlo. Una relazione è più utile quando dà priorità a evidenze concrete e correzioni proposte, anziché trattare ogni schema sospetto come una vulnerabilità confermata.
Le chiamate a funzioni consentono a un'applicazione circostante di esporre operazioni esterne al modello. Definisci lo scopo, gli argomenti e il risultato atteso di ogni strumento, quindi restituisci l'osservazione effettiva dello strumento per il passaggio successivo. Il modello può ragionare su tale risultato e stabilire come cambi il compito. Mantieni distinguibili azioni proposte, operazioni eseguite e verifiche irrisolte. Il produttore documenta anche risposte in streaming che restituiscono separatamente frammenti di ragionamento e di risposta; ricomponi la risposta completa prima di considerarla la relazione finale o la spiegazione del codice.
La scheda locale del modello fornisce un dettaglio specifico sulla gestione della cronologia: il template di chat conserva il ragionamento per impostazione predefinita, mentre il produttore raccomanda di cancellare esplicitamente il ragionamento precedente negli scenari di chat ordinaria. Applica la struttura conversazionale adatta al caso d'uso, preservando le risposte effettivamente completate e i risultati degli strumenti necessari per proseguire. Evita di considerare intercambiabili le impostazioni di controllo del ragionamento di GLM 5.2 o delle edizioni separate GLM 5.3 Flash con i controlli low/high/max di questo modello.
Per risultati strutturati, specifica campi, tipi e regole relative alle fonti. Un elaborato utile può essere una tabella dei difetti, un piano di modifiche o un oggetto JSON che riepiloga le osservazioni. Convalida sia la struttura sia i valori prima che un'applicazione li utilizzi. Il risultato finale deve identificare la risposta o l'elaborato rivisto, le evidenze a sostegno e le ipotesi residue. Un maggiore impegno di ragionamento non dimostra che uno strumento sia stato eseguito, che una modifica proposta abbia superato le verifiche o che un'affermazione fattuale disponga di supporto oltre il materiale fornito.
POST /v1/batchestexttext| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campoendpoint | Tipostring | RequisitoObbligatorio | Valori e limiti /v1/chat/completions | Predefinito— |
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti z-ai/glm-5.3:batch | Predefinito— |
Camporequests | Tipobatch_item[] | RequisitoObbligatorio | Valori e limiti Numero minimo di elementi: 1 | Predefinito— |
Camporequests[].custom_id | Tipostring | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Camporequests[].body.messages | Tipomessage[] | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campocompletion_window | Tipostring | RequisitoFacoltativo | Valori e limiti 24h | Predefinito— |
Campoprovider | Tipoobject|null | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Camporequests[].body.model | Tipostring | RequisitoFacoltativo | Valori e limiti z-ai/glm-5.3:batch, z-ai/glm-5.3 | Predefinito— |
Campoprovider.only | Tipostring[] | RequisitoFacoltativo | Valori e limiti deepinfra/fp4 | Predefinito— |
Campoprovider.allow_fallbacks | Tipoboolean|null | RequisitoFacoltativo | Valori e limiti false, null | Predefinito— |
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattoendpoint, model, requests |
Parametromaterial_types | Contrattotext |
Parametrorepresentation | Contrattorequests[] inline; ogni elemento contiene custom_id e body |
Parametrorequest_endpoint_profile | Contratto/v1/chat/completions |
Parametrofile_material | ContrattoIl chiamante può leggere localmente i dati JSONL effettivi in UTF-8 e inserirli in requests[]. Non viene usato alcun purpose di caricamento, input_file_id o riferimento a file. Il materiale del cliente mancante o vuoto interrompe la preparazione prima del POST. |
Parametroserialization_order | Contrattoendpoint, model, provider (se fornito), completion_window (se fornito), requests per ultimo |
Parametrooptional_controls | Contrattoprovider.only, provider.allow_fallbacks, completion_window |
Parametroschema_scope | ContrattoCorpi delle richieste Chat Completions per testo nella struttura inline Batch documentata. |
Ciclo di vita: asynchronous
GET /v1/batches/{operation_id} · response.id effettivo della risposta alla creazione originale; stesso utente/chiave/gruppo
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
Associa ogni costo alle condizioni indicate. Usa una sola tariffa per ogni insieme di configurazioni alternative.
| Configurazione | Listino delle tariffe | Token di contesto, più di | Token di contesto, fino al limite incluso | Costo |
|---|---|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Token di contesto, più di— | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.0009 / 1K token Output · Token in output $0.004 / 1K token Input · Lettura dalla cache $0.0002 / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
| ConfigurazioneFascia 1 di lunghezza della richiesta | Listino delle tariffe— | Token di contesto, più di0 | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.0009 / 1K token Output · Token in output $0.004 / 1K token Input · Lettura dalla cache $0.0002 / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json\nfrom pathlib import Path\nbody=json.loads('{"endpoint":"/v1/chat/completions","model":"z-ai/glm-5.3:batch","requests":[{"custom_id":"req-0001","body":{"messages":[{"role":"user","content":"Hello!"}],"max_tokens":16}}]}')\nPath("batch-request.json").write_text(json.dumps(body,ensure_ascii=False),encoding="utf-8")\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/batches \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @batch-request.json -D batch-response-headers.txt -o batch-create-response.json\nimport json, os\nfrom pathlib import Path\nfrom urllib.request import Request, urlopen\n\ndef prepare_requests(customer_path):\n path = Path(customer_path)\n if not path.is_file(): raise ValueError("Customer JSONL file is missing")\n items = [json.loads(line) for line in path.read_text(encoding="utf-8").splitlines() if line.strip()]\n if not items: raise ValueError("Customer JSONL contains no requests")\n ids = set()\n for item in items:\n if set(item) != {"custom_id", "body"}: raise ValueError("Each item needs custom_id and body")\n cid = item["custom_id"]\n if not isinstance(cid, str) or not cid.strip() or cid in ids: raise ValueError("custom_id must be nonempty and unique")\n ids.add(cid)\n if not isinstance(item["body"], dict) or not item["body"].get("messages"): raise ValueError("Supply actual text messages")\n supplied_model = item["body"].get("model")\n if supplied_model is not None and supplied_model not in ['z-ai/glm-5.3:batch', 'z-ai/glm-5.3']: raise ValueError("body.model must be an exact documented caller or wire ID")\n return {"endpoint":"/v1/chat/completions", "model":"z-ai/glm-5.3:batch", "requests":items}\n\nif __name__ == "__main__":\n material = os.environ.get("AILOOT_BATCH_REQUESTS_JSONL", "")\n if not material: raise SystemExit("Set AILOOT_BATCH_REQUESTS_JSONL to your actual customer file")\n body = prepare_requests(material)\n key = os.environ.get("AILOOT_API_KEY", "")\n if not key: raise SystemExit("Set AILOOT_API_KEY")\n request = Request("https://api.ailoot.ai/v1/batches", data=json.dumps(body, ensure_ascii=False).encode("utf-8"), headers={"Authorization":"Bearer " + key, "Content-Type":"application/json"}, method="POST")\n with urlopen(request) as response:\n raw = response.read()\n Path("batch-create-response.json").write_bytes(raw)\n print(raw.decode("utf-8"))\nimport json\nfrom pathlib import Path\nraw = Path("batch-status-response.json").read_bytes()\nresponse = json.loads(raw)\nif response.get("status") != "completed":\n raise SystemExit("Keep the original operation; read its status without resubmitting")\nresults = response.get("results")\nif not isinstance(results, list) or not results:\n raise SystemExit("Preserve the original response; completed results are missing")\nPath("batch-results.jsonl").write_text("".join(json.dumps(item, ensure_ascii=False) + "\\n" for item in results), encoding="utf-8")\n# Preserve batch-status-response.json with aggregate usage and every result/error.\nJSON inline di results[].response.body
GET /v1/batches/{operation_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nBATCH_OPERATION_ID="$(python3 - <<'PY_ID'\nimport json\nfrom pathlib import Path\nfrom urllib.parse import quote\nresponse = json.loads(Path("batch-create-response.json").read_text(encoding="utf-8"))\noperation = response.get("id")\nif not isinstance(operation, str) or not operation: raise SystemExit("No actual original operation ID; preserve the response and do not resubmit")\nprint(quote(operation, safe=""))\nPY_ID\n)"\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/batches/$BATCH_OPERATION_ID" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o batch-status-response.json\nConserva ogni risposta, file e parte di contenuto restituiti per intero.
Conserva il JSON completo dello stato originale, ogni result/custom_id e il corpo completo della risposta o dell'errore. Salva i results[] completati come JSONL senza filtrarli.
Conserva l'ID dell'operazione originale. La risposta 503 result_pending_check contiene X-Should-Retry:false; non reinviare mai un batch originale il cui esito è sconosciuto.
| Campo | Tipo |
|---|---|
Camporesults[].custom_id | Tipostring |
Camporesults[].response.body.choices[].message.content | Tipostring|null |
Camporesults[].error | Tipoobject|null |
Campousage | Tipoobject|null |
Campoid | Tipostring |
Campomodel | Tipostring |
Campoendpoint | Tipostring |
Campostatus | Tipostring |
Camporequest_counts | Tipoobject |
Camporesults[].id | Tipostring |
Camporesults[].response.status_code | Tipointeger |
Camporesults[].response.request_id | Tipostring |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneStruttura inline documentata non valida, chiavi duplicate, identità degli elementi non valida o conflitto con le capacità configurate del modello. | Passaggio successivoCorreggi i campi indicati prima di qualsiasi nuovo invio. |
Risposta401 · authentication_error | CondizioneChiave API non valida. | Passaggio successivoUsa la chiave Ailoot autorizzata. |
Risposta403 · permission_error | CondizioneGruppo Batch non disponibile. | Passaggio successivoVerifica le autorizzazioni della chiave e del gruppo. |
Risposta422 · invalid_request_error | CondizioneBatch usa l'addebito sul saldo; la creazione tramite abbonamento viene rifiutata. | Passaggio successivoUsa il gruppo autorizzato con addebito sul saldo. |
Risposta422 · price_unavailable | CondizioneNon è possibile formulare un preventivo per l'input Batch. | Passaggio successivoConserva la risposta; usa l'input documentato per la famiglia. |
Risposta402 · billing_error | CondizioneRiserva Batch non disponibile. | Passaggio successivoRisolvi le condizioni di ammissione prima di una nuova richiesta. |
Risposta503 · price_unavailable | CondizionePrezzo del metodo Batch o tariffe native non disponibili. | Passaggio successivoConserva la risposta; non sostituire i prezzi. |
Risposta503 · api_error | CondizioneLa rotta esatta del fornitore non è disponibile. | Passaggio successivoConserva la risposta per la riparazione della rotta. |
Risposta503 · result_pending_check | CondizioneIl risultato originale richiede una verifica; X-Should-Retry:false. | Passaggio successivoConserva operation_id/id originale e leggine lo stato; non ripetere mai il POST originale. |
Risposta404 · not_found | CondizioneL'operazione di stato Batch è assente o appartiene a un'altra identità. | Passaggio successivoUsa l'id originale esatto e lo stesso utente/chiave/gruppo. |
Ailoot Ultra z-ai/glm-5.3:batch
Usa i percorsi dei metodi indicati sopra.