Überblick: Repository-orientierte Programmierung
Qwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.
Der Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.
Belege aus dem Repository vorbereiten
Stellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.
Eine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.
Werkzeuge und Rückmeldungen über mehrere Gesprächsrunden
Der Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.
Die Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.
Fähigkeiten und Ergebnisformatierung
Erzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.
Prefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.
Kontext- und Ausgabegrenzen
Die Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.
Ein großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.
Praktisches Ergebnis und wesentliche Grenzen
Fordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.
Prüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.
", "aboutText": "Überblick: Repository-orientierte Programmierung\n\nQwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.\n\nDer Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.\n\nBelege aus dem Repository vorbereiten\n\nStellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.\n\nEine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.\n\nWerkzeuge und Rückmeldungen über mehrere Gesprächsrunden\n\nDer Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.\n\nDie Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.\n\nFähigkeiten und Ergebnisformatierung\n\nErzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.\n\nPrefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.\n\nKontext- und Ausgabegrenzen\n\nDie Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.\n\nEin großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.\n\nPraktisches Ergebnis und wesentliche Grenzen\n\nFordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.\n\nPrüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.", "editorialOverlay": { "copy_fields": { "practical_html": "Technisches Beispiel auf Englisch
Keep repository paths portable\n\nIn config.py, DATA_PATH = 'data/items.csv'. In runner.py, open(DATA_PATH) fails when the CLI is launched outside the repository directory. Propose a focused fix that anchors the resource path to the module location rather than the current working directory. Preserve the public CLI arguments and include a regression scenario launched from another directory.A small coordinated code proposal for the named modules and a regression scenario for an unrelated working directory.The proposed path does not depend on the launch directory and does not change the public CLI arguments.qwen/qwen3-coder-flashQwen3-Coder-Flash ist Qwens Textmodell für Repository-Verständnis und Werkzeuginteraktion über mehrere Gesprächsrunden. Die Spezifikation nennt eine Million Tokens Kontext, maximal 997.952 Eingabe- und 65.536 Ausgabe-Tokens; Werkzeugfunktionen gelten im Rahmen des Bereitstellungsprofils des Herstellers.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Überblick: Repository-orientierte Programmierung
Qwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.
Der Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.
Belege aus dem Repository vorbereiten
Stellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.
Eine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.
Werkzeuge und Rückmeldungen über mehrere Gesprächsrunden
Der Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.
Die Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.
Fähigkeiten und Ergebnisformatierung
Erzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.
Prefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.
Kontext- und Ausgabegrenzen
Die Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.
Ein großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.
Praktisches Ergebnis und wesentliche Grenzen
Fordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.
Prüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.
POST /v1/chat/completionstexttext| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits qwen/qwen3-coder-flash | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits Mindestanzahl Elemente: 1 | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits Beispiele: system, user, assistant, tool, function Bedingungen: Diese Rollen sind in den Kompatibilitätstypen des Quellcodes ausdrücklich dargestellt; der genaue Rollenumfang bleibt modellspezifisch. Modellabhängig | Standard— |
Feldmessages[].content | Typstring|content_part[]|null | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].tool_calls | Typtool_call[] | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].tool_call_id | Typstring | AnforderungOptional | Werte und Limits Gilt, wenn: role=tool; die tatsächlich zurückgegebene ID verwenden | Standard— |
Feldmessages[].name | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].reasoning_content | Typstring | AnforderungOptional | Werte und Limits Gilt, wenn: Tatsächlich zurückgegebene Reasoning-Daten erneut übermitteln, sofern dieses Modell sie verwendet | Standard— |
Feldmessages[].reasoning_details | Typobject|array | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldmax_tokens | Typinteger | AnforderungOptional | Werte und Limits Minimum: 1 Modellabhängig | Standard— |
Feldmax_completion_tokens | Typinteger | AnforderungOptional | Werte und Limits Minimum: 1 Modellabhängig | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Feldstream_options.include_usage | Typboolean | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtemperature | Typnumber | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtop_p | Typnumber | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldstop | Typstring|string[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtools | Typfunction_tool[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtools[].type | Typstring | AnforderungOptional | Werte und Limits function Modellabhängig | Standard— |
Feldtools[].function.name | Typstring | AnforderungErforderlich | Werte und Limits Gilt, wenn: Funktionswerkzeug bereitgestellt | Standard— |
Feldtools[].function.description | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldtools[].function.parameters | TypJSON_schema | AnforderungOptional | Werte und Limits | Standard— |
Feldtool_choice | Typstring|object | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldparallel_tool_calls | Typboolean | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldresponse_format | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldreasoning_effort | Typstring | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldreasoning | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldservice_tier | Typstring | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldinstructions | Typstring | AnforderungOptional | Werte und Limits Kompatibilitätsfeld | Standard— |
Feldfunctions | Typfunction[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldfunction_call | Typstring|object | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldprompt_cache_options | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldmodalities | Typstring[] | AnforderungOptional | Werte und Limits text | Standard— |
Feldprovider | Typobject | AnforderungOptional | Werte und Limits Bedingungen: provider.options wird auf dieser Ultra-Textroute abgelehnt | Standard— |
Feldcache_control.ttl | Typstring | AnforderungOptional | Werte und Limits Bedingungen: 1h wird in den tatsächlichen Prompt-Cache-Feldern abgelehnt | Standard— |
Text · UTF8-Text
messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages |
Parametermaterial_types | Vertragtext |
Parametermessages | VertragNachrichtenarray mit role/content-Struktur |
Parameterfile_material | VertragTatsächliches UTF-8-Dokument als wörtlicher Text eingefügt; keine Datei-ID abgeleitet |
Parameteroptional_controls | Vertragstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | VertragModellspezifisch; benutzerseitige Funktionswerkzeuge unterscheiden sich von gehosteten Werkzeugen |
Parameteroutput_modalities | Vertragtext |
Parameterhosted_operations | Vertragfalse |
Parametermultimodal_input_binding | Vertragnull |
Lebenszyklus: synchronous_or_streamed
Die genaue Modell-ID zusammen mit messages senden.
Die Kontextlänge ist keine Ausgabeobergrenze.
Eine Textdatei kann wörtlichen Text liefern; Bild-, Audio- und Dateiobjekteingaben benötigen eine exakte Zuordnung.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlich32.000 | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 2 | Tarifstaffel— | Kontexttoken, mehr als32.000 | Kontexttoken, bis einschließlich128.000 | Gebühr Eingabe · Eingabetoken $0.00065 / 1K Token Ausgabe · Ausgabetoken $0.00325 / 1K Token Eingabe · Cache-Lesen $0.00013 / 1K Token Eingabe · Cache-Schreiben $0.0008125 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 3 | Tarifstaffel— | Kontexttoken, mehr als128.000 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00104 / 1K Token Ausgabe · Ausgabetoken $0.0052 / 1K Token Eingabe · Cache-Lesen $0.000208 / 1K Token Eingabe · Cache-Schreiben $0.0013 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "qwen/qwen3-coder-flash", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='qwen/qwen3-coder-flash',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='qwen/qwen3-coder-flash',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Antwortvarianten mit ihren Inhalten, Werkzeugaufrufen und Reasoning-Daten beibehalten. In SSE die Deltas nach Varianten- und Werkzeugindex zusammensetzen; endgültigen Beendigungsgrund und Verbrauchsdaten beibehalten.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldchoices[].index | Typinteger |
Feldchoices[].message.content | Typstring|null |
Feldchoices[].message.tool_calls | Typtool_call[] |
Feldchoices[].message.reasoning_content | Typstring |
Feldchoices[].message.reasoning_details | Typobject|array |
Feldchoices[].finish_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra qwen/qwen3-coder-flash, qwen3-coder-flash
/chat/completions
qwen/qwen3-coder-flashQwen3-Coder-Flash ist Qwens Textmodell für Repository-Verständnis und Werkzeuginteraktion über mehrere Gesprächsrunden. Die Spezifikation nennt eine Million Tokens Kontext, maximal 997.952 Eingabe- und 65.536 Ausgabe-Tokens; Werkzeugfunktionen gelten im Rahmen des Bereitstellungsprofils des Herstellers.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Überblick: Repository-orientierte Programmierung
Qwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.
Der Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.
Belege aus dem Repository vorbereiten
Stellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.
Eine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.
Werkzeuge und Rückmeldungen über mehrere Gesprächsrunden
Der Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.
Die Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.
Fähigkeiten und Ergebnisformatierung
Erzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.
Prefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.
Kontext- und Ausgabegrenzen
Die Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.
Ein großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.
Praktisches Ergebnis und wesentliche Grenzen
Fordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.
Prüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.
POST /v1/messagestextjson, sse| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits qwen/qwen3-coder-flash | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits user, assistant | Standard— |
Feldmessages[].content | Typstring | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmax_tokens | Typinteger | AnforderungErforderlich | Werte und Limits | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Text · UTF-8-Text
Zeichenfolge messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages, max_tokens |
Parameteroptional_controls | Vertragstream |
Parametermaterial_types | Vertragtext |
Parametertext_file_material | VertragDas tatsächliche UTF-8-Dokument lesen und seinen Text in die angegebene Zeichenfolge für Eingabe oder Nachrichteninhalt einfügen. |
Lebenszyklus: synchronous_or_streamed
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlich32.000 | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 2 | Tarifstaffel— | Kontexttoken, mehr als32.000 | Kontexttoken, bis einschließlich128.000 | Gebühr Eingabe · Eingabetoken $0.00065 / 1K Token Ausgabe · Ausgabetoken $0.00325 / 1K Token Eingabe · Cache-Lesen $0.00013 / 1K Token Eingabe · Cache-Schreiben $0.0008125 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 3 | Tarifstaffel— | Kontexttoken, mehr als128.000 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00104 / 1K Token Ausgabe · Ausgabetoken $0.0052 / 1K Token Eingabe · Cache-Lesen $0.000208 / 1K Token Eingabe · Cache-Schreiben $0.0013 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "qwen/qwen3-coder-flash",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen/qwen3-coder-flash', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen/qwen3-coder-flash', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Inhaltsblöcke, Thinking-Signaturen und tatsächlichen Werkzeugaufruf-IDs beibehalten. Alle SSE-Blockdeltas zusammensetzen; der erste Textblock ist nicht die vollständige Ausgabe.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldid | Typstring |
Feldmodel | Typstring |
Feldcontent[] | Typtext|thinking|tool_use|other content block |
Feldstop_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra qwen/qwen3-coder-flash, qwen3-coder-flash
/chat/completions
qwen3-coder-flashQwen3-Coder-Flash ist Qwens Textmodell für Repository-Verständnis und Werkzeuginteraktion über mehrere Gesprächsrunden. Die Spezifikation nennt eine Million Tokens Kontext, maximal 997.952 Eingabe- und 65.536 Ausgabe-Tokens; Werkzeugfunktionen gelten im Rahmen des Bereitstellungsprofils des Herstellers.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Überblick: Repository-orientierte Programmierung
Qwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.
Der Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.
Belege aus dem Repository vorbereiten
Stellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.
Eine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.
Werkzeuge und Rückmeldungen über mehrere Gesprächsrunden
Der Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.
Die Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.
Fähigkeiten und Ergebnisformatierung
Erzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.
Prefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.
Kontext- und Ausgabegrenzen
Die Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.
Ein großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.
Praktisches Ergebnis und wesentliche Grenzen
Fordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.
Prüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.
POST /v1/chat/completionstexttext| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits qwen3-coder-flash | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits Mindestanzahl Elemente: 1 | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits Modellabhängig | Standard— |
Feldmessages[].content | Typstring | AnforderungOptional | Werte und Limits Gilt, wenn: Textgespräch | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Text · UTF8-Text
messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages |
Parametermaterial_types | Vertragtext |
Parametermessages | VertragNachrichtenarray mit role/content-Struktur |
Parameterfile_material | VertragTatsächliches UTF-8-Dokument als wörtlicher Text eingefügt; keine Datei-ID abgeleitet |
Parameteroptional_controls | Vertragstream |
Parametercontrol_scope | VertragTextgespräch; stream ist ein boolescher Wert und standardmäßig false. |
Parameteroutput_modalities | Vertragtext |
Parameterhosted_operations | Vertragfalse |
Parametermultimodal_input_binding | Vertragnull |
Methodenaliasnamen: /chat/completions
Lebenszyklus: synchronous_or_streamed
Die genaue Modell-ID zusammen mit messages senden.
Die Kontextlänge ist keine Ausgabeobergrenze.
Eine Textdatei kann wörtlichen Text liefern; Bild-, Audio- und Dateiobjekteingaben benötigen eine exakte Zuordnung.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlich32.000 | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 2 | Tarifstaffel— | Kontexttoken, mehr als32.000 | Kontexttoken, bis einschließlich128.000 | Gebühr Eingabe · Eingabetoken $0.00065 / 1K Token Ausgabe · Ausgabetoken $0.00325 / 1K Token Eingabe · Cache-Lesen $0.00013 / 1K Token Eingabe · Cache-Schreiben $0.0008125 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 3 | Tarifstaffel— | Kontexttoken, mehr als128.000 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00104 / 1K Token Ausgabe · Ausgabetoken $0.0052 / 1K Token Eingabe · Cache-Lesen $0.000208 / 1K Token Eingabe · Cache-Schreiben $0.0013 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model":"qwen3-coder-flash","messages":[{"role":"user","content":"hello"}],"stream":false}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model="qwen3-coder-flash", messages=[{"role":"user","content":"hello"}], stream=False)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\njson oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Antwortvarianten mit ihren Inhalten, Werkzeugaufrufen und Reasoning-Daten beibehalten. In SSE die Deltas nach Varianten- und Werkzeugindex zusammensetzen; endgültigen Beendigungsgrund und Verbrauchsdaten beibehalten.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldchoices[].index | Typinteger |
Feldchoices[].message.content | Typstring|null |
Feldchoices[].message.tool_calls | Typtool_call[] |
Feldchoices[].message.reasoning_content | Typstring |
Feldchoices[].message.reasoning_details | Typobject|array |
Feldchoices[].finish_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra qwen/qwen3-coder-flash, qwen3-coder-flash
/chat/completions
qwen3-coder-flashQwen3-Coder-Flash ist Qwens Textmodell für Repository-Verständnis und Werkzeuginteraktion über mehrere Gesprächsrunden. Die Spezifikation nennt eine Million Tokens Kontext, maximal 997.952 Eingabe- und 65.536 Ausgabe-Tokens; Werkzeugfunktionen gelten im Rahmen des Bereitstellungsprofils des Herstellers.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Überblick: Repository-orientierte Programmierung
Qwen3-Coder-Flash ist ein auf Qwen3 basierendes Modell zur Codegenerierung. Laut Hersteller übernimmt es Fähigkeiten als Programmieragent von Qwen3-Coder-Plus und ist für das Verständnis auf Repository-Ebene, stabile Werkzeugaufrufe und die Interaktion über mehrere Gesprächsrunden optimiert. Dokumentierte Eingabe und Ausgabe sind Text. Nutzen Sie es für eine Programmieraufgabe mit bereitgestelltem Projektkontext und einem konkreten Arbeitsergebnis, etwa einem vorgeschlagenen Patch, einer Funktion oder einer Erklärung.
Der Hersteller beschreibt qwen3-coder-flash derzeit als funktional gleichwertig mit qwen3-coder-flash-2025-07-28 und führt diesen datierten Snapshot als benannte Version weiter. Behalten Sie beim Dokumentieren der Modellauswahl die angeforderte Identität bei. Die Seite dieses konkreten Modells belegt weder die Parameterzahl noch die Identität der Gewichte eines offenen Coder-Checkpoints. Der Name Flash sollte daher nicht in eine unbelegte Größen- oder Architekturaussage umgedeutet werden.
Belege aus dem Repository vorbereiten
Stellen Sie die relevanten Module, Schnittstellen, Anforderungen und eine Eingabe bereit, die das besprochene Verhalten veranschaulicht. Bitten Sie um einen nach betroffenen Komponenten geordneten Implementierungsvorschlag und fordern Sie anschließend das bearbeitbare Arbeitsergebnis getrennt von den Erläuterungen an. Geben Sie für eine Fehleranalyse den beobachteten Fehler oder die Ausgabe sowie das erwartete Verhalten an. Beschreiben Sie bei einer neuen Funktion die Interaktionen und Bedingungen, die das Ergebnis erfüllen muss.
Eine nützliche Antwort kann Diagnose, vorgeschlagene Änderung und die zur Prüfung erforderlichen Kontrollen darstellen. Bei einer Aufgabe in einem großen Projekt sollten Datei- und Funktionskennungen im bereitgestellten Material erhalten bleiben, damit die Erklärung auf ihre Belege verweisen kann. Prüfen Sie die vorgeschlagenen Änderungen anhand der bereitgestellten Dateien, des erwarteten Verhaltens und der von angeschlossenen Prüfungen gelieferten Ergebnisse.
Werkzeuge und Rückmeldungen über mehrere Gesprächsrunden
Der Hersteller betont die Werkzeuginteraktion über mehrere Gesprächsrunden. Ein angeschlossener Ablauf kann Untersuchungs- oder Ausführungswerkzeuge bereitstellen und tatsächliche Beobachtungen an das Modell zurückgeben. Legen Sie zulässige Aktionen und beobachtbare Abschlusskriterien fest. Wenn eine Prüfung fehlschlägt, liefern Sie den tatsächlichen Fehler und den relevanten Code, statt lediglich um einen neuen Versuch zu bitten. Das Modell kann seinen Arbeitsvorschlag anhand dieser Rückmeldung überarbeiten; die Anwendung führt die Aktionen aus.
Die Funktionsmatrix unterstützt Function Calling im Alibaba-Profil China (Beijing) und kennzeichnet es in Singapore, Germany (Frankfurt) und US (Virginia) als nicht unterstützt. Werkzeugverfügbarkeit ist daher an Bedingungen gebunden und wird nicht allein durch den Modellnamen zugesichert. Ein Textvorschlag, eine Werkzeuganfrage und ein abgeschlossener Vorgang sollten im Abschlussbericht unterscheidbar bleiben. Geben Sie einen Abschlussbericht aus, der Codevorschlag, angeforderte Werkzeugaufrufe und tatsächliche Werkzeugergebnisse trennt.
Fähigkeiten und Ergebnisformatierung
Erzwungene strukturierte Ausgaben und integrierte Websuche sind auf der eigenen Modellseite als nicht unterstützt gekennzeichnet. Ein Prompt kann eine Tabelle oder JSON-förmigen Text verlangen, schafft damit aber keinen Vertrag zur Schemaerzwingung. Ein Programmieragent kann aktuelle Belege von einem durch die Anwendung bereitgestellten Werkzeug erhalten, ohne dass das Modell selbst eine integrierte Suchfunktion hat.
Prefix Completion wird in China (Beijing) nicht unterstützt, in Singapore, Germany (Frankfurt) und US (Virginia) dagegen schon. Context Caching wird für den undatierten Alias in allen vier Profilen unterstützt, während der separat aufgeführte Snapshot vom 28. Juli dies als nicht unterstützt kennzeichnet. Beide Ausführungen kennzeichnen Batch-Inferenz und Fine-Tuning als nicht unterstützt. Fordern Sie ein leicht überprüfbares Endergebnis an und behalten Sie tatsächliche Werkzeugbeobachtungen bei, wenn ein Bericht behauptet, dass etwas geprüft wurde.
Kontext- und Ausgabegrenzen
Die Spezifikation nennt ein Kontextfenster von 1.000.000 Tokens, maximal 997.952 Tokens Eingabelänge und maximal 65.536 Tokens Ausgabelänge. Dies sind separate Grenzen; es sollte nicht angenommen werden, dass die größtmögliche Eingabe und Ausgabe gleichzeitig in den Kontext passen. Projekttext, Verlauf, Werkzeugergebnisse und generierter Quelltext benötigen Platz im tatsächlichen Anfragebudget.
Ein großer Kontext kann mehr Repository-Belege in einer Aufgabe zusammenführen. Trotzdem ist es sinnvoll, nicht relevante generierte Dateien, Wiederholungen und irrelevante Module zu entfernen und die Definitionen und Schnittstellen zu behalten, von denen die Änderung abhängt. Fordern Sie bei einem umfangreichen Arbeitsergebnis die benötigten Dateien oder Funktionen ausdrücklich an und reservieren Sie ausreichend Platz für deren Ausgabe. Trennen Sie Codedateien von Erläuterungen, damit Prüfende die vorgeschlagenen Änderungen nachvollziehen können.
Praktisches Ergebnis und wesentliche Grenzen
Fordern Sie bei einer Repository-Änderung einen Patch mit betroffenen Dateien, Annahmen und tatsächlich zurückgelieferten Ergebnissen angeschlossener Prüfungen an. Geben Sie bei einem Algorithmus Eingabebedingungen und erwartete Ausgabe an, bevor Sie nach Code fragen. Die dokumentierte Eingabe ist Text. Eine visuelle Referenz oder Aufzeichnung benötigt daher eine geeignete separate Darstellung, wenn sie als Beleg für die Aufgabe dienen soll.
Prüfen Sie generierte Syntax, Schnittstellen und Randfälle im Entwicklungsablauf. Eine plausible Erklärung oder eine werkzeugorientierte Modellbeschreibung belegt nicht, dass Code erfolgreich ausgeführt wurde. Das praktische Ergebnis ist ein überprüfbares Text- oder Codeartefakt, das an bereitgestelltes Repository-Material gebunden ist und die genaue Flash-Identität, Herstellergrenzen und den bedingten Werkzeugvertrag wahrt.
POST /v1/messagestextjson, sse| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits qwen3-coder-flash | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits user, assistant | Standard— |
Feldmessages[].content | Typstring | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmax_tokens | Typinteger | AnforderungErforderlich | Werte und Limits | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Text · UTF-8-Text
Zeichenfolge messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages, max_tokens |
Parameteroptional_controls | Vertragstream |
Parametermaterial_types | Vertragtext |
Parametertext_file_material | VertragDas tatsächliche UTF-8-Dokument lesen und seinen Text in die angegebene Zeichenfolge für Eingabe oder Nachrichteninhalt einfügen. |
Lebenszyklus: synchronous_or_streamed
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlich32.000 | Gebühr Eingabe · Eingabetoken $0.00039 / 1K Token Ausgabe · Ausgabetoken $0.00195 / 1K Token Eingabe · Cache-Lesen $0.000078 / 1K Token Eingabe · Cache-Schreiben $0.0004875 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 2 | Tarifstaffel— | Kontexttoken, mehr als32.000 | Kontexttoken, bis einschließlich128.000 | Gebühr Eingabe · Eingabetoken $0.00065 / 1K Token Ausgabe · Ausgabetoken $0.00325 / 1K Token Eingabe · Cache-Lesen $0.00013 / 1K Token Eingabe · Cache-Schreiben $0.0008125 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 3 | Tarifstaffel— | Kontexttoken, mehr als128.000 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00104 / 1K Token Ausgabe · Ausgabetoken $0.0052 / 1K Token Eingabe · Cache-Lesen $0.000208 / 1K Token Eingabe · Cache-Schreiben $0.0013 / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "qwen3-coder-flash",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen3-coder-flash', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen3-coder-flash', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Inhaltsblöcke, Thinking-Signaturen und tatsächlichen Werkzeugaufruf-IDs beibehalten. Alle SSE-Blockdeltas zusammensetzen; der erste Textblock ist nicht die vollständige Ausgabe.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldid | Typstring |
Feldmodel | Typstring |
Feldcontent[] | Typtext|thinking|tool_use|other content block |
Feldstop_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra qwen/qwen3-coder-flash, qwen3-coder-flash
/chat/completions
Technisches Beispiel auf Englisch
Keep repository paths portable\n\nIn config.py, DATA_PATH = 'data/items.csv'. In runner.py, open(DATA_PATH) fails when the CLI is launched outside the repository directory. Propose a focused fix that anchors the resource path to the module location rather than the current working directory. Preserve the public CLI arguments and include a regression scenario launched from another directory.A small coordinated code proposal for the named modules and a regression scenario for an unrelated working directory.The proposed path does not depend on the launch directory and does not change the public CLI arguments.