CodeGeeX4 ist eine mehrsprachige Programmiermodellfamilie für Programmierhilfe und Arbeit über zusammengehörige Quelldateien hinweg. Der Hersteller veröffentlicht CodeGeeX4-ALL-9B als quelloffenes Mitglied der Reihe, entwickelt durch fortgesetztes Training von GLM-4-9B. Seine Dokumentation behandelt Codeerzeugung und -vervollständigung, Programmierfragen, Repository-Analyse und angeschlossene Abläufe mit Codeinterpreter, Websuche oder Funktionsaufrufen. Die gewöhnliche Ausgabe ist Text: Code, Erklärungen, Antworten oder mit Dateinamen gekennzeichnete Änderungen, entsprechend der Aufgabenanweisung.
Wählen Sie zunächst die Operation und geben Sie dem Modell den benötigten Code. Der native Systemprompt-Leitfaden enthält eigene Anweisungen zum Ergänzen von Kommentaren, Erklären eines Programms, Übersetzen zwischen Programmiersprachen, Prüfen oder Reparieren von Code, Erzeugen von Tests und Beantworten von Fragen zu einer Datei. Fügen Sie für eine Reparatur den fehlerhaften Code, das beobachtete Verhalten und das gewünschte Ergebnis bei. Nennen Sie für eine Übersetzung die Zielprogrammiersprache und stellen Sie die vollständige relevante Funktion bereit. Bei Kommentaren bewahrt die Aufgabenanweisung des Herstellers den Code und ergänzt Kommentare; bei mehreren Aufgaben zur Codeerzeugung verlangt sie ausschließlich Code. Diese Unterschiede machen das Ergebnis als Code oder Erklärung nutzbar, statt das Ausgabeformat unausgesprochen zu lassen.
Die Leitfäden liefern chinesische und englische Systemprompts. Die Sprache der Systemanweisung bestimmt nicht von sich aus die Antwortsprache; fordern Sie diese daher ausdrücklich an, wenn eine Erklärung benötigt wird. Der spezialisierte Prüfleitfaden beschreibt chinesische Ausgabe; der allgemeine Prompt für Programmierassistenten bietet einen separaten Weg, eine Prüfung in einer anderen Antwortsprache anzufordern. Einige Aufgabenvorlagen passen die Kommentarsprache an die Quelle an und schließen gemischte chinesische und englische Ausgabe aus. Wiederholen Sie in einem laufenden Dialog beim Wechsel der Operation die relevante Aufgabenanweisung, damit eine Bitte um Erklärung nicht mit der vorhergehenden Bitte um reine Codeausgabe verwechselt wird.
Für kontextbezogene Vervollständigung beschreibt das native Format die Zieldatei, ihre Programmiersprache und den Code auf beiden Seiten der Einfügestelle. Verwenden Sie den relativen Dateipfad mit ###PATH: und fügen Sie ###LANGUAGE: hinzu; der Leitfaden erlaubt einen leeren Sprachwert, wenn die Sprache unbekannt ist. ###MODE: wählt LINE für eine einzeilige oder BLOCK für eine mehrzeilige Vervollständigung; BLOCK ist der dokumentierte Standard. Die Fill-in-the-Middle-Sequenz enthält zuerst das Suffix, dann das Präfix und dann den fehlenden Mittelteil, markiert mit <|code_suffix|>, <|code_prefix|> und <|code_middle|>. Die Einfügevorlage des Herstellers lässt den Systemprompt weg. Das Bewahren des Suffixes gibt dem Modell den umgebenden Kontrollfluss und den Code, der nach der Einfügung erhalten bleiben muss. Das Ergebnis ist der vorgeschlagene fehlende Code, der anschließend an seiner ursprünglichen Stelle geprüft werden kann.
Dateiübergreifende Vervollständigung ergänzt verwandte Ausschnitte als Referenzmaterial, jeweils eingeleitet durch ###REFERENCE: und ein eigenes ###PATH:. Halten Sie diese Referenzen von der Zieldatei und ihrer Einfügestelle getrennt. Stellen Sie etwa beim Vervollständigen einer Funktion, die eine bestehende Hilfsfunktion aufruft, deren Signatur und Implementierung neben Präfix und Suffix der Zielfunktion bereit. Der Leitfaden für projektweite Vervollständigung erweitert diesen Ansatz auf das Erzeugen einer neuen Datei anhand der Projektanforderungen und relevanten bestehenden Codes. Klare Pfade und ausgewählte Abhängigkeiten ermöglichen es, als Beleg bereitgestellten Code von der Datei zu unterscheiden, die das Modell vervollständigen soll.
Repository-Fragen verwenden einen anderen nativen Aufbau: Führen Sie jede Datei unter ###PATH: auf, fügen Sie ihren Code bei und stellen Sie dann die Frage. Ein hilfreicher Auftrag kann fragen, wo ein Wert definiert wird oder wie ein Aufruf zwischen den bereitgestellten Modulen weiterläuft. Repository-Bearbeitung verwendet eine eigene Systemanweisung zum Hinzufügen, Löschen oder Ändern von Dateien und verlangt die Ausgabe als ###PATH: {PATH}, gefolgt vom Code. Bereiten Sie die relevanten Dateien vor und beschreiben Sie die erforderliche Änderung, einschließlich der hinzuzufügenden Datei oder des zu bewahrenden Verhaltens. Lesen Sie die zurückgegebenen, mit Pfaden gekennzeichneten Blöcke als Änderungsvorschläge; sie belegen weder eine bereits erfolgte Repository-Änderung noch eine Codeausführung.
Für das veröffentlichte Mitglied CodeGeeX4-ALL-9B dokumentiert der Hersteller einen 128K-Kontext und empfiehlt die Auswahl relevanter Repository-Inhalte, wenn ein Projekt dieses Fenster überschreitet. Der Abruf verwandter Ausschnitte und das Kürzen übergroßer Eingaben sind Vorbereitungsschritte im Repository-Leitfaden. Der Kontext muss Anweisungen, bereitgestellten Code und erzeugte Fortsetzung aufnehmen; daher ist eine gezielte Dateiauswahl oft hilfreicher als ein ungegliederter Projektdump. Die beispielhaften Erzeugungseinstellungen des Herstellers steuern die Länge eines bestimmten Durchlaufs; sie definieren keine universelle maximale Antwortlänge für jede CodeGeeX4-Edition.
Die Reihe beschreibt außerdem angeschlossene Programmierabläufe mit Interpretern, Suche und Funktionsaufrufen. Ein solcher Ablauf benötigt die umgebende Anwendung, die die benannten Werkzeuge bereitstellt und deren Ergebnisse in den Dialog zurückgibt. Geben Sie beim Anfordern ausführbaren Codes die vorgesehene Sprache, die Abhängigkeiten und das erwartete Verhalten an; fordern Sie bei einer Analyse relevante Datei- oder Funktionsverweise an. Kompilieren oder starten Sie die vorgeschlagenen Änderungen in der vorgesehenen Umgebung und prüfen Sie das Verhalten anhand der bereitgestellten Anforderung, bevor Sie sie in ein Projekt übernehmen.
", "aboutText": "CodeGeeX4 ist eine mehrsprachige Programmiermodellfamilie für Programmierhilfe und Arbeit über zusammengehörige Quelldateien hinweg. Der Hersteller veröffentlicht CodeGeeX4-ALL-9B als quelloffenes Mitglied der Reihe, entwickelt durch fortgesetztes Training von GLM-4-9B. Seine Dokumentation behandelt Codeerzeugung und -vervollständigung, Programmierfragen, Repository-Analyse und angeschlossene Abläufe mit Codeinterpreter, Websuche oder Funktionsaufrufen. Die gewöhnliche Ausgabe ist Text: Code, Erklärungen, Antworten oder mit Dateinamen gekennzeichnete Änderungen, entsprechend der Aufgabenanweisung.\n\nWählen Sie zunächst die Operation und geben Sie dem Modell den benötigten Code. Der native Systemprompt-Leitfaden enthält eigene Anweisungen zum Ergänzen von Kommentaren, Erklären eines Programms, Übersetzen zwischen Programmiersprachen, Prüfen oder Reparieren von Code, Erzeugen von Tests und Beantworten von Fragen zu einer Datei. Fügen Sie für eine Reparatur den fehlerhaften Code, das beobachtete Verhalten und das gewünschte Ergebnis bei. Nennen Sie für eine Übersetzung die Zielprogrammiersprache und stellen Sie die vollständige relevante Funktion bereit. Bei Kommentaren bewahrt die Aufgabenanweisung des Herstellers den Code und ergänzt Kommentare; bei mehreren Aufgaben zur Codeerzeugung verlangt sie ausschließlich Code. Diese Unterschiede machen das Ergebnis als Code oder Erklärung nutzbar, statt das Ausgabeformat unausgesprochen zu lassen.\n\nDie Leitfäden liefern chinesische und englische Systemprompts. Die Sprache der Systemanweisung bestimmt nicht von sich aus die Antwortsprache; fordern Sie diese daher ausdrücklich an, wenn eine Erklärung benötigt wird. Der spezialisierte Prüfleitfaden beschreibt chinesische Ausgabe; der allgemeine Prompt für Programmierassistenten bietet einen separaten Weg, eine Prüfung in einer anderen Antwortsprache anzufordern. Einige Aufgabenvorlagen passen die Kommentarsprache an die Quelle an und schließen gemischte chinesische und englische Ausgabe aus. Wiederholen Sie in einem laufenden Dialog beim Wechsel der Operation die relevante Aufgabenanweisung, damit eine Bitte um Erklärung nicht mit der vorhergehenden Bitte um reine Codeausgabe verwechselt wird.\n\nFür kontextbezogene Vervollständigung beschreibt das native Format die Zieldatei, ihre Programmiersprache und den Code auf beiden Seiten der Einfügestelle. Verwenden Sie den relativen Dateipfad mit ###PATH: und fügen Sie ###LANGUAGE: hinzu; der Leitfaden erlaubt einen leeren Sprachwert, wenn die Sprache unbekannt ist. ###MODE: wählt LINE für eine einzeilige oder BLOCK für eine mehrzeilige Vervollständigung; BLOCK ist der dokumentierte Standard. Die Fill-in-the-Middle-Sequenz enthält zuerst das Suffix, dann das Präfix und dann den fehlenden Mittelteil, markiert mit <|code_suffix|>, <|code_prefix|> und <|code_middle|>. Die Einfügevorlage des Herstellers lässt den Systemprompt weg. Das Bewahren des Suffixes gibt dem Modell den umgebenden Kontrollfluss und den Code, der nach der Einfügung erhalten bleiben muss. Das Ergebnis ist der vorgeschlagene fehlende Code, der anschließend an seiner ursprünglichen Stelle geprüft werden kann.\n\nDateiübergreifende Vervollständigung ergänzt verwandte Ausschnitte als Referenzmaterial, jeweils eingeleitet durch ###REFERENCE: und ein eigenes ###PATH:. Halten Sie diese Referenzen von der Zieldatei und ihrer Einfügestelle getrennt. Stellen Sie etwa beim Vervollständigen einer Funktion, die eine bestehende Hilfsfunktion aufruft, deren Signatur und Implementierung neben Präfix und Suffix der Zielfunktion bereit. Der Leitfaden für projektweite Vervollständigung erweitert diesen Ansatz auf das Erzeugen einer neuen Datei anhand der Projektanforderungen und relevanten bestehenden Codes. Klare Pfade und ausgewählte Abhängigkeiten ermöglichen es, als Beleg bereitgestellten Code von der Datei zu unterscheiden, die das Modell vervollständigen soll.\n\nRepository-Fragen verwenden einen anderen nativen Aufbau: Führen Sie jede Datei unter ###PATH: auf, fügen Sie ihren Code bei und stellen Sie dann die Frage. Ein hilfreicher Auftrag kann fragen, wo ein Wert definiert wird oder wie ein Aufruf zwischen den bereitgestellten Modulen weiterläuft. Repository-Bearbeitung verwendet eine eigene Systemanweisung zum Hinzufügen, Löschen oder Ändern von Dateien und verlangt die Ausgabe als ###PATH: {PATH}, gefolgt vom Code. Bereiten Sie die relevanten Dateien vor und beschreiben Sie die erforderliche Änderung, einschließlich der hinzuzufügenden Datei oder des zu bewahrenden Verhaltens. Lesen Sie die zurückgegebenen, mit Pfaden gekennzeichneten Blöcke als Änderungsvorschläge; sie belegen weder eine bereits erfolgte Repository-Änderung noch eine Codeausführung.\n\nFür das veröffentlichte Mitglied CodeGeeX4-ALL-9B dokumentiert der Hersteller einen 128K-Kontext und empfiehlt die Auswahl relevanter Repository-Inhalte, wenn ein Projekt dieses Fenster überschreitet. Der Abruf verwandter Ausschnitte und das Kürzen übergroßer Eingaben sind Vorbereitungsschritte im Repository-Leitfaden. Der Kontext muss Anweisungen, bereitgestellten Code und erzeugte Fortsetzung aufnehmen; daher ist eine gezielte Dateiauswahl oft hilfreicher als ein ungegliederter Projektdump. Die beispielhaften Erzeugungseinstellungen des Herstellers steuern die Länge eines bestimmten Durchlaufs; sie definieren keine universelle maximale Antwortlänge für jede CodeGeeX4-Edition.\n\nDie Reihe beschreibt außerdem angeschlossene Programmierabläufe mit Interpretern, Suche und Funktionsaufrufen. Ein solcher Ablauf benötigt die umgebende Anwendung, die die benannten Werkzeuge bereitstellt und deren Ergebnisse in den Dialog zurückgibt. Geben Sie beim Anfordern ausführbaren Codes die vorgesehene Sprache, die Abhängigkeiten und das erwartete Verhalten an; fordern Sie bei einer Analyse relevante Datei- oder Funktionsverweise an. Kompilieren oder starten Sie die vorgeschlagenen Änderungen in der vorgesehenen Umgebung und prüfen Sie das Verhalten anhand der bereitgestellten Anforderung, bevor Sie sie in ein Projekt übernehmen.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "8612a9136ba3dba5ffe16ab18deec5cdac1d43a781859a1907dad2d3226cf1fc", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de-at", "methods": [ { "html": "codegeex-4CodeGeeX4 ist eine mehrsprachige Modellfamilie für Codeerzeugung, Vervollständigung, Erklärung, Reparatur und Repository-Fragen. Die nativen Leitfäden behandeln aufgabenspezifische Prompts, das Füllen von Lücken zwischen bestehendem Code und die Verwendung verwandter Dateien zur Vorbereitung von Änderungen mit ausdrücklichen Dateipfaden.
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.
CodeGeeX4 ist eine mehrsprachige Programmiermodellfamilie für Programmierhilfe und Arbeit über zusammengehörige Quelldateien hinweg. Der Hersteller veröffentlicht CodeGeeX4-ALL-9B als quelloffenes Mitglied der Reihe, entwickelt durch fortgesetztes Training von GLM-4-9B. Seine Dokumentation behandelt Codeerzeugung und -vervollständigung, Programmierfragen, Repository-Analyse und angeschlossene Abläufe mit Codeinterpreter, Websuche oder Funktionsaufrufen. Die gewöhnliche Ausgabe ist Text: Code, Erklärungen, Antworten oder mit Dateinamen gekennzeichnete Änderungen, entsprechend der Aufgabenanweisung.
Wählen Sie zunächst die Operation und geben Sie dem Modell den benötigten Code. Der native Systemprompt-Leitfaden enthält eigene Anweisungen zum Ergänzen von Kommentaren, Erklären eines Programms, Übersetzen zwischen Programmiersprachen, Prüfen oder Reparieren von Code, Erzeugen von Tests und Beantworten von Fragen zu einer Datei. Fügen Sie für eine Reparatur den fehlerhaften Code, das beobachtete Verhalten und das gewünschte Ergebnis bei. Nennen Sie für eine Übersetzung die Zielprogrammiersprache und stellen Sie die vollständige relevante Funktion bereit. Bei Kommentaren bewahrt die Aufgabenanweisung des Herstellers den Code und ergänzt Kommentare; bei mehreren Aufgaben zur Codeerzeugung verlangt sie ausschließlich Code. Diese Unterschiede machen das Ergebnis als Code oder Erklärung nutzbar, statt das Ausgabeformat unausgesprochen zu lassen.
Die Leitfäden liefern chinesische und englische Systemprompts. Die Sprache der Systemanweisung bestimmt nicht von sich aus die Antwortsprache; fordern Sie diese daher ausdrücklich an, wenn eine Erklärung benötigt wird. Der spezialisierte Prüfleitfaden beschreibt chinesische Ausgabe; der allgemeine Prompt für Programmierassistenten bietet einen separaten Weg, eine Prüfung in einer anderen Antwortsprache anzufordern. Einige Aufgabenvorlagen passen die Kommentarsprache an die Quelle an und schließen gemischte chinesische und englische Ausgabe aus. Wiederholen Sie in einem laufenden Dialog beim Wechsel der Operation die relevante Aufgabenanweisung, damit eine Bitte um Erklärung nicht mit der vorhergehenden Bitte um reine Codeausgabe verwechselt wird.
Für kontextbezogene Vervollständigung beschreibt das native Format die Zieldatei, ihre Programmiersprache und den Code auf beiden Seiten der Einfügestelle. Verwenden Sie den relativen Dateipfad mit ###PATH: und fügen Sie ###LANGUAGE: hinzu; der Leitfaden erlaubt einen leeren Sprachwert, wenn die Sprache unbekannt ist. ###MODE: wählt LINE für eine einzeilige oder BLOCK für eine mehrzeilige Vervollständigung; BLOCK ist der dokumentierte Standard. Die Fill-in-the-Middle-Sequenz enthält zuerst das Suffix, dann das Präfix und dann den fehlenden Mittelteil, markiert mit <|code_suffix|>, <|code_prefix|> und <|code_middle|>. Die Einfügevorlage des Herstellers lässt den Systemprompt weg. Das Bewahren des Suffixes gibt dem Modell den umgebenden Kontrollfluss und den Code, der nach der Einfügung erhalten bleiben muss. Das Ergebnis ist der vorgeschlagene fehlende Code, der anschließend an seiner ursprünglichen Stelle geprüft werden kann.
Dateiübergreifende Vervollständigung ergänzt verwandte Ausschnitte als Referenzmaterial, jeweils eingeleitet durch ###REFERENCE: und ein eigenes ###PATH:. Halten Sie diese Referenzen von der Zieldatei und ihrer Einfügestelle getrennt. Stellen Sie etwa beim Vervollständigen einer Funktion, die eine bestehende Hilfsfunktion aufruft, deren Signatur und Implementierung neben Präfix und Suffix der Zielfunktion bereit. Der Leitfaden für projektweite Vervollständigung erweitert diesen Ansatz auf das Erzeugen einer neuen Datei anhand der Projektanforderungen und relevanten bestehenden Codes. Klare Pfade und ausgewählte Abhängigkeiten ermöglichen es, als Beleg bereitgestellten Code von der Datei zu unterscheiden, die das Modell vervollständigen soll.
Repository-Fragen verwenden einen anderen nativen Aufbau: Führen Sie jede Datei unter ###PATH: auf, fügen Sie ihren Code bei und stellen Sie dann die Frage. Ein hilfreicher Auftrag kann fragen, wo ein Wert definiert wird oder wie ein Aufruf zwischen den bereitgestellten Modulen weiterläuft. Repository-Bearbeitung verwendet eine eigene Systemanweisung zum Hinzufügen, Löschen oder Ändern von Dateien und verlangt die Ausgabe als ###PATH: {PATH}, gefolgt vom Code. Bereiten Sie die relevanten Dateien vor und beschreiben Sie die erforderliche Änderung, einschließlich der hinzuzufügenden Datei oder des zu bewahrenden Verhaltens. Lesen Sie die zurückgegebenen, mit Pfaden gekennzeichneten Blöcke als Änderungsvorschläge; sie belegen weder eine bereits erfolgte Repository-Änderung noch eine Codeausführung.
Für das veröffentlichte Mitglied CodeGeeX4-ALL-9B dokumentiert der Hersteller einen 128K-Kontext und empfiehlt die Auswahl relevanter Repository-Inhalte, wenn ein Projekt dieses Fenster überschreitet. Der Abruf verwandter Ausschnitte und das Kürzen übergroßer Eingaben sind Vorbereitungsschritte im Repository-Leitfaden. Der Kontext muss Anweisungen, bereitgestellten Code und erzeugte Fortsetzung aufnehmen; daher ist eine gezielte Dateiauswahl oft hilfreicher als ein ungegliederter Projektdump. Die beispielhaften Erzeugungseinstellungen des Herstellers steuern die Länge eines bestimmten Durchlaufs; sie definieren keine universelle maximale Antwortlänge für jede CodeGeeX4-Edition.
Die Reihe beschreibt außerdem angeschlossene Programmierabläufe mit Interpretern, Suche und Funktionsaufrufen. Ein solcher Ablauf benötigt die umgebende Anwendung, die die benannten Werkzeuge bereitstellt und deren Ergebnisse in den Dialog zurückgibt. Geben Sie beim Anfordern ausführbaren Codes die vorgesehene Sprache, die Abhängigkeiten und das erwartete Verhalten an; fordern Sie bei einer Analyse relevante Datei- oder Funktionsverweise an. Kompilieren oder starten Sie die vorgeschlagenen Änderungen in der vorgesehenen Umgebung und prüfen Sie das Verhalten anhand der bereitgestellten Anforderung, bevor Sie sie in ein Projekt übernehmen.
POST /v1/chat/completionstexttext| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits codegeex-4 | 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.
| Konfiguration | Tarifstaffel | Gebühr |
|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Gebühr Eingabe · Eingabetoken $0.028 / 1K Tokens Ausgabe · Ausgabetoken $0.028 / 1K Tokens Eingabe · Cache lesen $0 / 1K Tokens Eingabe · In Cache schreiben $0 / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
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":"codegeex-4","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="codegeex-4", 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 codegeex-4
/chat/completions
codegeex-4CodeGeeX4 ist eine mehrsprachige Modellfamilie für Codeerzeugung, Vervollständigung, Erklärung, Reparatur und Repository-Fragen. Die nativen Leitfäden behandeln aufgabenspezifische Prompts, das Füllen von Lücken zwischen bestehendem Code und die Verwendung verwandter Dateien zur Vorbereitung von Änderungen mit ausdrücklichen Dateipfaden.
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.
CodeGeeX4 ist eine mehrsprachige Programmiermodellfamilie für Programmierhilfe und Arbeit über zusammengehörige Quelldateien hinweg. Der Hersteller veröffentlicht CodeGeeX4-ALL-9B als quelloffenes Mitglied der Reihe, entwickelt durch fortgesetztes Training von GLM-4-9B. Seine Dokumentation behandelt Codeerzeugung und -vervollständigung, Programmierfragen, Repository-Analyse und angeschlossene Abläufe mit Codeinterpreter, Websuche oder Funktionsaufrufen. Die gewöhnliche Ausgabe ist Text: Code, Erklärungen, Antworten oder mit Dateinamen gekennzeichnete Änderungen, entsprechend der Aufgabenanweisung.
Wählen Sie zunächst die Operation und geben Sie dem Modell den benötigten Code. Der native Systemprompt-Leitfaden enthält eigene Anweisungen zum Ergänzen von Kommentaren, Erklären eines Programms, Übersetzen zwischen Programmiersprachen, Prüfen oder Reparieren von Code, Erzeugen von Tests und Beantworten von Fragen zu einer Datei. Fügen Sie für eine Reparatur den fehlerhaften Code, das beobachtete Verhalten und das gewünschte Ergebnis bei. Nennen Sie für eine Übersetzung die Zielprogrammiersprache und stellen Sie die vollständige relevante Funktion bereit. Bei Kommentaren bewahrt die Aufgabenanweisung des Herstellers den Code und ergänzt Kommentare; bei mehreren Aufgaben zur Codeerzeugung verlangt sie ausschließlich Code. Diese Unterschiede machen das Ergebnis als Code oder Erklärung nutzbar, statt das Ausgabeformat unausgesprochen zu lassen.
Die Leitfäden liefern chinesische und englische Systemprompts. Die Sprache der Systemanweisung bestimmt nicht von sich aus die Antwortsprache; fordern Sie diese daher ausdrücklich an, wenn eine Erklärung benötigt wird. Der spezialisierte Prüfleitfaden beschreibt chinesische Ausgabe; der allgemeine Prompt für Programmierassistenten bietet einen separaten Weg, eine Prüfung in einer anderen Antwortsprache anzufordern. Einige Aufgabenvorlagen passen die Kommentarsprache an die Quelle an und schließen gemischte chinesische und englische Ausgabe aus. Wiederholen Sie in einem laufenden Dialog beim Wechsel der Operation die relevante Aufgabenanweisung, damit eine Bitte um Erklärung nicht mit der vorhergehenden Bitte um reine Codeausgabe verwechselt wird.
Für kontextbezogene Vervollständigung beschreibt das native Format die Zieldatei, ihre Programmiersprache und den Code auf beiden Seiten der Einfügestelle. Verwenden Sie den relativen Dateipfad mit ###PATH: und fügen Sie ###LANGUAGE: hinzu; der Leitfaden erlaubt einen leeren Sprachwert, wenn die Sprache unbekannt ist. ###MODE: wählt LINE für eine einzeilige oder BLOCK für eine mehrzeilige Vervollständigung; BLOCK ist der dokumentierte Standard. Die Fill-in-the-Middle-Sequenz enthält zuerst das Suffix, dann das Präfix und dann den fehlenden Mittelteil, markiert mit <|code_suffix|>, <|code_prefix|> und <|code_middle|>. Die Einfügevorlage des Herstellers lässt den Systemprompt weg. Das Bewahren des Suffixes gibt dem Modell den umgebenden Kontrollfluss und den Code, der nach der Einfügung erhalten bleiben muss. Das Ergebnis ist der vorgeschlagene fehlende Code, der anschließend an seiner ursprünglichen Stelle geprüft werden kann.
Dateiübergreifende Vervollständigung ergänzt verwandte Ausschnitte als Referenzmaterial, jeweils eingeleitet durch ###REFERENCE: und ein eigenes ###PATH:. Halten Sie diese Referenzen von der Zieldatei und ihrer Einfügestelle getrennt. Stellen Sie etwa beim Vervollständigen einer Funktion, die eine bestehende Hilfsfunktion aufruft, deren Signatur und Implementierung neben Präfix und Suffix der Zielfunktion bereit. Der Leitfaden für projektweite Vervollständigung erweitert diesen Ansatz auf das Erzeugen einer neuen Datei anhand der Projektanforderungen und relevanten bestehenden Codes. Klare Pfade und ausgewählte Abhängigkeiten ermöglichen es, als Beleg bereitgestellten Code von der Datei zu unterscheiden, die das Modell vervollständigen soll.
Repository-Fragen verwenden einen anderen nativen Aufbau: Führen Sie jede Datei unter ###PATH: auf, fügen Sie ihren Code bei und stellen Sie dann die Frage. Ein hilfreicher Auftrag kann fragen, wo ein Wert definiert wird oder wie ein Aufruf zwischen den bereitgestellten Modulen weiterläuft. Repository-Bearbeitung verwendet eine eigene Systemanweisung zum Hinzufügen, Löschen oder Ändern von Dateien und verlangt die Ausgabe als ###PATH: {PATH}, gefolgt vom Code. Bereiten Sie die relevanten Dateien vor und beschreiben Sie die erforderliche Änderung, einschließlich der hinzuzufügenden Datei oder des zu bewahrenden Verhaltens. Lesen Sie die zurückgegebenen, mit Pfaden gekennzeichneten Blöcke als Änderungsvorschläge; sie belegen weder eine bereits erfolgte Repository-Änderung noch eine Codeausführung.
Für das veröffentlichte Mitglied CodeGeeX4-ALL-9B dokumentiert der Hersteller einen 128K-Kontext und empfiehlt die Auswahl relevanter Repository-Inhalte, wenn ein Projekt dieses Fenster überschreitet. Der Abruf verwandter Ausschnitte und das Kürzen übergroßer Eingaben sind Vorbereitungsschritte im Repository-Leitfaden. Der Kontext muss Anweisungen, bereitgestellten Code und erzeugte Fortsetzung aufnehmen; daher ist eine gezielte Dateiauswahl oft hilfreicher als ein ungegliederter Projektdump. Die beispielhaften Erzeugungseinstellungen des Herstellers steuern die Länge eines bestimmten Durchlaufs; sie definieren keine universelle maximale Antwortlänge für jede CodeGeeX4-Edition.
Die Reihe beschreibt außerdem angeschlossene Programmierabläufe mit Interpretern, Suche und Funktionsaufrufen. Ein solcher Ablauf benötigt die umgebende Anwendung, die die benannten Werkzeuge bereitstellt und deren Ergebnisse in den Dialog zurückgibt. Geben Sie beim Anfordern ausführbaren Codes die vorgesehene Sprache, die Abhängigkeiten und das erwartete Verhalten an; fordern Sie bei einer Analyse relevante Datei- oder Funktionsverweise an. Kompilieren oder starten Sie die vorgeschlagenen Änderungen in der vorgesehenen Umgebung und prüfen Sie das Verhalten anhand der bereitgestellten Anforderung, bevor Sie sie in ein Projekt übernehmen.
POST /v1/messagestextjson, sse| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits codegeex-4 | 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.
| Konfiguration | Tarifstaffel | Gebühr |
|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Gebühr Eingabe · Eingabetoken $0.028 / 1K Tokens Ausgabe · Ausgabetoken $0.028 / 1K Tokens Eingabe · Cache lesen $0 / 1K Tokens Eingabe · In Cache schreiben $0 / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
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": "codegeex-4",\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': 'codegeex-4', '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': 'codegeex-4', '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 codegeex-4
/chat/completions