Kimi-Dev-72B è il modello linguistico di programmazione di Moonshot AI per compiti di ingegneria del software, con particolare attenzione alla risoluzione di problemi nei repository esistenti. Accetta testo e produce testo, incluse proposte di codice, spiegazioni e test. Il suo design parte dal modello base Qwen 2.5 72B e sviluppa le capacità necessarie a trasformare una segnalazione di bug in una modifica esaminabile.
BugFixer e TestWriter. Il produttore tratta la correzione di un’implementazione e la scrittura del test che ne riproduce il difetto come capacità complementari. Entrambe usano la stessa struttura in due fasi: identificare il file che richiede attenzione, poi apportare la modifica pertinente al codice. Un test utile per la correzione fallisce quando il bug è presente e passa quando viene applicata la correzione prevista. Questo dà al modello un’attenzione pratica alla relazione tra segnalazione, implementazione ed evidenze eseguibili.
Addestramento intermedio. Il team riporta circa 150 miliardi di token di addestramento aggiuntivo da materiale reale di alta qualità, inclusi milioni di issue e commit di pull request. Questa fase insegna schemi nel modo in cui gli sviluppatori indagano una segnalazione, modificano codice e scrivono test unitari. Il team esclude inoltre i repository SWE-bench Verified da questa raccolta di addestramento per ridurre la contaminazione.
Apprendimento per rinforzo. Dopo il fine-tuning supervisionato, la fase di apprendimento per rinforzo si concentra sulle modifiche di codice. La ricompensa usa l’esito finale dell’esecuzione in un repository containerizzato; il produttore descrive il successo come superamento dell’intera suite di test. Il processo di addestramento filtra i compiti su cui più tentativi campionati falliscono tutti, introduce gradualmente prompt più difficili e riusa esempi recenti riusciti per rafforzare schemi di correzione efficaci.
Prepara un problema reale. Fornisci comportamento atteso, risultato osservato e una riproduzione minima, poi includi file sorgente pertinenti, output degli errori e test esistenti. Mantieni invariati percorsi dei file e nomi delle funzioni. Chiedi al modello di identificare il file probabile e spiegare come l’errore derivi dall’implementazione fornita prima di presentare una patch. L’elaborato risultante deve dichiarare quale codice cambia, perché la modifica affronta la segnalazione e quale comportamento esistente deve preservare.
Prepara il test di regressione. Fornisci le convenzioni di test correnti del progetto e fixture rappresentative. Richiedi un test che attivi l’errore originale, insieme all’asserzione che distingue il comportamento corretto da quello errato. Per una segnalazione su un caso limite, indica la condizione di confine, invece di chiedere copertura aggiuntiva generica. Una risposta utile può contenere sia una modifica minima sia un test mirato, consentendo al revisore di confrontare direttamente la correzione proposta con il problema.
Self-play durante la valutazione. Il flusso di ricerca di Moonshot consente inoltre alle proposte di correzione dei bug e di scrittura dei test di verificarsi a vicenda. È una tecnica di valutazione e orchestrazione attorno al modello: un test candidato può mettere alla prova una patch e una patch può essere verificata rispetto al test. In un’applicazione, la stessa idea può guidare una richiesta di revisione che chieda un controesempio a una correzione proposta prima di accettare la modifica finale.
La risposta testuale è una proposta finché non viene applicata ed esercitata nel repository effettivo. Accesso ai file, modifiche, esecuzione in container e risultati dei test provengono dall’ambiente di sviluppo circostante. Includi gli output di quei controlli in una richiesta successiva, affinché il modello possa ragionare sull’errore osservato, anziché su un’esecuzione immaginata. Preserva i vincoli del progetto e chiedi la modifica minima giustificata quando il problema riguarda una base di codice matura.
", "aboutText": "Kimi-Dev-72B è il modello linguistico di programmazione di Moonshot AI per compiti di ingegneria del software, con particolare attenzione alla risoluzione di problemi nei repository esistenti. Accetta testo e produce testo, incluse proposte di codice, spiegazioni e test. Il suo design parte dal modello base Qwen 2.5 72B e sviluppa le capacità necessarie a trasformare una segnalazione di bug in una modifica esaminabile.\n\nBugFixer e TestWriter. Il produttore tratta la correzione di un’implementazione e la scrittura del test che ne riproduce il difetto come capacità complementari. Entrambe usano la stessa struttura in due fasi: identificare il file che richiede attenzione, poi apportare la modifica pertinente al codice. Un test utile per la correzione fallisce quando il bug è presente e passa quando viene applicata la correzione prevista. Questo dà al modello un’attenzione pratica alla relazione tra segnalazione, implementazione ed evidenze eseguibili.\n\nAddestramento intermedio. Il team riporta circa 150 miliardi di token di addestramento aggiuntivo da materiale reale di alta qualità, inclusi milioni di issue e commit di pull request. Questa fase insegna schemi nel modo in cui gli sviluppatori indagano una segnalazione, modificano codice e scrivono test unitari. Il team esclude inoltre i repository SWE-bench Verified da questa raccolta di addestramento per ridurre la contaminazione.\n\nApprendimento per rinforzo. Dopo il fine-tuning supervisionato, la fase di apprendimento per rinforzo si concentra sulle modifiche di codice. La ricompensa usa l’esito finale dell’esecuzione in un repository containerizzato; il produttore descrive il successo come superamento dell’intera suite di test. Il processo di addestramento filtra i compiti su cui più tentativi campionati falliscono tutti, introduce gradualmente prompt più difficili e riusa esempi recenti riusciti per rafforzare schemi di correzione efficaci.\n\nPrepara un problema reale. Fornisci comportamento atteso, risultato osservato e una riproduzione minima, poi includi file sorgente pertinenti, output degli errori e test esistenti. Mantieni invariati percorsi dei file e nomi delle funzioni. Chiedi al modello di identificare il file probabile e spiegare come l’errore derivi dall’implementazione fornita prima di presentare una patch. L’elaborato risultante deve dichiarare quale codice cambia, perché la modifica affronta la segnalazione e quale comportamento esistente deve preservare.\n\nPrepara il test di regressione. Fornisci le convenzioni di test correnti del progetto e fixture rappresentative. Richiedi un test che attivi l’errore originale, insieme all’asserzione che distingue il comportamento corretto da quello errato. Per una segnalazione su un caso limite, indica la condizione di confine, invece di chiedere copertura aggiuntiva generica. Una risposta utile può contenere sia una modifica minima sia un test mirato, consentendo al revisore di confrontare direttamente la correzione proposta con il problema.\n\nSelf-play durante la valutazione. Il flusso di ricerca di Moonshot consente inoltre alle proposte di correzione dei bug e di scrittura dei test di verificarsi a vicenda. È una tecnica di valutazione e orchestrazione attorno al modello: un test candidato può mettere alla prova una patch e una patch può essere verificata rispetto al test. In un’applicazione, la stessa idea può guidare una richiesta di revisione che chieda un controesempio a una correzione proposta prima di accettare la modifica finale.\n\nLa risposta testuale è una proposta finché non viene applicata ed esercitata nel repository effettivo. Accesso ai file, modifiche, esecuzione in container e risultati dei test provengono dall’ambiente di sviluppo circostante. Includi gli output di quei controlli in una richiesta successiva, affinché il modello possa ragionare sull’errore osservato, anziché su un’esecuzione immaginata. Preserva i vincoli del progetto e chiedi la modifica minima giustificata quando il problema riguarda una base di codice matura.", "editorialOverlay": { "copy_fields": { "practical_html": "Esempio tecnico in inglese
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 è il modello di programmazione di Moonshot AI per risolvere problemi software. Il suo design abbina correzione dei bug e scrittura di test di regressione: individuare i file pertinenti, proporre una patch e produrre un test che dimostri l’errore originale.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
Kimi-Dev-72B è il modello linguistico di programmazione di Moonshot AI per compiti di ingegneria del software, con particolare attenzione alla risoluzione di problemi nei repository esistenti. Accetta testo e produce testo, incluse proposte di codice, spiegazioni e test. Il suo design parte dal modello base Qwen 2.5 72B e sviluppa le capacità necessarie a trasformare una segnalazione di bug in una modifica esaminabile.
BugFixer e TestWriter. Il produttore tratta la correzione di un’implementazione e la scrittura del test che ne riproduce il difetto come capacità complementari. Entrambe usano la stessa struttura in due fasi: identificare il file che richiede attenzione, poi apportare la modifica pertinente al codice. Un test utile per la correzione fallisce quando il bug è presente e passa quando viene applicata la correzione prevista. Questo dà al modello un’attenzione pratica alla relazione tra segnalazione, implementazione ed evidenze eseguibili.
Addestramento intermedio. Il team riporta circa 150 miliardi di token di addestramento aggiuntivo da materiale reale di alta qualità, inclusi milioni di issue e commit di pull request. Questa fase insegna schemi nel modo in cui gli sviluppatori indagano una segnalazione, modificano codice e scrivono test unitari. Il team esclude inoltre i repository SWE-bench Verified da questa raccolta di addestramento per ridurre la contaminazione.
Apprendimento per rinforzo. Dopo il fine-tuning supervisionato, la fase di apprendimento per rinforzo si concentra sulle modifiche di codice. La ricompensa usa l’esito finale dell’esecuzione in un repository containerizzato; il produttore descrive il successo come superamento dell’intera suite di test. Il processo di addestramento filtra i compiti su cui più tentativi campionati falliscono tutti, introduce gradualmente prompt più difficili e riusa esempi recenti riusciti per rafforzare schemi di correzione efficaci.
Prepara un problema reale. Fornisci comportamento atteso, risultato osservato e una riproduzione minima, poi includi file sorgente pertinenti, output degli errori e test esistenti. Mantieni invariati percorsi dei file e nomi delle funzioni. Chiedi al modello di identificare il file probabile e spiegare come l’errore derivi dall’implementazione fornita prima di presentare una patch. L’elaborato risultante deve dichiarare quale codice cambia, perché la modifica affronta la segnalazione e quale comportamento esistente deve preservare.
Prepara il test di regressione. Fornisci le convenzioni di test correnti del progetto e fixture rappresentative. Richiedi un test che attivi l’errore originale, insieme all’asserzione che distingue il comportamento corretto da quello errato. Per una segnalazione su un caso limite, indica la condizione di confine, invece di chiedere copertura aggiuntiva generica. Una risposta utile può contenere sia una modifica minima sia un test mirato, consentendo al revisore di confrontare direttamente la correzione proposta con il problema.
Self-play durante la valutazione. Il flusso di ricerca di Moonshot consente inoltre alle proposte di correzione dei bug e di scrittura dei test di verificarsi a vicenda. È una tecnica di valutazione e orchestrazione attorno al modello: un test candidato può mettere alla prova una patch e una patch può essere verificata rispetto al test. In un’applicazione, la stessa idea può guidare una richiesta di revisione che chieda un controesempio a una correzione proposta prima di accettare la modifica finale.
La risposta testuale è una proposta finché non viene applicata ed esercitata nel repository effettivo. Accesso ai file, modifiche, esecuzione in container e risultati dei test provengono dall’ambiente di sviluppo circostante. Includi gli output di quei controlli in una richiesta successiva, affinché il modello possa ragionare sull’errore osservato, anziché su un’esecuzione immaginata. Preserva i vincoli del progetto e chiedi la modifica minima giustificata quando il problema riguarda una base di codice matura.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti moonshotai/Kimi-Dev-72B | Predefinito— |
Campomessages | Tipomessage[] | RequisitoObbligatorio | Valori e limiti Numero minimo di elementi: 1 | Predefinito— |
Campomessages[].role | Tipostring | RequisitoObbligatorio | Valori e limiti Esempi: system, user, assistant, tool, function Condizioni: Questi ruoli sono rappresentati esplicitamente dai tipi di compatibilità del codice sorgente; l’insieme esatto dei ruoli rimane specifico del modello. Dipende dal modello | Predefinito— |
Campomessages[].content | Tipostring|content_part[]|null | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campomessages[].tool_calls | Tipotool_call[] | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campomessages[].tool_call_id | Tipostring | RequisitoFacoltativo | Valori e limiti Si applica quando: role=tool; usa l’ID effettivamente restituito | Predefinito— |
Campomessages[].name | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campomessages[].reasoning_content | Tipostring | RequisitoFacoltativo | Valori e limiti Si applica quando: Reinserisci il ragionamento effettivamente restituito quando il modello lo utilizza | Predefinito— |
Campomessages[].reasoning_details | Tipoobject|array | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campomax_tokens | Tipointeger | RequisitoFacoltativo | Valori e limiti Minimo: 1 Dipende dal modello | Predefinito— |
Campomax_completion_tokens | Tipointeger | RequisitoFacoltativo | Valori e limiti Minimo: 1 Dipende dal modello | Predefinito— |
Campostream | Tipoboolean | RequisitoFacoltativo | Valori e limiti | Predefinitofalse |
Campostream_options.include_usage | Tipoboolean | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campotemperature | Tiponumber | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campotop_p | Tiponumber | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campostop | Tipostring|string[] | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campotools | Tipofunction_tool[] | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campotools[].type | Tipostring | RequisitoFacoltativo | Valori e limiti function Dipende dal modello | Predefinito— |
Campotools[].function.name | Tipostring | RequisitoObbligatorio | Valori e limiti Si applica quando: Funzione fornita come strumento | Predefinito— |
Campotools[].function.description | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campotools[].function.parameters | TipoJSON_schema | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campotool_choice | Tipostring|object | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campoparallel_tool_calls | Tipoboolean | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Camporesponse_format | Tipoobject | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Camporeasoning_effort | Tipostring | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Camporeasoning | Tipoobject | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Camposervice_tier | Tipostring | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campoinstructions | Tipostring | RequisitoFacoltativo | Valori e limiti Campo di compatibilità | Predefinito— |
Campofunctions | Tipofunction[] | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campofunction_call | Tipostring|object | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campoprompt_cache_options | Tipoobject | RequisitoFacoltativo | Valori e limiti Dipende dal modello | Predefinito— |
Campomodalities | Tipostring[] | RequisitoFacoltativo | Valori e limiti text | Predefinito— |
Campoprovider | Tipoobject | RequisitoFacoltativo | Valori e limiti Condizioni: provider.options viene rifiutato su questa rotta testuale Ultra | Predefinito— |
Campocache_control.ttl | Tipostring | RequisitoFacoltativo | Valori e limiti Condizioni: 1h viene rifiutato nelle posizioni effettive della cache dei prompt | Predefinito— |
Testo · Testo UTF8
messages[].content
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, messages |
Parametromaterial_types | Contrattotext |
Parametromessages | ContrattoArray di messaggi con struttura role/content |
Parametrofile_material | ContrattoDocumento UTF-8 effettivo inserito come testo letterale; nessun ID di file dedotto |
Parametrooptional_controls | Contrattostream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametrocontrol_scope | ContrattoSpecifico del modello; gli strumenti di funzione dell’utente differiscono dagli strumenti ospitati |
Parametrooutput_modalities | Contrattotext |
Parametrohosted_operations | Contrattofalse |
Parametromultimodal_input_binding | Contrattonull |
Ciclo di vita: synchronous_or_streamed
Invia l’ID esatto del modello con messages.
La lunghezza del contesto non è un limite di uscita.
Un file di testo può fornire testo letterale; gli ingressi immagine/audio/oggetto file richiedono un’associazione esatta.
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
| Configurazione | Listino delle tariffe | Costo |
|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Costo Input · Token in input $0.0006 / 1K token Output · Token in output $0.00228 / 1K token Input · Lettura dalla cache $0 / 1K token Input · Scrittura nella cache $0 / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
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 o SSE
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Conserva ogni scelta con contenuto, chiamate agli strumenti e ragionamento. In SSE assembla i delta per indice di scelta e strumento e conserva il motivo finale di completamento e i dati di utilizzo.
Conserva gli ID e le intestazioni di richiesta/risposta. Non viene fornito alcun URL generico per recuperare un’attività testuale.
| Campo | Tipo |
|---|---|
Campochoices[].index | Tipointeger |
Campochoices[].message.content | Tipostring|null |
Campochoices[].message.tool_calls | Tipotool_call[] |
Campochoices[].message.reasoning_content | Tipostring |
Campochoices[].message.reasoning_details | Tipoobject|array |
Campochoices[].finish_reason | Tipostring|null |
Campousage | Tipoobject |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneCampi obbligatori, rappresentazione del materiale o valore del parametro non validi | Passaggio successivoCorreggi i campi indicati prima di una nuova richiesta di creazione. |
Ailoot Ultra moonshotai/Kimi-Dev-72B
Usa i percorsi dei metodi indicati sopra.
moonshotai/Kimi-Dev-72BKimi-Dev-72B è il modello di programmazione di Moonshot AI per risolvere problemi software. Il suo design abbina correzione dei bug e scrittura di test di regressione: individuare i file pertinenti, proporre una patch e produrre un test che dimostri l’errore originale.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
Kimi-Dev-72B è il modello linguistico di programmazione di Moonshot AI per compiti di ingegneria del software, con particolare attenzione alla risoluzione di problemi nei repository esistenti. Accetta testo e produce testo, incluse proposte di codice, spiegazioni e test. Il suo design parte dal modello base Qwen 2.5 72B e sviluppa le capacità necessarie a trasformare una segnalazione di bug in una modifica esaminabile.
BugFixer e TestWriter. Il produttore tratta la correzione di un’implementazione e la scrittura del test che ne riproduce il difetto come capacità complementari. Entrambe usano la stessa struttura in due fasi: identificare il file che richiede attenzione, poi apportare la modifica pertinente al codice. Un test utile per la correzione fallisce quando il bug è presente e passa quando viene applicata la correzione prevista. Questo dà al modello un’attenzione pratica alla relazione tra segnalazione, implementazione ed evidenze eseguibili.
Addestramento intermedio. Il team riporta circa 150 miliardi di token di addestramento aggiuntivo da materiale reale di alta qualità, inclusi milioni di issue e commit di pull request. Questa fase insegna schemi nel modo in cui gli sviluppatori indagano una segnalazione, modificano codice e scrivono test unitari. Il team esclude inoltre i repository SWE-bench Verified da questa raccolta di addestramento per ridurre la contaminazione.
Apprendimento per rinforzo. Dopo il fine-tuning supervisionato, la fase di apprendimento per rinforzo si concentra sulle modifiche di codice. La ricompensa usa l’esito finale dell’esecuzione in un repository containerizzato; il produttore descrive il successo come superamento dell’intera suite di test. Il processo di addestramento filtra i compiti su cui più tentativi campionati falliscono tutti, introduce gradualmente prompt più difficili e riusa esempi recenti riusciti per rafforzare schemi di correzione efficaci.
Prepara un problema reale. Fornisci comportamento atteso, risultato osservato e una riproduzione minima, poi includi file sorgente pertinenti, output degli errori e test esistenti. Mantieni invariati percorsi dei file e nomi delle funzioni. Chiedi al modello di identificare il file probabile e spiegare come l’errore derivi dall’implementazione fornita prima di presentare una patch. L’elaborato risultante deve dichiarare quale codice cambia, perché la modifica affronta la segnalazione e quale comportamento esistente deve preservare.
Prepara il test di regressione. Fornisci le convenzioni di test correnti del progetto e fixture rappresentative. Richiedi un test che attivi l’errore originale, insieme all’asserzione che distingue il comportamento corretto da quello errato. Per una segnalazione su un caso limite, indica la condizione di confine, invece di chiedere copertura aggiuntiva generica. Una risposta utile può contenere sia una modifica minima sia un test mirato, consentendo al revisore di confrontare direttamente la correzione proposta con il problema.
Self-play durante la valutazione. Il flusso di ricerca di Moonshot consente inoltre alle proposte di correzione dei bug e di scrittura dei test di verificarsi a vicenda. È una tecnica di valutazione e orchestrazione attorno al modello: un test candidato può mettere alla prova una patch e una patch può essere verificata rispetto al test. In un’applicazione, la stessa idea può guidare una richiesta di revisione che chieda un controesempio a una correzione proposta prima di accettare la modifica finale.
La risposta testuale è una proposta finché non viene applicata ed esercitata nel repository effettivo. Accesso ai file, modifiche, esecuzione in container e risultati dei test provengono dall’ambiente di sviluppo circostante. Includi gli output di quei controlli in una richiesta successiva, affinché il modello possa ragionare sull’errore osservato, anziché su un’esecuzione immaginata. Preserva i vincoli del progetto e chiedi la modifica minima giustificata quando il problema riguarda una base di codice matura.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti moonshotai/Kimi-Dev-72B | Predefinito— |
Campomessages | Tipomessage[] | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campomessages[].role | Tipostring | RequisitoObbligatorio | Valori e limiti user, assistant | Predefinito— |
Campomessages[].content | Tipostring | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campomax_tokens | Tipointeger | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campostream | Tipoboolean | RequisitoFacoltativo | Valori e limiti | Predefinitofalse |
Testo · Testo UTF-8
Stringa messages[].content
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, messages, max_tokens |
Parametrooptional_controls | Contrattostream |
Parametromaterial_types | Contrattotext |
Parametrotext_file_material | ContrattoLeggi il documento UTF-8 effettivo e inserisci il testo nell’ingresso indicato o nella stringa del contenuto del messaggio. |
Ciclo di vita: synchronous_or_streamed
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
| Configurazione | Listino delle tariffe | Costo |
|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Costo Input · Token in input $0.0006 / 1K token Output · Token in output $0.00228 / 1K token Input · Lettura dalla cache $0 / 1K token Input · Scrittura nella cache $0 / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
{\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 o SSE
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Conserva tutti i blocchi di contenuto, le firme di ragionamento e gli ID effettivi di utilizzo degli strumenti. Assembla tutti i delta dei blocchi SSE; il primo blocco di testo non è l’uscita completa.
Conserva gli ID e le intestazioni di richiesta/risposta. Non viene fornito alcun URL generico per recuperare un’attività testuale.
| Campo | Tipo |
|---|---|
Campoid | Tipostring |
Campomodel | Tipostring |
Campocontent[] | Tipotext|thinking|tool_use|other content block |
Campostop_reason | Tipostring|null |
Campousage | Tipoobject |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneCampi obbligatori, rappresentazione del materiale o valore del parametro non validi | Passaggio successivoCorreggi i campi indicati prima di una nuova richiesta di creazione. |
Ailoot Ultra moonshotai/Kimi-Dev-72B
Usa i percorsi dei metodi indicati sopra.
Esempio tecnico in inglese
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.