Z.ai GLM 5.3 er en storskala tekstbasert resonneringsmodell utviklet for kompleks programvareutvikling og langvarig agentarbeid. Produsenten oppgir at den bruker samme basismodell som GLM 5.2, og at de nye forbedringene kommer fra ettertrening. Utgivelsen vektlegger sterkere programmering, terminaloperasjoner og bredere oppgaver som omfatter flere avhengige trinn. Den tar imot tekst og produserer tekst, inkludert kode, forklaringer, planer og forespørsler om verktøykall i en applikasjon som er koblet til verktøy.
Den dokumenterte resonneringsmodusen er alltid aktivert. GLM 5.3 tilbyr tre innsatsnivåer: low, high og max, med max som standard. Produsenten anbefaler max til komplekst kodingsarbeid; low gir et lettere resonneringsalternativ for enklere trinn. Bruk det valgte nivået sammen med en tydelig sluttproduktbeskrivelse og fullføringskriterier. For eksempel: «Undersøk disse filene og de mislykkede resultatene, spor årsaken på tvers av de berørte modulene, foreslå en rettelse som bevarer det offentlige grensesnittet, og forklar hvilke kontroller som fastslår at regresjonen er løst.»
Produsenten angir et kontekstvindu på 1M tokener og en maksimal utdatalengde på 128K tokener. Organiser langt materiale rundt relasjonen modellen skal undersøke. Bevar filnavn, relevante definisjoner, kildeetiketter og rekkefølgen av observasjoner, og sett av plass til resonneringen og sluttsvaret innenfor den gjeldende arbeidskonteksten. Et stort vindu er nyttig for avhengigheter på tvers av moduler eller en lang rekke agentobservasjoner; det gjør ikke et urettet arkiv med materiale som ikke henger sammen, til en veldefinert oppgave.
For arbeid i et kodelager gir du forventet atferd, relevant kildetekst, avhengighetsversjoner og faktiske feilmeldinger. Be modellen identifisere den berørte atferden før den foreslår en rettelse. For en refaktorering navngir du grensesnittet og invariantene som må forbli intakte. Et nyttig svar inneholder revidert kode, hvorfor endringen løser det observerte problemet og tilfellene som trengs for å kontrollere resultatet. Mat faktiske resultater tilbake til en verktøytilkoblet arbeidsflyt, slik at neste trinn bygger på den endrede tilstanden fremfor det tidligere forslaget.
For ytelsesarbeid gir du en arbeidsbelastning, en referansemåling og målinger som tidsbruk, profiler eller allokeringsregistreringer. Z.ai beskriver treningsoppgaver som omfatter diagnostisering av flaskehalser, optimalisering, eksperimenter og resultater som bevarer korrekthet. En praktisk forespørsel er: «Bruk denne profilen til å identifisere flaskehalsen med størst betydning, foreslå én målbar endring og forklar hvilket resultat som ville rettferdiggjøre å beholde den.» Skill mellom en ytelseshypotese og en registrert forbedring. Bevar samme arbeidsbelastning og relevante betingelser når du gransker et resultat.
Utgivelsen videreutvikler også evnen til sårbarhetsanalyse. For en defensiv kildekodegjennomgang gir du relevant kode, de tilsiktede tillitsgrensene og betingelsene den kjører under. Be om et funn som knytter et mistenkt problem til berørte inndata, atferd og et målrettet utbedringstiltak. Skill mellom en mulig svakhet og en reprodusert feil, og behold observasjonen som ble brukt til å validere den. En rapport er mer nyttig når den prioriterer konkrete bevis og foreslåtte rettelser fremfor å behandle hvert mistenkelig mønster som en bekreftet sårbarhet.
Funksjonskall lar en omkringliggende applikasjon eksponere eksterne operasjoner for modellen. Definer hvert verktøys formål, argumenter og forventede resultat, og returner deretter den faktiske verktøyobservasjonen til neste trinn. Modellen kan resonnere over resultatet og avgjøre hvordan det endrer oppgaven. Hold foreslåtte handlinger, utførte operasjoner og uavklarte kontroller atskilt. Produsenten dokumenterer også strømmende svar som returnerer resonnerings- og svarfragmenter separat; sett sammen det fullførte svaret før det behandles som den endelige rapporten eller kodeforklaringen.
Det lokale modellkortet gir en konkret detalj om historikkinnstillinger: chat-malen beholder tenkning som standard, mens produsenten anbefaler å fjerne gammel tenkning uttrykkelig i vanlige chatscenarioer. Bruk samtalestrukturen som passer bruksområdet, og bevar de faktisk fullførte svarene og verktøyresultatene som trengs for fortsettelsen. Ikke behandle resonneringsinnstillinger fra GLM 5.2 eller de separate GLM 5.3 Flash-utgavene som utbyttbare med denne modellens low/high/max-innstillinger.
For strukturerte resultater angir du forventede felt, typer og kilderegler. En nyttig leveranse kan være en feiltabell, en endringsplan eller et JSON-objekt som oppsummerer observasjoner. Valider både strukturen og verdiene før en applikasjon bruker dem. Sluttresultatet bør identifisere svaret eller den reviderte leveransen, bevisene som støtter den og de gjenstående antakelsene. Mer resonneringsinnsats fastslår ikke at et verktøy er kjørt, at en foreslått rettelse har bestått kontrollene eller at en faktapåstand har støtte utover materialet som er gitt.
", "aboutText": "Z.ai GLM 5.3 er en storskala tekstbasert resonneringsmodell utviklet for kompleks programvareutvikling og langvarig agentarbeid. Produsenten oppgir at den bruker samme basismodell som GLM 5.2, og at de nye forbedringene kommer fra ettertrening. Utgivelsen vektlegger sterkere programmering, terminaloperasjoner og bredere oppgaver som omfatter flere avhengige trinn. Den tar imot tekst og produserer tekst, inkludert kode, forklaringer, planer og forespørsler om verktøykall i en applikasjon som er koblet til verktøy.\n\nDen dokumenterte resonneringsmodusen er alltid aktivert. GLM 5.3 tilbyr tre innsatsnivåer: low, high og max, med max som standard. Produsenten anbefaler max til komplekst kodingsarbeid; low gir et lettere resonneringsalternativ for enklere trinn. Bruk det valgte nivået sammen med en tydelig sluttproduktbeskrivelse og fullføringskriterier. For eksempel: «Undersøk disse filene og de mislykkede resultatene, spor årsaken på tvers av de berørte modulene, foreslå en rettelse som bevarer det offentlige grensesnittet, og forklar hvilke kontroller som fastslår at regresjonen er løst.»\n\nProdusenten angir et kontekstvindu på 1M tokener og en maksimal utdatalengde på 128K tokener. Organiser langt materiale rundt relasjonen modellen skal undersøke. Bevar filnavn, relevante definisjoner, kildeetiketter og rekkefølgen av observasjoner, og sett av plass til resonneringen og sluttsvaret innenfor den gjeldende arbeidskonteksten. Et stort vindu er nyttig for avhengigheter på tvers av moduler eller en lang rekke agentobservasjoner; det gjør ikke et urettet arkiv med materiale som ikke henger sammen, til en veldefinert oppgave.\n\nFor arbeid i et kodelager gir du forventet atferd, relevant kildetekst, avhengighetsversjoner og faktiske feilmeldinger. Be modellen identifisere den berørte atferden før den foreslår en rettelse. For en refaktorering navngir du grensesnittet og invariantene som må forbli intakte. Et nyttig svar inneholder revidert kode, hvorfor endringen løser det observerte problemet og tilfellene som trengs for å kontrollere resultatet. Mat faktiske resultater tilbake til en verktøytilkoblet arbeidsflyt, slik at neste trinn bygger på den endrede tilstanden fremfor det tidligere forslaget.\n\nFor ytelsesarbeid gir du en arbeidsbelastning, en referansemåling og målinger som tidsbruk, profiler eller allokeringsregistreringer. Z.ai beskriver treningsoppgaver som omfatter diagnostisering av flaskehalser, optimalisering, eksperimenter og resultater som bevarer korrekthet. En praktisk forespørsel er: «Bruk denne profilen til å identifisere flaskehalsen med størst betydning, foreslå én målbar endring og forklar hvilket resultat som ville rettferdiggjøre å beholde den.» Skill mellom en ytelseshypotese og en registrert forbedring. Bevar samme arbeidsbelastning og relevante betingelser når du gransker et resultat.\n\nUtgivelsen videreutvikler også evnen til sårbarhetsanalyse. For en defensiv kildekodegjennomgang gir du relevant kode, de tilsiktede tillitsgrensene og betingelsene den kjører under. Be om et funn som knytter et mistenkt problem til berørte inndata, atferd og et målrettet utbedringstiltak. Skill mellom en mulig svakhet og en reprodusert feil, og behold observasjonen som ble brukt til å validere den. En rapport er mer nyttig når den prioriterer konkrete bevis og foreslåtte rettelser fremfor å behandle hvert mistenkelig mønster som en bekreftet sårbarhet.\n\nFunksjonskall lar en omkringliggende applikasjon eksponere eksterne operasjoner for modellen. Definer hvert verktøys formål, argumenter og forventede resultat, og returner deretter den faktiske verktøyobservasjonen til neste trinn. Modellen kan resonnere over resultatet og avgjøre hvordan det endrer oppgaven. Hold foreslåtte handlinger, utførte operasjoner og uavklarte kontroller atskilt. Produsenten dokumenterer også strømmende svar som returnerer resonnerings- og svarfragmenter separat; sett sammen det fullførte svaret før det behandles som den endelige rapporten eller kodeforklaringen.\n\nDet lokale modellkortet gir en konkret detalj om historikkinnstillinger: chat-malen beholder tenkning som standard, mens produsenten anbefaler å fjerne gammel tenkning uttrykkelig i vanlige chatscenarioer. Bruk samtalestrukturen som passer bruksområdet, og bevar de faktisk fullførte svarene og verktøyresultatene som trengs for fortsettelsen. Ikke behandle resonneringsinnstillinger fra GLM 5.2 eller de separate GLM 5.3 Flash-utgavene som utbyttbare med denne modellens low/high/max-innstillinger.\n\nFor strukturerte resultater angir du forventede felt, typer og kilderegler. En nyttig leveranse kan være en feiltabell, en endringsplan eller et JSON-objekt som oppsummerer observasjoner. Valider både strukturen og verdiene før en applikasjon bruker dem. Sluttresultatet bør identifisere svaret eller den reviderte leveransen, bevisene som støtter den og de gjenstående antakelsene. Mer resonneringsinnsats fastslår ikke at et verktøy er kjørt, at en foreslått rettelse har bestått kontrollene eller at en faktapåstand har støtte utover materialet som er gitt.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "9e484ed3b660caf2ca9d45e5baf34ab3ab4928a824a94caaaedd3488bfaec2bf", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "z-ai/glm-5.3:batchZ.ai GLM 5.3 er en tekstbasert resonneringsmodell for kompleks programvareutvikling, terminalarbeid og langvarige agentoppgaver. Den støtter en produsentdokumentert kontekst på 1M tokener, opptil 128K utdatatokener, funksjonskall og resonneringsnivåene low/high/max, med resonnering aktivert hele tiden.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Z.ai GLM 5.3 er en storskala tekstbasert resonneringsmodell utviklet for kompleks programvareutvikling og langvarig agentarbeid. Produsenten oppgir at den bruker samme basismodell som GLM 5.2, og at de nye forbedringene kommer fra ettertrening. Utgivelsen vektlegger sterkere programmering, terminaloperasjoner og bredere oppgaver som omfatter flere avhengige trinn. Den tar imot tekst og produserer tekst, inkludert kode, forklaringer, planer og forespørsler om verktøykall i en applikasjon som er koblet til verktøy.
Den dokumenterte resonneringsmodusen er alltid aktivert. GLM 5.3 tilbyr tre innsatsnivåer: low, high og max, med max som standard. Produsenten anbefaler max til komplekst kodingsarbeid; low gir et lettere resonneringsalternativ for enklere trinn. Bruk det valgte nivået sammen med en tydelig sluttproduktbeskrivelse og fullføringskriterier. For eksempel: «Undersøk disse filene og de mislykkede resultatene, spor årsaken på tvers av de berørte modulene, foreslå en rettelse som bevarer det offentlige grensesnittet, og forklar hvilke kontroller som fastslår at regresjonen er løst.»
Produsenten angir et kontekstvindu på 1M tokener og en maksimal utdatalengde på 128K tokener. Organiser langt materiale rundt relasjonen modellen skal undersøke. Bevar filnavn, relevante definisjoner, kildeetiketter og rekkefølgen av observasjoner, og sett av plass til resonneringen og sluttsvaret innenfor den gjeldende arbeidskonteksten. Et stort vindu er nyttig for avhengigheter på tvers av moduler eller en lang rekke agentobservasjoner; det gjør ikke et urettet arkiv med materiale som ikke henger sammen, til en veldefinert oppgave.
For arbeid i et kodelager gir du forventet atferd, relevant kildetekst, avhengighetsversjoner og faktiske feilmeldinger. Be modellen identifisere den berørte atferden før den foreslår en rettelse. For en refaktorering navngir du grensesnittet og invariantene som må forbli intakte. Et nyttig svar inneholder revidert kode, hvorfor endringen løser det observerte problemet og tilfellene som trengs for å kontrollere resultatet. Mat faktiske resultater tilbake til en verktøytilkoblet arbeidsflyt, slik at neste trinn bygger på den endrede tilstanden fremfor det tidligere forslaget.
For ytelsesarbeid gir du en arbeidsbelastning, en referansemåling og målinger som tidsbruk, profiler eller allokeringsregistreringer. Z.ai beskriver treningsoppgaver som omfatter diagnostisering av flaskehalser, optimalisering, eksperimenter og resultater som bevarer korrekthet. En praktisk forespørsel er: «Bruk denne profilen til å identifisere flaskehalsen med størst betydning, foreslå én målbar endring og forklar hvilket resultat som ville rettferdiggjøre å beholde den.» Skill mellom en ytelseshypotese og en registrert forbedring. Bevar samme arbeidsbelastning og relevante betingelser når du gransker et resultat.
Utgivelsen videreutvikler også evnen til sårbarhetsanalyse. For en defensiv kildekodegjennomgang gir du relevant kode, de tilsiktede tillitsgrensene og betingelsene den kjører under. Be om et funn som knytter et mistenkt problem til berørte inndata, atferd og et målrettet utbedringstiltak. Skill mellom en mulig svakhet og en reprodusert feil, og behold observasjonen som ble brukt til å validere den. En rapport er mer nyttig når den prioriterer konkrete bevis og foreslåtte rettelser fremfor å behandle hvert mistenkelig mønster som en bekreftet sårbarhet.
Funksjonskall lar en omkringliggende applikasjon eksponere eksterne operasjoner for modellen. Definer hvert verktøys formål, argumenter og forventede resultat, og returner deretter den faktiske verktøyobservasjonen til neste trinn. Modellen kan resonnere over resultatet og avgjøre hvordan det endrer oppgaven. Hold foreslåtte handlinger, utførte operasjoner og uavklarte kontroller atskilt. Produsenten dokumenterer også strømmende svar som returnerer resonnerings- og svarfragmenter separat; sett sammen det fullførte svaret før det behandles som den endelige rapporten eller kodeforklaringen.
Det lokale modellkortet gir en konkret detalj om historikkinnstillinger: chat-malen beholder tenkning som standard, mens produsenten anbefaler å fjerne gammel tenkning uttrykkelig i vanlige chatscenarioer. Bruk samtalestrukturen som passer bruksområdet, og bevar de faktisk fullførte svarene og verktøyresultatene som trengs for fortsettelsen. Ikke behandle resonneringsinnstillinger fra GLM 5.2 eller de separate GLM 5.3 Flash-utgavene som utbyttbare med denne modellens low/high/max-innstillinger.
For strukturerte resultater angir du forventede felt, typer og kilderegler. En nyttig leveranse kan være en feiltabell, en endringsplan eller et JSON-objekt som oppsummerer observasjoner. Valider både strukturen og verdiene før en applikasjon bruker dem. Sluttresultatet bør identifisere svaret eller den reviderte leveransen, bevisene som støtter den og de gjenstående antakelsene. Mer resonneringsinnsats fastslår ikke at et verktøy er kjørt, at en foreslått rettelse har bestått kontrollene eller at en faktapåstand har støtte utover materialet som er gitt.
POST /v1/batchestexttext| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltendpoint | Typestring | KravPåkrevd | Verdier & grenser /v1/chat/completions | Standard— |
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser z-ai/glm-5.3:batch | Standard— |
Feltrequests | Typebatch_item[] | KravPåkrevd | Verdier & grenser Minste antall elementer: 1 | Standard— |
Feltrequests[].custom_id | Typestring | KravPåkrevd | Verdier & grenser | Standard— |
Feltrequests[].body.messages | Typemessage[] | KravPåkrevd | Verdier & grenser | Standard— |
Feltcompletion_window | Typestring | KravValgfritt | Verdier & grenser 24h | Standard— |
Feltprovider | Typeobject|null | KravValgfritt | Verdier & grenser | Standard— |
Feltrequests[].body.model | Typestring | KravValgfritt | Verdier & grenser z-ai/glm-5.3:batch, z-ai/glm-5.3 | Standard— |
Feltprovider.only | Typestring[] | KravValgfritt | Verdier & grenser deepinfra/fp4 | Standard— |
Feltprovider.allow_fallbacks | Typeboolean|null | KravValgfritt | Verdier & grenser false, null | Standard— |
| Parameter | Avtale |
|---|---|
Parametercontent_type | Avtaleapplication/json |
Parameterrequired | Avtaleendpoint, model, requests |
Parametermaterial_types | Avtaletext |
Parameterrepresentation | Avtalerequests[] direkte i forespørselen; hvert element har custom_id og body |
Parameterrequest_endpoint_profile | Avtale/v1/chat/completions |
Parameterfile_material | AvtaleKlienten kan lese det faktiske UTF-8-kodede JSONL-innholdet lokalt inn i requests[]. Feltet purpose for opplasting, input_file_id og filreferanser brukes ikke. Manglende eller tomt kundemateriale stopper klargjøringen før POST. |
Parameterserialization_order | Avtaleendpoint, model, provider (hvis angitt), completion_window (hvis angitt), requests til slutt |
Parameteroptional_controls | Avtaleprovider.only, provider.allow_fallbacks, completion_window |
Parameterschema_scope | AvtaleForespørselsinnhold for tekstbasert Chat Completions lagt direkte inn i det dokumenterte Batch-formatet. |
Livssyklus: asynchronous
GET /v1/batches/{operation_id} · faktisk response.id fra den opprinnelige opprettelsen; samme bruker/nøkkel/gruppe
Tariffopplysninger legger ikke til forespørselsvalg. Støttede parametere står ved den valgte metoden.
Knytt hver kostnad til de viste vilkårene. Bruk én sats for hvert sett med alternative konfigurasjoner.
| Konfigurasjon | Prisplan | Konteksttokener, mer enn | Konteksttokener, opptil og med | Kostnad |
|---|---|---|---|---|
| KonfigurasjonGrunnpriser for tokener | PrisplanGrunnsats | Konteksttokener, mer enn— | Konteksttokener, opptil og medIngen øvre grense | Kostnad Inndata · Inngående tokener $0.0009 / 1K tokener Utdata · Utgående tokener $0.004 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.0002 / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
| KonfigurasjonNivå 1 for forespørselslengde | Prisplan— | Konteksttokener, mer enn0 | Konteksttokener, opptil og medIngen øvre grense | Kostnad Inndata · Inngående tokener $0.0009 / 1K tokener Utdata · Utgående tokener $0.004 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.0002 / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
Ailoot reserverer et estimert beløp før en forespørsel. Etter resultatet gjøres det endelige beløpet opp basert på målt forbruk. Oppgjør for strømming bruker den endelige forbruksposten. Slik fungerer reservasjon og oppgjør →
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 fra results[].response.body direkte i svaret
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\nBehold alle fullstendige returnerte svar, filer og innholdsdeler.
Bevar hele den opprinnelige statusresponsen i JSON, alle resultater og custom_id-verdier samt hele svar- eller feilinnholdet. Lagre fullførte results[] som JSONL uten filtrering.
Bevar den opprinnelige operasjons-ID-en. 503 result_pending_check har X-Should-Retry:false; send aldri den opprinnelige batchen på nytt når utfallet er ukjent.
| Felt | Type |
|---|---|
Feltresults[].custom_id | Typestring |
Feltresults[].response.body.choices[].message.content | Typestring|null |
Feltresults[].error | Typeobject|null |
Feltusage | Typeobject|null |
Feltid | Typestring |
Feltmodel | Typestring |
Feltendpoint | Typestring |
Feltstatus | Typestring |
Feltrequest_counts | Typeobject |
Feltresults[].id | Typestring |
Feltresults[].response.status_code | Typeinteger |
Feltresults[].response.request_id | Typestring |
| Svar | Vilkår | Neste trinn |
|---|---|---|
Svar400 · invalid_request_error | VilkårUgyldig struktur i det dokumenterte formatet med innebygde forespørsler, dupliserte nøkler, ugyldig elementidentitet eller konflikt med modellens konfigurerte funksjoner. | Neste trinnRett de angitte feltene før du sender en ny forespørsel. |
Svar401 · authentication_error | VilkårUgyldig API-nøkkel. | Neste trinnBruk den autoriserte Ailoot-nøkkelen. |
Svar403 · permission_error | VilkårGruppen for batchbehandling er ikke tilgjengelig. | Neste trinnKontroller tilgangsrettighetene til nøkkelen/gruppen. |
Svar422 · invalid_request_error | VilkårBatch belastes saldoen; opprettelse via abonnement avvises. | Neste trinnBruk den autoriserte gruppen som belastes saldoen. |
Svar422 · price_unavailable | VilkårDet kan ikke beregnes en pris for batchens inndata. | Neste trinnBevar svaret; bruk de dokumenterte inndataene for API-familien. |
Svar402 · billing_error | VilkårBeløpsreservasjon for batchbehandling er ikke tilgjengelig. | Neste trinnLøs problemet som hindrer forespørselen i å bli godkjent før du sender en ny forespørsel. |
Svar503 · price_unavailable | VilkårPris for Batch-metoden eller systemets innebygde satser er ikke tilgjengelige. | Neste trinnBevar svaret; ikke erstatt prisene. |
Svar503 · api_error | VilkårDen nøyaktige leverandørruten er ikke tilgjengelig. | Neste trinnBevar svaret slik at ruten kan repareres. |
Svar503 · result_pending_check | VilkårDet opprinnelige resultatet må kontrolleres; X-Should-Retry:false. | Neste trinnBevar opprinnelig operation_id/id og les statusen; gjenta aldri den opprinnelige POST-forespørselen. |
Svar404 · not_found | VilkårStatusoperasjonen for batchen finnes ikke eller tilhører en annen identitet. | Neste trinnBruk nøyaktig den opprinnelige id-verdien og samme bruker/nøkkel/gruppe. |
Ailoot Ultra z-ai/glm-5.3:batch
Bruk metodestiene som vises ovenfor.