Kimi-Dev-72B ist das Programmiersprachmodell von Moonshot AI für Softwareentwicklungsaufgaben mit besonderem Schwerpunkt auf der Lösung von Problemen in bestehenden Repositories. Es nimmt Text entgegen und erzeugt Text, darunter Codevorschläge, Erklärungen und Tests. Sein Entwurf geht vom Basismodell Qwen 2.5 72B aus und entwickelt die Fähigkeiten, die nötig sind, um einen Fehlerbericht in eine überprüfbare Änderung zu überführen.
BugFixer und TestWriter. Der Hersteller behandelt die Korrektur einer Implementierung und das Schreiben des Tests, der ihren Defekt reproduziert, als einander ergänzende Fähigkeiten. Beide verwenden dieselbe zweistufige Struktur: die zu bearbeitende Datei identifizieren und anschließend die relevante Codeänderung vornehmen. Ein nützlicher Reparaturtest schlägt fehl, wenn der Fehler vorhanden ist, und besteht, wenn die beabsichtigte Korrektur angewendet wird. Dadurch erhält das Modell einen praktischen Schwerpunkt auf der Beziehung zwischen Bericht, Implementierung und ausführbarem Beleg.
Zwischentraining. Das Team berichtet von ungefähr 150 Milliarden Tokens zusätzlichen Trainings aus hochwertigem realem Material, darunter Millionen von Issues und Pull-Request-Commits. Diese Phase vermittelt Muster darin, wie Entwickler einen Bericht untersuchen, Code bearbeiten und Unit-Tests schreiben. Das Team schließt außerdem Repositories aus SWE-bench Verified aus dieser Trainingssammlung aus, um Kontamination zu verringern.
Bestärkendes Lernen. Nach dem überwachten Feinabstimmen konzentriert sich die Phase des bestärkenden Lernens auf Codeänderungen. Ihre Belohnung verwendet das abschließende Ausführungsergebnis in einem containerisierten Repository; der Hersteller beschreibt Erfolg dadurch, dass die vollständige Testsuite besteht. Der Trainingsprozess filtert Aufgaben aus, bei denen mehrere gezogene Versuche sämtlich scheitern, führt schrittweise schwierigere Prompts ein und verwendet jüngste erfolgreiche Beispiele erneut, um wirksame Reparaturmuster zu stärken.
Ein reales Problem vorbereiten. Stellen Sie das erwartete Verhalten, das beobachtete Ergebnis und eine minimale Reproduktion bereit und fügen Sie dann die relevanten Quelldateien, Fehlerausgaben und bestehenden Tests bei. Lassen Sie Dateipfade und Funktionsnamen unverändert. Bitten Sie das Modell, die wahrscheinliche Datei zu identifizieren und zu erklären, wie sich der Fehler aus der bereitgestellten Implementierung ergibt, bevor es einen Patch vorlegt. Das entstehende Artefakt sollte angeben, welcher Code sich ändert, warum die Änderung den Bericht behandelt und welches bestehende Verhalten sie bewahren muss.
Den Regressionstest vorbereiten. Geben Sie die aktuellen Testkonventionen des Projekts und repräsentative Testdaten an. Verlangen Sie einen Test, der den ursprünglichen Fehler auslöst, zusammen mit der Prüfbedingung (Assertion), die korrektes von falschem Verhalten unterscheidet. Benennen Sie bei einem Randfallbericht die Grenzbedingung, statt allgemeine zusätzliche Abdeckung zu verlangen. Eine nützliche Antwort kann sowohl eine minimale Änderung als auch einen gezielten Test enthalten, sodass die prüfende Person den Reparaturvorschlag direkt mit dem Problem vergleichen kann.
Selbstspiel zur Testzeit. Moonshots Forschungsablauf lässt außerdem Vorschläge für Fehlerbehebung und Testschreiben einander prüfen. Das ist eine Evaluations- und Orchestrierungstechnik rund um das Modell: Ein Testkandidat kann einen Patch herausfordern, und ein Patch kann anhand des Tests geprüft werden. In einer Anwendung kann dieselbe Idee eine Prüfanfrage anleiten, die vor der Annahme der endgültigen Änderung ein Gegenbeispiel zur vorgeschlagenen Korrektur verlangt.
Die Textantwort ist ein Vorschlag, bis sie im tatsächlichen Repository angewendet und erprobt wird. Dateizugriff, Änderungen, Containerausführung und Testergebnisse kommen aus der umgebenden Entwicklungsumgebung. Fügen Sie die Ausgaben dieser Prüfungen einer Folgeanfrage bei, damit das Modell über den beobachteten Fehler statt über einen vorgestellten Lauf nachdenken kann. Bewahren Sie Projektvorgaben und verlangen Sie die kleinste begründete Änderung, wenn das Problem eine ausgereifte Codebasis betrifft.
", "aboutText": "Kimi-Dev-72B ist das Programmiersprachmodell von Moonshot AI für Softwareentwicklungsaufgaben mit besonderem Schwerpunkt auf der Lösung von Problemen in bestehenden Repositories. Es nimmt Text entgegen und erzeugt Text, darunter Codevorschläge, Erklärungen und Tests. Sein Entwurf geht vom Basismodell Qwen 2.5 72B aus und entwickelt die Fähigkeiten, die nötig sind, um einen Fehlerbericht in eine überprüfbare Änderung zu überführen.\n\nBugFixer und TestWriter. Der Hersteller behandelt die Korrektur einer Implementierung und das Schreiben des Tests, der ihren Defekt reproduziert, als einander ergänzende Fähigkeiten. Beide verwenden dieselbe zweistufige Struktur: die zu bearbeitende Datei identifizieren und anschließend die relevante Codeänderung vornehmen. Ein nützlicher Reparaturtest schlägt fehl, wenn der Fehler vorhanden ist, und besteht, wenn die beabsichtigte Korrektur angewendet wird. Dadurch erhält das Modell einen praktischen Schwerpunkt auf der Beziehung zwischen Bericht, Implementierung und ausführbarem Beleg.\n\nZwischentraining. Das Team berichtet von ungefähr 150 Milliarden Tokens zusätzlichen Trainings aus hochwertigem realem Material, darunter Millionen von Issues und Pull-Request-Commits. Diese Phase vermittelt Muster darin, wie Entwickler einen Bericht untersuchen, Code bearbeiten und Unit-Tests schreiben. Das Team schließt außerdem Repositories aus SWE-bench Verified aus dieser Trainingssammlung aus, um Kontamination zu verringern.\n\nBestärkendes Lernen. Nach dem überwachten Feinabstimmen konzentriert sich die Phase des bestärkenden Lernens auf Codeänderungen. Ihre Belohnung verwendet das abschließende Ausführungsergebnis in einem containerisierten Repository; der Hersteller beschreibt Erfolg dadurch, dass die vollständige Testsuite besteht. Der Trainingsprozess filtert Aufgaben aus, bei denen mehrere gezogene Versuche sämtlich scheitern, führt schrittweise schwierigere Prompts ein und verwendet jüngste erfolgreiche Beispiele erneut, um wirksame Reparaturmuster zu stärken.\n\nEin reales Problem vorbereiten. Stellen Sie das erwartete Verhalten, das beobachtete Ergebnis und eine minimale Reproduktion bereit und fügen Sie dann die relevanten Quelldateien, Fehlerausgaben und bestehenden Tests bei. Lassen Sie Dateipfade und Funktionsnamen unverändert. Bitten Sie das Modell, die wahrscheinliche Datei zu identifizieren und zu erklären, wie sich der Fehler aus der bereitgestellten Implementierung ergibt, bevor es einen Patch vorlegt. Das entstehende Artefakt sollte angeben, welcher Code sich ändert, warum die Änderung den Bericht behandelt und welches bestehende Verhalten sie bewahren muss.\n\nDen Regressionstest vorbereiten. Geben Sie die aktuellen Testkonventionen des Projekts und repräsentative Testdaten an. Verlangen Sie einen Test, der den ursprünglichen Fehler auslöst, zusammen mit der Prüfbedingung (Assertion), die korrektes von falschem Verhalten unterscheidet. Benennen Sie bei einem Randfallbericht die Grenzbedingung, statt allgemeine zusätzliche Abdeckung zu verlangen. Eine nützliche Antwort kann sowohl eine minimale Änderung als auch einen gezielten Test enthalten, sodass die prüfende Person den Reparaturvorschlag direkt mit dem Problem vergleichen kann.\n\nSelbstspiel zur Testzeit. Moonshots Forschungsablauf lässt außerdem Vorschläge für Fehlerbehebung und Testschreiben einander prüfen. Das ist eine Evaluations- und Orchestrierungstechnik rund um das Modell: Ein Testkandidat kann einen Patch herausfordern, und ein Patch kann anhand des Tests geprüft werden. In einer Anwendung kann dieselbe Idee eine Prüfanfrage anleiten, die vor der Annahme der endgültigen Änderung ein Gegenbeispiel zur vorgeschlagenen Korrektur verlangt.\n\nDie Textantwort ist ein Vorschlag, bis sie im tatsächlichen Repository angewendet und erprobt wird. Dateizugriff, Änderungen, Containerausführung und Testergebnisse kommen aus der umgebenden Entwicklungsumgebung. Fügen Sie die Ausgaben dieser Prüfungen einer Folgeanfrage bei, damit das Modell über den beobachteten Fehler statt über einen vorgestellten Lauf nachdenken kann. Bewahren Sie Projektvorgaben und verlangen Sie die kleinste begründete Änderung, wenn das Problem eine ausgereifte Codebasis betrifft.", "editorialOverlay": { "copy_fields": { "practical_html": "Technisches Beispiel auf Englisch
Fix a mutable default argument\n\nIssue in utils.py: def add_tag(tag, tags=[]): tags.append(tag); return tags. Separate calls unexpectedly share prior tags. Expected behavior: omitted tags starts a fresh list; an explicitly supplied list is still updated. Propose the smallest patch and a regression test using standard unittest that fails on the original. Keep the function name and argument order.A focused utils.py patch and unittest cases covering independent defaults and explicit-list mutation.Check the regression makes two independent calls and detects leakage between them.moonshotai/Kimi-Dev-72BKimi-Dev-72B ist das Programmiermodell von Moonshot AI zur Lösung von Softwareproblemen. Sein Entwurf verbindet Fehlerbehebung mit dem Schreiben von Regressionstests: relevante Dateien auffinden, einen Patch vorschlagen und einen Test erzeugen, der den ursprünglichen Fehler nachweist.
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.
Kimi-Dev-72B ist das Programmiersprachmodell von Moonshot AI für Softwareentwicklungsaufgaben mit besonderem Schwerpunkt auf der Lösung von Problemen in bestehenden Repositories. Es nimmt Text entgegen und erzeugt Text, darunter Codevorschläge, Erklärungen und Tests. Sein Entwurf geht vom Basismodell Qwen 2.5 72B aus und entwickelt die Fähigkeiten, die nötig sind, um einen Fehlerbericht in eine überprüfbare Änderung zu überführen.
BugFixer und TestWriter. Der Hersteller behandelt die Korrektur einer Implementierung und das Schreiben des Tests, der ihren Defekt reproduziert, als einander ergänzende Fähigkeiten. Beide verwenden dieselbe zweistufige Struktur: die zu bearbeitende Datei identifizieren und anschließend die relevante Codeänderung vornehmen. Ein nützlicher Reparaturtest schlägt fehl, wenn der Fehler vorhanden ist, und besteht, wenn die beabsichtigte Korrektur angewendet wird. Dadurch erhält das Modell einen praktischen Schwerpunkt auf der Beziehung zwischen Bericht, Implementierung und ausführbarem Beleg.
Zwischentraining. Das Team berichtet von ungefähr 150 Milliarden Tokens zusätzlichen Trainings aus hochwertigem realem Material, darunter Millionen von Issues und Pull-Request-Commits. Diese Phase vermittelt Muster darin, wie Entwickler einen Bericht untersuchen, Code bearbeiten und Unit-Tests schreiben. Das Team schließt außerdem Repositories aus SWE-bench Verified aus dieser Trainingssammlung aus, um Kontamination zu verringern.
Bestärkendes Lernen. Nach dem überwachten Feinabstimmen konzentriert sich die Phase des bestärkenden Lernens auf Codeänderungen. Ihre Belohnung verwendet das abschließende Ausführungsergebnis in einem containerisierten Repository; der Hersteller beschreibt Erfolg dadurch, dass die vollständige Testsuite besteht. Der Trainingsprozess filtert Aufgaben aus, bei denen mehrere gezogene Versuche sämtlich scheitern, führt schrittweise schwierigere Prompts ein und verwendet jüngste erfolgreiche Beispiele erneut, um wirksame Reparaturmuster zu stärken.
Ein reales Problem vorbereiten. Stellen Sie das erwartete Verhalten, das beobachtete Ergebnis und eine minimale Reproduktion bereit und fügen Sie dann die relevanten Quelldateien, Fehlerausgaben und bestehenden Tests bei. Lassen Sie Dateipfade und Funktionsnamen unverändert. Bitten Sie das Modell, die wahrscheinliche Datei zu identifizieren und zu erklären, wie sich der Fehler aus der bereitgestellten Implementierung ergibt, bevor es einen Patch vorlegt. Das entstehende Artefakt sollte angeben, welcher Code sich ändert, warum die Änderung den Bericht behandelt und welches bestehende Verhalten sie bewahren muss.
Den Regressionstest vorbereiten. Geben Sie die aktuellen Testkonventionen des Projekts und repräsentative Testdaten an. Verlangen Sie einen Test, der den ursprünglichen Fehler auslöst, zusammen mit der Prüfbedingung (Assertion), die korrektes von falschem Verhalten unterscheidet. Benennen Sie bei einem Randfallbericht die Grenzbedingung, statt allgemeine zusätzliche Abdeckung zu verlangen. Eine nützliche Antwort kann sowohl eine minimale Änderung als auch einen gezielten Test enthalten, sodass die prüfende Person den Reparaturvorschlag direkt mit dem Problem vergleichen kann.
Selbstspiel zur Testzeit. Moonshots Forschungsablauf lässt außerdem Vorschläge für Fehlerbehebung und Testschreiben einander prüfen. Das ist eine Evaluations- und Orchestrierungstechnik rund um das Modell: Ein Testkandidat kann einen Patch herausfordern, und ein Patch kann anhand des Tests geprüft werden. In einer Anwendung kann dieselbe Idee eine Prüfanfrage anleiten, die vor der Annahme der endgültigen Änderung ein Gegenbeispiel zur vorgeschlagenen Korrektur verlangt.
Die Textantwort ist ein Vorschlag, bis sie im tatsächlichen Repository angewendet und erprobt wird. Dateizugriff, Änderungen, Containerausführung und Testergebnisse kommen aus der umgebenden Entwicklungsumgebung. Fügen Sie die Ausgaben dieser Prüfungen einer Folgeanfrage bei, damit das Modell über den beobachteten Fehler statt über einen vorgestellten Lauf nachdenken kann. Bewahren Sie Projektvorgaben und verlangen Sie die kleinste begründete Änderung, wenn das Problem eine ausgereifte Codebasis betrifft.
POST /v1/chat/completionstexttext| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits moonshotai/Kimi-Dev-72B | 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.
| Konfiguration | Tarifstaffel | Gebühr |
|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Gebühr Eingabe · Eingabetoken $0.0006 / 1K Tokens Ausgabe · Ausgabetoken $0.00228 / 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": "moonshotai/Kimi-Dev-72B", "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='moonshotai/Kimi-Dev-72B',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='moonshotai/Kimi-Dev-72B',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 moonshotai/Kimi-Dev-72B
Verwenden Sie die oben angezeigten Methodenpfade.
moonshotai/Kimi-Dev-72BKimi-Dev-72B ist das Programmiermodell von Moonshot AI zur Lösung von Softwareproblemen. Sein Entwurf verbindet Fehlerbehebung mit dem Schreiben von Regressionstests: relevante Dateien auffinden, einen Patch vorschlagen und einen Test erzeugen, der den ursprünglichen Fehler nachweist.
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.
Kimi-Dev-72B ist das Programmiersprachmodell von Moonshot AI für Softwareentwicklungsaufgaben mit besonderem Schwerpunkt auf der Lösung von Problemen in bestehenden Repositories. Es nimmt Text entgegen und erzeugt Text, darunter Codevorschläge, Erklärungen und Tests. Sein Entwurf geht vom Basismodell Qwen 2.5 72B aus und entwickelt die Fähigkeiten, die nötig sind, um einen Fehlerbericht in eine überprüfbare Änderung zu überführen.
BugFixer und TestWriter. Der Hersteller behandelt die Korrektur einer Implementierung und das Schreiben des Tests, der ihren Defekt reproduziert, als einander ergänzende Fähigkeiten. Beide verwenden dieselbe zweistufige Struktur: die zu bearbeitende Datei identifizieren und anschließend die relevante Codeänderung vornehmen. Ein nützlicher Reparaturtest schlägt fehl, wenn der Fehler vorhanden ist, und besteht, wenn die beabsichtigte Korrektur angewendet wird. Dadurch erhält das Modell einen praktischen Schwerpunkt auf der Beziehung zwischen Bericht, Implementierung und ausführbarem Beleg.
Zwischentraining. Das Team berichtet von ungefähr 150 Milliarden Tokens zusätzlichen Trainings aus hochwertigem realem Material, darunter Millionen von Issues und Pull-Request-Commits. Diese Phase vermittelt Muster darin, wie Entwickler einen Bericht untersuchen, Code bearbeiten und Unit-Tests schreiben. Das Team schließt außerdem Repositories aus SWE-bench Verified aus dieser Trainingssammlung aus, um Kontamination zu verringern.
Bestärkendes Lernen. Nach dem überwachten Feinabstimmen konzentriert sich die Phase des bestärkenden Lernens auf Codeänderungen. Ihre Belohnung verwendet das abschließende Ausführungsergebnis in einem containerisierten Repository; der Hersteller beschreibt Erfolg dadurch, dass die vollständige Testsuite besteht. Der Trainingsprozess filtert Aufgaben aus, bei denen mehrere gezogene Versuche sämtlich scheitern, führt schrittweise schwierigere Prompts ein und verwendet jüngste erfolgreiche Beispiele erneut, um wirksame Reparaturmuster zu stärken.
Ein reales Problem vorbereiten. Stellen Sie das erwartete Verhalten, das beobachtete Ergebnis und eine minimale Reproduktion bereit und fügen Sie dann die relevanten Quelldateien, Fehlerausgaben und bestehenden Tests bei. Lassen Sie Dateipfade und Funktionsnamen unverändert. Bitten Sie das Modell, die wahrscheinliche Datei zu identifizieren und zu erklären, wie sich der Fehler aus der bereitgestellten Implementierung ergibt, bevor es einen Patch vorlegt. Das entstehende Artefakt sollte angeben, welcher Code sich ändert, warum die Änderung den Bericht behandelt und welches bestehende Verhalten sie bewahren muss.
Den Regressionstest vorbereiten. Geben Sie die aktuellen Testkonventionen des Projekts und repräsentative Testdaten an. Verlangen Sie einen Test, der den ursprünglichen Fehler auslöst, zusammen mit der Prüfbedingung (Assertion), die korrektes von falschem Verhalten unterscheidet. Benennen Sie bei einem Randfallbericht die Grenzbedingung, statt allgemeine zusätzliche Abdeckung zu verlangen. Eine nützliche Antwort kann sowohl eine minimale Änderung als auch einen gezielten Test enthalten, sodass die prüfende Person den Reparaturvorschlag direkt mit dem Problem vergleichen kann.
Selbstspiel zur Testzeit. Moonshots Forschungsablauf lässt außerdem Vorschläge für Fehlerbehebung und Testschreiben einander prüfen. Das ist eine Evaluations- und Orchestrierungstechnik rund um das Modell: Ein Testkandidat kann einen Patch herausfordern, und ein Patch kann anhand des Tests geprüft werden. In einer Anwendung kann dieselbe Idee eine Prüfanfrage anleiten, die vor der Annahme der endgültigen Änderung ein Gegenbeispiel zur vorgeschlagenen Korrektur verlangt.
Die Textantwort ist ein Vorschlag, bis sie im tatsächlichen Repository angewendet und erprobt wird. Dateizugriff, Änderungen, Containerausführung und Testergebnisse kommen aus der umgebenden Entwicklungsumgebung. Fügen Sie die Ausgaben dieser Prüfungen einer Folgeanfrage bei, damit das Modell über den beobachteten Fehler statt über einen vorgestellten Lauf nachdenken kann. Bewahren Sie Projektvorgaben und verlangen Sie die kleinste begründete Änderung, wenn das Problem eine ausgereifte Codebasis betrifft.
POST /v1/messagestextjson, sse| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits moonshotai/Kimi-Dev-72B | 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.0006 / 1K Tokens Ausgabe · Ausgabetoken $0.00228 / 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": "moonshotai/Kimi-Dev-72B",\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': 'moonshotai/Kimi-Dev-72B', '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': 'moonshotai/Kimi-Dev-72B', '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 moonshotai/Kimi-Dev-72B
Verwenden Sie die oben angezeigten Methodenpfade.
Technisches Beispiel auf Englisch
Fix a mutable default argument\n\nIssue in utils.py: def add_tag(tag, tags=[]): tags.append(tag); return tags. Separate calls unexpectedly share prior tags. Expected behavior: omitted tags starts a fresh list; an explicitly supplied list is still updated. Propose the smallest patch and a regression test using standard unittest that fails on the original. Keep the function name and argument order.A focused utils.py patch and unittest cases covering independent defaults and explicit-list mutation.Check the regression makes two independent calls and detects leakage between them.