Kimi-Dev-72B es el modelo de lenguaje de programación de Moonshot AI para tareas de ingeniería de software, con un enfoque particular en resolver problemas de repositorios existentes. Acepta texto y produce texto, incluidas propuestas de código, explicaciones y pruebas. Su diseño parte del modelo base Qwen 2.5 72B y desarrolla las capacidades necesarias para convertir un reporte de error en un cambio que se pueda revisar.
BugFixer y TestWriter. Su desarrollador trata la corrección de una implementación y la escritura de la prueba que reproduce su defecto como habilidades complementarias. Ambas usan la misma estructura de dos etapas: identificar el archivo que necesita atención y después realizar la edición de código relevante. Una prueba útil de reparación falla cuando el error está presente y pasa cuando se aplica la corrección prevista. Esto da al modelo un enfoque práctico en la relación entre el reporte, la implementación y la evidencia ejecutable.
Entrenamiento intermedio. El equipo reporta aproximadamente 150,000 millones de tokens de entrenamiento adicional con material real de alta calidad, incluidos millones de incidencias y commits de solicitudes de incorporación de cambios. Esta etapa enseña patrones de cómo los desarrolladores investigan un reporte, editan código y escriben pruebas unitarias. El equipo también excluye repositorios de SWE-bench Verified de esta colección de entrenamiento para reducir la contaminación.
Aprendizaje por refuerzo. Después del ajuste fino supervisado, la etapa de aprendizaje por refuerzo se enfoca en cambios de código. Su recompensa usa el resultado final de ejecución en un repositorio dentro de un contenedor; su desarrollador describe el éxito como que pase toda la suite de pruebas. El proceso de entrenamiento filtra tareas en las que todos los intentos de varias muestras fallan, introduce gradualmente prompts más difíciles y reutiliza ejemplos recientes exitosos para reforzar patrones eficaces de reparación.
Prepara un problema real. Proporciona el comportamiento esperado, el resultado observado y una reproducción mínima, y después incluye los archivos fuente relevantes, la salida de error y las pruebas existentes. Conserva sin cambios las rutas de archivos y los nombres de funciones. Pide al modelo identificar el archivo probable y explicar cómo el fallo se deriva de la implementación proporcionada antes de presentar un parche. El artefacto resultante debe indicar qué código cambia, por qué el cambio aborda el reporte y qué comportamiento existente debe conservar.
Prepara la prueba de regresión. Proporciona las convenciones actuales de pruebas del proyecto y fixtures representativos. Solicita una prueba que active el fallo original, junto con la aserción que distingue el comportamiento correcto del incorrecto. Para un reporte de caso límite, indica la condición de frontera en lugar de pedir cobertura adicional genérica. Una respuesta útil puede contener una edición mínima y una prueba enfocada, lo que permite al revisor comparar directamente la reparación propuesta con el problema.
Autojuego en tiempo de prueba. El flujo de investigación de Moonshot también permite que las propuestas de corrección de errores y escritura de pruebas se comprueben entre sí. Es una técnica de evaluación y orquestación alrededor del modelo: una prueba candidata puede cuestionar un parche y un parche se puede comprobar contra la prueba. En una aplicación, la misma idea puede orientar una solicitud de revisión que pida un contraejemplo a una corrección propuesta antes de aceptar la edición final.
La respuesta de texto es una propuesta hasta que se aplica y se ejecuta en el repositorio real. El acceso a archivos, las ediciones, la ejecución en contenedores y los resultados de pruebas provienen del entorno de desarrollo que lo integra. Incluye las salidas de esas comprobaciones en una solicitud posterior para que el modelo razone sobre el fallo observado y no sobre una ejecución imaginaria. Conserva las restricciones del proyecto y solicita el cambio mínimo justificado cuando el problema afecte una base de código madura.
", "aboutText": "Kimi-Dev-72B es el modelo de lenguaje de programación de Moonshot AI para tareas de ingeniería de software, con un enfoque particular en resolver problemas de repositorios existentes. Acepta texto y produce texto, incluidas propuestas de código, explicaciones y pruebas. Su diseño parte del modelo base Qwen 2.5 72B y desarrolla las capacidades necesarias para convertir un reporte de error en un cambio que se pueda revisar.\n\nBugFixer y TestWriter. Su desarrollador trata la corrección de una implementación y la escritura de la prueba que reproduce su defecto como habilidades complementarias. Ambas usan la misma estructura de dos etapas: identificar el archivo que necesita atención y después realizar la edición de código relevante. Una prueba útil de reparación falla cuando el error está presente y pasa cuando se aplica la corrección prevista. Esto da al modelo un enfoque práctico en la relación entre el reporte, la implementación y la evidencia ejecutable.\n\nEntrenamiento intermedio. El equipo reporta aproximadamente 150,000 millones de tokens de entrenamiento adicional con material real de alta calidad, incluidos millones de incidencias y commits de solicitudes de incorporación de cambios. Esta etapa enseña patrones de cómo los desarrolladores investigan un reporte, editan código y escriben pruebas unitarias. El equipo también excluye repositorios de SWE-bench Verified de esta colección de entrenamiento para reducir la contaminación.\n\nAprendizaje por refuerzo. Después del ajuste fino supervisado, la etapa de aprendizaje por refuerzo se enfoca en cambios de código. Su recompensa usa el resultado final de ejecución en un repositorio dentro de un contenedor; su desarrollador describe el éxito como que pase toda la suite de pruebas. El proceso de entrenamiento filtra tareas en las que todos los intentos de varias muestras fallan, introduce gradualmente prompts más difíciles y reutiliza ejemplos recientes exitosos para reforzar patrones eficaces de reparación.\n\nPrepara un problema real. Proporciona el comportamiento esperado, el resultado observado y una reproducción mínima, y después incluye los archivos fuente relevantes, la salida de error y las pruebas existentes. Conserva sin cambios las rutas de archivos y los nombres de funciones. Pide al modelo identificar el archivo probable y explicar cómo el fallo se deriva de la implementación proporcionada antes de presentar un parche. El artefacto resultante debe indicar qué código cambia, por qué el cambio aborda el reporte y qué comportamiento existente debe conservar.\n\nPrepara la prueba de regresión. Proporciona las convenciones actuales de pruebas del proyecto y fixtures representativos. Solicita una prueba que active el fallo original, junto con la aserción que distingue el comportamiento correcto del incorrecto. Para un reporte de caso límite, indica la condición de frontera en lugar de pedir cobertura adicional genérica. Una respuesta útil puede contener una edición mínima y una prueba enfocada, lo que permite al revisor comparar directamente la reparación propuesta con el problema.\n\nAutojuego en tiempo de prueba. El flujo de investigación de Moonshot también permite que las propuestas de corrección de errores y escritura de pruebas se comprueben entre sí. Es una técnica de evaluación y orquestación alrededor del modelo: una prueba candidata puede cuestionar un parche y un parche se puede comprobar contra la prueba. En una aplicación, la misma idea puede orientar una solicitud de revisión que pida un contraejemplo a una corrección propuesta antes de aceptar la edición final.\n\nLa respuesta de texto es una propuesta hasta que se aplica y se ejecuta en el repositorio real. El acceso a archivos, las ediciones, la ejecución en contenedores y los resultados de pruebas provienen del entorno de desarrollo que lo integra. Incluye las salidas de esas comprobaciones en una solicitud posterior para que el modelo razone sobre el fallo observado y no sobre una ejecución imaginaria. Conserva las restricciones del proyecto y solicita el cambio mínimo justificado cuando el problema afecte una base de código madura.", "editorialOverlay": { "copy_fields": { "practical_html": "Ejemplo técnico en inglés
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 es el modelo de programación de Moonshot AI para resolver problemas de software. Su diseño combina corrección de errores con escritura de pruebas de regresión: localizar los archivos relevantes, proponer un parche y producir una prueba que demuestre el fallo original.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Kimi-Dev-72B es el modelo de lenguaje de programación de Moonshot AI para tareas de ingeniería de software, con un enfoque particular en resolver problemas de repositorios existentes. Acepta texto y produce texto, incluidas propuestas de código, explicaciones y pruebas. Su diseño parte del modelo base Qwen 2.5 72B y desarrolla las capacidades necesarias para convertir un reporte de error en un cambio que se pueda revisar.
BugFixer y TestWriter. Su desarrollador trata la corrección de una implementación y la escritura de la prueba que reproduce su defecto como habilidades complementarias. Ambas usan la misma estructura de dos etapas: identificar el archivo que necesita atención y después realizar la edición de código relevante. Una prueba útil de reparación falla cuando el error está presente y pasa cuando se aplica la corrección prevista. Esto da al modelo un enfoque práctico en la relación entre el reporte, la implementación y la evidencia ejecutable.
Entrenamiento intermedio. El equipo reporta aproximadamente 150,000 millones de tokens de entrenamiento adicional con material real de alta calidad, incluidos millones de incidencias y commits de solicitudes de incorporación de cambios. Esta etapa enseña patrones de cómo los desarrolladores investigan un reporte, editan código y escriben pruebas unitarias. El equipo también excluye repositorios de SWE-bench Verified de esta colección de entrenamiento para reducir la contaminación.
Aprendizaje por refuerzo. Después del ajuste fino supervisado, la etapa de aprendizaje por refuerzo se enfoca en cambios de código. Su recompensa usa el resultado final de ejecución en un repositorio dentro de un contenedor; su desarrollador describe el éxito como que pase toda la suite de pruebas. El proceso de entrenamiento filtra tareas en las que todos los intentos de varias muestras fallan, introduce gradualmente prompts más difíciles y reutiliza ejemplos recientes exitosos para reforzar patrones eficaces de reparación.
Prepara un problema real. Proporciona el comportamiento esperado, el resultado observado y una reproducción mínima, y después incluye los archivos fuente relevantes, la salida de error y las pruebas existentes. Conserva sin cambios las rutas de archivos y los nombres de funciones. Pide al modelo identificar el archivo probable y explicar cómo el fallo se deriva de la implementación proporcionada antes de presentar un parche. El artefacto resultante debe indicar qué código cambia, por qué el cambio aborda el reporte y qué comportamiento existente debe conservar.
Prepara la prueba de regresión. Proporciona las convenciones actuales de pruebas del proyecto y fixtures representativos. Solicita una prueba que active el fallo original, junto con la aserción que distingue el comportamiento correcto del incorrecto. Para un reporte de caso límite, indica la condición de frontera en lugar de pedir cobertura adicional genérica. Una respuesta útil puede contener una edición mínima y una prueba enfocada, lo que permite al revisor comparar directamente la reparación propuesta con el problema.
Autojuego en tiempo de prueba. El flujo de investigación de Moonshot también permite que las propuestas de corrección de errores y escritura de pruebas se comprueben entre sí. Es una técnica de evaluación y orquestación alrededor del modelo: una prueba candidata puede cuestionar un parche y un parche se puede comprobar contra la prueba. En una aplicación, la misma idea puede orientar una solicitud de revisión que pida un contraejemplo a una corrección propuesta antes de aceptar la edición final.
La respuesta de texto es una propuesta hasta que se aplica y se ejecuta en el repositorio real. El acceso a archivos, las ediciones, la ejecución en contenedores y los resultados de pruebas provienen del entorno de desarrollo que lo integra. Incluye las salidas de esas comprobaciones en una solicitud posterior para que el modelo razone sobre el fallo observado y no sobre una ejecución imaginaria. Conserva las restricciones del proyecto y solicita el cambio mínimo justificado cuando el problema afecte una base de código madura.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites moonshotai/Kimi-Dev-72B | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites Ejemplos: system, user, assistant, tool, function Condiciones: Estos roles están representados explícitamente por los tipos de compatibilidad del código fuente; el conjunto exacto de roles depende del modelo. Depende del modelo | Predeterminado— |
Campomessages[].content | Tipostring|content_part[]|null | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_calls | Tipotool_call[] | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_call_id | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: role=tool; utiliza el ID real devuelto | Predeterminado— |
Campomessages[].name | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].reasoning_content | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: Devuelve en los turnos siguientes el razonamiento realmente recibido cuando este modelo lo utilice | Predeterminado— |
Campomessages[].reasoning_details | Tipoobject|array | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campomax_completion_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Campostream_options.include_usage | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotemperature | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotop_p | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campostop | Tipostring|string[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools | Tipofunction_tool[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools[].type | Tipostring | RequisitoOpcional | Valores y límites function Depende del modelo | Predeterminado— |
Campotools[].function.name | Tipostring | RequisitoObligatorio | Valores y límites Se aplica cuando: herramienta de función proporcionada | Predeterminado— |
Campotools[].function.description | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotools[].function.parameters | TipoJSON_schema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotool_choice | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoparallel_tool_calls | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporesponse_format | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning_effort | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camposervice_tier | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoinstructions | Tipostring | RequisitoOpcional | Valores y límites Campo de compatibilidad | Predeterminado— |
Campofunctions | Tipofunction[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campofunction_call | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoprompt_cache_options | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomodalities | Tipostring[] | RequisitoOpcional | Valores y límites text | Predeterminado— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores y límites Condiciones: provider.options se rechaza en esta ruta de texto Ultra | Predeterminado— |
Campocache_control.ttl | Tipostring | RequisitoOpcional | Valores y límites Condiciones: 1h se rechaza en los campos reales de caché de instrucciones | Predeterminado— |
Texto · Texto UTF8
messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages |
Parámetromaterial_types | Contratotext |
Parámetromessages | Contratomatriz de mensajes con estructura role/content |
Parámetrofile_material | Contratodocumento real en UTF-8 insertado como texto literal; no se deduce ningún ID de archivo |
Parámetrooptional_controls | Contratostream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parámetrocontrol_scope | Contratodepende del modelo; las herramientas de funciones del usuario difieren de las herramientas alojadas |
Parámetrooutput_modalities | Contratotext |
Parámetrohosted_operations | Contratofalse |
Parámetromultimodal_input_binding | Contratonull |
Ciclo de vida: synchronous_or_streamed
Envía el ID exacto del modelo junto con messages.
La longitud del contexto no es un límite máximo de salida.
Un archivo de texto puede aportar texto literal; las entradas de imagen, audio u objetos de archivo requieren una vinculación exacta.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0006 / 1K tokens Salida · Tokens de salida $0.00228 / 1K tokens Entrada · Lectura de caché $0 / 1K tokens Entrada · Escritura en caché $0 / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
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 todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva cada alternativa y su contenido, llamadas de herramientas y razonamiento. En SSE, ensambla los fragmentos incrementales por índice de alternativa/herramienta y conserva el motivo final de terminación y el uso.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| 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 |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra moonshotai/Kimi-Dev-72B
Usa las rutas de método indicadas arriba.
moonshotai/Kimi-Dev-72BKimi-Dev-72B es el modelo de programación de Moonshot AI para resolver problemas de software. Su diseño combina corrección de errores con escritura de pruebas de regresión: localizar los archivos relevantes, proponer un parche y producir una prueba que demuestre el fallo original.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Kimi-Dev-72B es el modelo de lenguaje de programación de Moonshot AI para tareas de ingeniería de software, con un enfoque particular en resolver problemas de repositorios existentes. Acepta texto y produce texto, incluidas propuestas de código, explicaciones y pruebas. Su diseño parte del modelo base Qwen 2.5 72B y desarrolla las capacidades necesarias para convertir un reporte de error en un cambio que se pueda revisar.
BugFixer y TestWriter. Su desarrollador trata la corrección de una implementación y la escritura de la prueba que reproduce su defecto como habilidades complementarias. Ambas usan la misma estructura de dos etapas: identificar el archivo que necesita atención y después realizar la edición de código relevante. Una prueba útil de reparación falla cuando el error está presente y pasa cuando se aplica la corrección prevista. Esto da al modelo un enfoque práctico en la relación entre el reporte, la implementación y la evidencia ejecutable.
Entrenamiento intermedio. El equipo reporta aproximadamente 150,000 millones de tokens de entrenamiento adicional con material real de alta calidad, incluidos millones de incidencias y commits de solicitudes de incorporación de cambios. Esta etapa enseña patrones de cómo los desarrolladores investigan un reporte, editan código y escriben pruebas unitarias. El equipo también excluye repositorios de SWE-bench Verified de esta colección de entrenamiento para reducir la contaminación.
Aprendizaje por refuerzo. Después del ajuste fino supervisado, la etapa de aprendizaje por refuerzo se enfoca en cambios de código. Su recompensa usa el resultado final de ejecución en un repositorio dentro de un contenedor; su desarrollador describe el éxito como que pase toda la suite de pruebas. El proceso de entrenamiento filtra tareas en las que todos los intentos de varias muestras fallan, introduce gradualmente prompts más difíciles y reutiliza ejemplos recientes exitosos para reforzar patrones eficaces de reparación.
Prepara un problema real. Proporciona el comportamiento esperado, el resultado observado y una reproducción mínima, y después incluye los archivos fuente relevantes, la salida de error y las pruebas existentes. Conserva sin cambios las rutas de archivos y los nombres de funciones. Pide al modelo identificar el archivo probable y explicar cómo el fallo se deriva de la implementación proporcionada antes de presentar un parche. El artefacto resultante debe indicar qué código cambia, por qué el cambio aborda el reporte y qué comportamiento existente debe conservar.
Prepara la prueba de regresión. Proporciona las convenciones actuales de pruebas del proyecto y fixtures representativos. Solicita una prueba que active el fallo original, junto con la aserción que distingue el comportamiento correcto del incorrecto. Para un reporte de caso límite, indica la condición de frontera en lugar de pedir cobertura adicional genérica. Una respuesta útil puede contener una edición mínima y una prueba enfocada, lo que permite al revisor comparar directamente la reparación propuesta con el problema.
Autojuego en tiempo de prueba. El flujo de investigación de Moonshot también permite que las propuestas de corrección de errores y escritura de pruebas se comprueben entre sí. Es una técnica de evaluación y orquestación alrededor del modelo: una prueba candidata puede cuestionar un parche y un parche se puede comprobar contra la prueba. En una aplicación, la misma idea puede orientar una solicitud de revisión que pida un contraejemplo a una corrección propuesta antes de aceptar la edición final.
La respuesta de texto es una propuesta hasta que se aplica y se ejecuta en el repositorio real. El acceso a archivos, las ediciones, la ejecución en contenedores y los resultados de pruebas provienen del entorno de desarrollo que lo integra. Incluye las salidas de esas comprobaciones en una solicitud posterior para que el modelo razone sobre el fallo observado y no sobre una ejecución imaginaria. Conserva las restricciones del proyecto y solicita el cambio mínimo justificado cuando el problema afecte una base de código madura.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites moonshotai/Kimi-Dev-72B | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites user, assistant | Predeterminado— |
Campomessages[].content | Tipostring | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Texto · Texto UTF-8
cadena messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages, max_tokens |
Parámetrooptional_controls | Contratostream |
Parámetromaterial_types | Contratotext |
Parámetrotext_file_material | ContratoLee el documento real en UTF-8 y coloca su texto en el campo input indicado o en la cadena de contenido del mensaje. |
Ciclo de vida: synchronous_or_streamed
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0006 / 1K tokens Salida · Tokens de salida $0.00228 / 1K tokens Entrada · Lectura de caché $0 / 1K tokens Entrada · Escritura en caché $0 / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
{\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 todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva todos los bloques de contenido, las firmas de razonamiento y los ID reales de uso de herramientas. Ensambla todos los fragmentos incrementales de los bloques SSE; el primer bloque de texto no constituye la salida completa.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| Campo | Tipo |
|---|---|
Campoid | Tipostring |
Campomodel | Tipostring |
Campocontent[] | Tipotext|thinking|tool_use|other content block |
Campostop_reason | Tipostring|null |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra moonshotai/Kimi-Dev-72B
Usa las rutas de método indicadas arriba.
Ejemplo técnico en inglés
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.