Gemini 3.6 Flash er Googles multimodale arbeidshestprofil for koding, kunnskapsarbeid og agentbasert utførelse. Den bygger på Gemini 3.5 Flash, med vekt på bedre multimodal ytelse og tokeneffektivitet. Modellen tar imot tekst, bilder, lyd, video og PDF og returnerer tekst. En nyttig oppgave kan kombinere kode, et skjermbilde og et krav, eller sammenligne et diagram eller en visuell plan med skriftlige begrensninger for å produsere en kontrollert forklaring eller målrettet endring.
Utviklerveiledningen fremhever færre unødvendige resonneringstrinn, samtalerunder og verktøykall i arbeid med flere trinn, samt mer målrettede endringer. Ved diagnostisering oppgir du den observerte feilen, den relevante kildekoden og atferden som skal forbli uendret. Ved feilsøking av et diagram kan du be modellen undersøke hvorfor feil dataserie vises, identifisere datatransformasjonen som er involvert, og foreslå én rettelse mens resten av oppsettet beholdes. Resultatet kan deretter sammenlignes med de faktiske inndataene og den påkrevde diagramatferden.
Programmatisk undersøkelse før endringer er en særskilt atferd beskrevet for 3.6. Produsenten sier at modellen oftere undersøker et problem med diagnostisk kode før den gjør endringer. Dette kan hjelpe ved en kompleks undersøkelse, men veiledningen påpeker at det kan tilføre utforskende trinn til vanlig frontend-arbeid. Angi om oppgaven krever en undersøkelse, en enkel endring eller en designsammenligning. Oppgi informasjonen som tydeliggjør forskjellen, og spesifiser tillatte handlinger for verktøyene i den tilkoblede applikasjonen.
Romlig og multimodal resonnering fremheves også: tolkning av diagrammer, omforming av visuelle tegninger og nettoppsett med flere elementer. Oppgi den relevante visningen eller sidene, angi hva som skal tolkes, og be om belegget bak konklusjonen. Ta med konkrete retningslinjer for oppsett og stil ved en designoppgave. Produsenten påpeker vektlegging av funksjonell kode og at evaluatorer noen ganger foretrakk tidligere modellers visuelle stil, noe som gjør en eksplisitt visuell instruks nyttig. Kontroller resultatet mot det faktiske diagrammet eller designkravene.
Medium er det dokumenterte standardnivået for resonnering. Googles modellspesifikke tabell for resonnering oppgir minimal, low, medium og high; migreringsveiledningen for 3.6 bruker medium eller high i eksemplene på innsatsnivå. Den konkrete siden oppgir funksjonskall, kodekjøring, filsøk, forankring i søkeresultater, Maps-forankring, URL-kontekst og strukturerte utdata, med Computer Use som en forhåndsversjon. Definer funksjonens inndata og det nødvendige resultatet tydelig. En funksjon valgt av modellen trenger et reelt applikasjonsresultat før et senere svar kan bygge på utfallet. Definer skjemaet og kildebelegget som kreves for hvert funn i en strukturert analyse.
Veiledningen for 3.6 endrer forberedelsen sammenlignet med tidligere Gemini-forespørsler. Den markerer samplingsinnstillingene temperature, top-p og top-k som foreldede, avviser en forhåndsutfylt siste melding med modellrolle og anbefaler systeminstruksjoner eller strukturerte utdata for å styre svaret. Reglene for funksjonssvar kobler et svar til kallet ved hjelp av identitet og navn, og Gemini 3-grunnlaget bevarer resonneringssignaturer i bruk med flere samtalerunder. En praktisk fortsettelse bør videreføre den relevante historikken og verktøyresultatet uendret fremfor å etterligne begynnelsen på et tidligere svar.
Det opprinnelige modellkortet angir opptil 1M inndatakontekst og 64K tekstutdata; den konkrete API-tabellen oppgir 1048576 inndatatokener og 65536 utdatatokener. Regn instruksjoner, historikk og medier som del av inndataene, og be om et resultat som passer til oppgaven. Produsentsiden oppgir også hurtigbufring, batch-, Flex- og Priority-behandling. Hold postidentifikatoren og resultatformatet eksplisitte ved behandling av uavhengige poster. Utdataene er en tekstleveranse selv når belegget omfatter fotografier, lyd eller video.
Mulige begrensninger omfatter hallusinasjoner og sporadisk treghet eller tidsavbrudd. Kunnskapsgrensen i mars 2026 omfatter fagområder der kunnskapen fortsatt er begrenset til januar 2025, så legg ved nyere materiale eller bruk en dokumentert arbeidsflyt for kildeforankring når aktuelle fakta er viktige. Kontroller beregninger, kildereferanser, visuelle tolkninger og foreslåtte endringer. Den særskilte forberedelsen for denne utgaven er en målrettet diagnostisk instruks, et tydelig verktøyomfang og eksplisitte designbegrensninger, etterfulgt av kontroll av det konkrete resultatet.
", "aboutText": "Gemini 3.6 Flash er Googles multimodale arbeidshestprofil for koding, kunnskapsarbeid og agentbasert utførelse. Den bygger på Gemini 3.5 Flash, med vekt på bedre multimodal ytelse og tokeneffektivitet. Modellen tar imot tekst, bilder, lyd, video og PDF og returnerer tekst. En nyttig oppgave kan kombinere kode, et skjermbilde og et krav, eller sammenligne et diagram eller en visuell plan med skriftlige begrensninger for å produsere en kontrollert forklaring eller målrettet endring.\n\nUtviklerveiledningen fremhever færre unødvendige resonneringstrinn, samtalerunder og verktøykall i arbeid med flere trinn, samt mer målrettede endringer. Ved diagnostisering oppgir du den observerte feilen, den relevante kildekoden og atferden som skal forbli uendret. Ved feilsøking av et diagram kan du be modellen undersøke hvorfor feil dataserie vises, identifisere datatransformasjonen som er involvert, og foreslå én rettelse mens resten av oppsettet beholdes. Resultatet kan deretter sammenlignes med de faktiske inndataene og den påkrevde diagramatferden.\n\nProgrammatisk undersøkelse før endringer er en særskilt atferd beskrevet for 3.6. Produsenten sier at modellen oftere undersøker et problem med diagnostisk kode før den gjør endringer. Dette kan hjelpe ved en kompleks undersøkelse, men veiledningen påpeker at det kan tilføre utforskende trinn til vanlig frontend-arbeid. Angi om oppgaven krever en undersøkelse, en enkel endring eller en designsammenligning. Oppgi informasjonen som tydeliggjør forskjellen, og spesifiser tillatte handlinger for verktøyene i den tilkoblede applikasjonen.\n\nRomlig og multimodal resonnering fremheves også: tolkning av diagrammer, omforming av visuelle tegninger og nettoppsett med flere elementer. Oppgi den relevante visningen eller sidene, angi hva som skal tolkes, og be om belegget bak konklusjonen. Ta med konkrete retningslinjer for oppsett og stil ved en designoppgave. Produsenten påpeker vektlegging av funksjonell kode og at evaluatorer noen ganger foretrakk tidligere modellers visuelle stil, noe som gjør en eksplisitt visuell instruks nyttig. Kontroller resultatet mot det faktiske diagrammet eller designkravene.\n\nMedium er det dokumenterte standardnivået for resonnering. Googles modellspesifikke tabell for resonnering oppgir minimal, low, medium og high; migreringsveiledningen for 3.6 bruker medium eller high i eksemplene på innsatsnivå. Den konkrete siden oppgir funksjonskall, kodekjøring, filsøk, forankring i søkeresultater, Maps-forankring, URL-kontekst og strukturerte utdata, med Computer Use som en forhåndsversjon. Definer funksjonens inndata og det nødvendige resultatet tydelig. En funksjon valgt av modellen trenger et reelt applikasjonsresultat før et senere svar kan bygge på utfallet. Definer skjemaet og kildebelegget som kreves for hvert funn i en strukturert analyse.\n\nVeiledningen for 3.6 endrer forberedelsen sammenlignet med tidligere Gemini-forespørsler. Den markerer samplingsinnstillingene temperature, top-p og top-k som foreldede, avviser en forhåndsutfylt siste melding med modellrolle og anbefaler systeminstruksjoner eller strukturerte utdata for å styre svaret. Reglene for funksjonssvar kobler et svar til kallet ved hjelp av identitet og navn, og Gemini 3-grunnlaget bevarer resonneringssignaturer i bruk med flere samtalerunder. En praktisk fortsettelse bør videreføre den relevante historikken og verktøyresultatet uendret fremfor å etterligne begynnelsen på et tidligere svar.\n\nDet opprinnelige modellkortet angir opptil 1M inndatakontekst og 64K tekstutdata; den konkrete API-tabellen oppgir 1048576 inndatatokener og 65536 utdatatokener. Regn instruksjoner, historikk og medier som del av inndataene, og be om et resultat som passer til oppgaven. Produsentsiden oppgir også hurtigbufring, batch-, Flex- og Priority-behandling. Hold postidentifikatoren og resultatformatet eksplisitte ved behandling av uavhengige poster. Utdataene er en tekstleveranse selv når belegget omfatter fotografier, lyd eller video.\n\nMulige begrensninger omfatter hallusinasjoner og sporadisk treghet eller tidsavbrudd. Kunnskapsgrensen i mars 2026 omfatter fagområder der kunnskapen fortsatt er begrenset til januar 2025, så legg ved nyere materiale eller bruk en dokumentert arbeidsflyt for kildeforankring når aktuelle fakta er viktige. Kontroller beregninger, kildereferanser, visuelle tolkninger og foreslåtte endringer. Den særskilte forberedelsen for denne utgaven er en målrettet diagnostisk instruks, et tydelig verktøyomfang og eksplisitte designbegrensninger, etterfulgt av kontroll av det konkrete resultatet.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "746466321ec3f61a07dcc8b8ff6069acaef97ca1f4e7a0e06e8c853ec7aca6f2", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "google/gemini-3.6-flash:batchGemini 3.6 Flash er Googles multimodale tekstmodell for koding, romlig analyse og agenter som arbeider i flere trinn. Den vektlegger diagnostisk undersøkelse, målrettede endringer og færre unødvendige utførelsessløyfer. Den tar imot tekst, bilder, lyd, video og PDF, med verktøy, strukturerte utdata og en inndatagrense på 1048576 tokener.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Gemini 3.6 Flash er Googles multimodale arbeidshestprofil for koding, kunnskapsarbeid og agentbasert utførelse. Den bygger på Gemini 3.5 Flash, med vekt på bedre multimodal ytelse og tokeneffektivitet. Modellen tar imot tekst, bilder, lyd, video og PDF og returnerer tekst. En nyttig oppgave kan kombinere kode, et skjermbilde og et krav, eller sammenligne et diagram eller en visuell plan med skriftlige begrensninger for å produsere en kontrollert forklaring eller målrettet endring.
Utviklerveiledningen fremhever færre unødvendige resonneringstrinn, samtalerunder og verktøykall i arbeid med flere trinn, samt mer målrettede endringer. Ved diagnostisering oppgir du den observerte feilen, den relevante kildekoden og atferden som skal forbli uendret. Ved feilsøking av et diagram kan du be modellen undersøke hvorfor feil dataserie vises, identifisere datatransformasjonen som er involvert, og foreslå én rettelse mens resten av oppsettet beholdes. Resultatet kan deretter sammenlignes med de faktiske inndataene og den påkrevde diagramatferden.
Programmatisk undersøkelse før endringer er en særskilt atferd beskrevet for 3.6. Produsenten sier at modellen oftere undersøker et problem med diagnostisk kode før den gjør endringer. Dette kan hjelpe ved en kompleks undersøkelse, men veiledningen påpeker at det kan tilføre utforskende trinn til vanlig frontend-arbeid. Angi om oppgaven krever en undersøkelse, en enkel endring eller en designsammenligning. Oppgi informasjonen som tydeliggjør forskjellen, og spesifiser tillatte handlinger for verktøyene i den tilkoblede applikasjonen.
Romlig og multimodal resonnering fremheves også: tolkning av diagrammer, omforming av visuelle tegninger og nettoppsett med flere elementer. Oppgi den relevante visningen eller sidene, angi hva som skal tolkes, og be om belegget bak konklusjonen. Ta med konkrete retningslinjer for oppsett og stil ved en designoppgave. Produsenten påpeker vektlegging av funksjonell kode og at evaluatorer noen ganger foretrakk tidligere modellers visuelle stil, noe som gjør en eksplisitt visuell instruks nyttig. Kontroller resultatet mot det faktiske diagrammet eller designkravene.
Medium er det dokumenterte standardnivået for resonnering. Googles modellspesifikke tabell for resonnering oppgir minimal, low, medium og high; migreringsveiledningen for 3.6 bruker medium eller high i eksemplene på innsatsnivå. Den konkrete siden oppgir funksjonskall, kodekjøring, filsøk, forankring i søkeresultater, Maps-forankring, URL-kontekst og strukturerte utdata, med Computer Use som en forhåndsversjon. Definer funksjonens inndata og det nødvendige resultatet tydelig. En funksjon valgt av modellen trenger et reelt applikasjonsresultat før et senere svar kan bygge på utfallet. Definer skjemaet og kildebelegget som kreves for hvert funn i en strukturert analyse.
Veiledningen for 3.6 endrer forberedelsen sammenlignet med tidligere Gemini-forespørsler. Den markerer samplingsinnstillingene temperature, top-p og top-k som foreldede, avviser en forhåndsutfylt siste melding med modellrolle og anbefaler systeminstruksjoner eller strukturerte utdata for å styre svaret. Reglene for funksjonssvar kobler et svar til kallet ved hjelp av identitet og navn, og Gemini 3-grunnlaget bevarer resonneringssignaturer i bruk med flere samtalerunder. En praktisk fortsettelse bør videreføre den relevante historikken og verktøyresultatet uendret fremfor å etterligne begynnelsen på et tidligere svar.
Det opprinnelige modellkortet angir opptil 1M inndatakontekst og 64K tekstutdata; den konkrete API-tabellen oppgir 1048576 inndatatokener og 65536 utdatatokener. Regn instruksjoner, historikk og medier som del av inndataene, og be om et resultat som passer til oppgaven. Produsentsiden oppgir også hurtigbufring, batch-, Flex- og Priority-behandling. Hold postidentifikatoren og resultatformatet eksplisitte ved behandling av uavhengige poster. Utdataene er en tekstleveranse selv når belegget omfatter fotografier, lyd eller video.
Mulige begrensninger omfatter hallusinasjoner og sporadisk treghet eller tidsavbrudd. Kunnskapsgrensen i mars 2026 omfatter fagområder der kunnskapen fortsatt er begrenset til januar 2025, så legg ved nyere materiale eller bruk en dokumentert arbeidsflyt for kildeforankring når aktuelle fakta er viktige. Kontroller beregninger, kildereferanser, visuelle tolkninger og foreslåtte endringer. Den særskilte forberedelsen for denne utgaven er en målrettet diagnostisk instruks, et tydelig verktøyomfang og eksplisitte designbegrensninger, etterfulgt av kontroll av det konkrete resultatet.
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 google/gemini-3.6-flash: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 google/gemini-3.6-flash:batch, google/gemini-3.6-flash | Standard— |
Feltprovider.only | Typestring[] | KravValgfritt | Verdier & grenser google-vertex/global | 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.00075 / 1K tokener Utdata · Utgående tokener $0.00375 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.000075 / 1K tokener Inndata · Skriving til hurtigbuffer $0.0000833333333333334 / 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.00075 / 1K tokener Utdata · Utgående tokener $0.00375 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.000075 / 1K tokener Inndata · Skriving til hurtigbuffer $0.0000833333333333334 / 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":"google/gemini-3.6-flash: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 ['google/gemini-3.6-flash:batch', 'google/gemini-3.6-flash']: raise ValueError("body.model must be an exact documented caller or wire ID")\n return {"endpoint":"/v1/chat/completions", "model":"google/gemini-3.6-flash: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 google/gemini-3.6-flash:batch
Bruk metodestiene som vises ovenfor.