KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de ingeniería de software en un entorno con herramientas. La versión original del fabricante se centra en seguir una petición de desarrollo mediante inspección del repositorio, creación de parches y revisión. Su entrenamiento cubre implementación y mejora de funciones, corrección de errores, refactorización, trabajo de rendimiento, creación de pruebas, comprensión de código y tareas de configuración. Los resultados útiles son código y texto vinculados al comportamiento real del proyecto.
Indica el comportamiento que debe lograrse, la implementación actual y las condiciones que definen la finalización. Incluye los archivos o pasajes de código necesarios para comprender el problema y las órdenes u observaciones ya disponibles del entorno. Un encargo original de corrección de errores puede identificar la entrada que falla, el resultado esperado y la función cuyo comportamiento difiere. Una petición de funcionalidad puede indicar el resultado visible para el usuario y las interfaces que deben seguir siendo coherentes.
El entrenamiento de agentes del productor utiliza descripciones de incidencias, código de ramas, entornos ejecutables y condiciones verificables de tarea. Mantén alineadas esas partes en una tarea asistida por una aplicación. La propuesta del modelo debe abordar la copia de trabajo y las pruebas reales suministradas, mientras que la aplicación realiza las operaciones sobre archivos o de ejecución y devuelve los resultados. Conserva el resultado de cada operación con consecuencias junto a la continuación.
El fabricante documenta el seguimiento de instrucciones, el uso de herramientas y la interacción prolongada como partes centrales del desarrollo de la familia. La configuración publicada del agente de programación proporciona operaciones de lectura y edición de archivos y una acción de finalización. El modelo puede inspeccionar información, solicitar un cambio y continuar a partir de la observación devuelta. Su función es elegir y describir el siguiente paso; el entorno que lo rodea establece lo que ocurrió realmente.
La versión original también describe las solicitudes paralelas de herramientas como una capacidad observada tras el entrenamiento de agentes. Utiliza operaciones independientes únicamente cuando sus resultados puedan mantenerse asociados a la petición correcta. Una explicación de repositorio puede combinar información de varios archivos, mientras que un parche necesita el contenido y el comportamiento actuales del código afectado. No sustituyas una observación ausente por un resultado plausible del entorno.
La configuración de agente publicada por el productor separa generación de parches, filtrado, selección y reflexión. El filtrado combina deduplicación semántica con comprobaciones basadas en ejecución; la selección evalúa los candidatos restantes; la reflexión utiliza los resultados anteriores para orientar una ronda posterior. Esas etapas pertenecen al flujo de programación documentado, no son una garantía automática asociada a cualquier respuesta de texto simple.
Para una tarea práctica de código, conserva juntos el parche propuesto, las comprobaciones realmente ejecutadas y sus resultados. Una comparación de posibles correcciones debe explicar la condición que las distingue, especialmente cuando todas parecen plausibles solo a partir de las diferencias de código. Una comprobación fallida puede dar al siguiente turno un problema específico que resolver, en vez de provocar una reescritura sin relación.
La versión original del fabricante distingue KAT-Coder del modelo abierto independiente KAT-Dev-32B. Las explicaciones de entrenamiento y las demostraciones de flujos no hacen de cada perfil con nombre de la familia un checkpoint idéntico. Conserva el perfil seleccionado y las instrucciones suministradas del proyecto junto al resultado, y utiliza la interfaz concreta del productor o la configuración del entorno para sus operaciones.
Una entrega útil puede contener una implementación concreta, una explicación del defecto o una refactorización con las pruebas que respaldan su comportamiento. Revisa la lógica cambiada y las salidas reales del entorno antes de tratar una tarea como terminada. La finalidad de ingeniería de software de KAT-Coder resulta más útil cuando sigue vinculada a una petición concreta de desarrollo, el código pertinente y un resultado final que pueda revisarse.
", "aboutText": "KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de ingeniería de software en un entorno con herramientas. La versión original del fabricante se centra en seguir una petición de desarrollo mediante inspección del repositorio, creación de parches y revisión. Su entrenamiento cubre implementación y mejora de funciones, corrección de errores, refactorización, trabajo de rendimiento, creación de pruebas, comprensión de código y tareas de configuración. Los resultados útiles son código y texto vinculados al comportamiento real del proyecto.\n\n### Proporciona el problema y el contexto pertinente del proyecto\n\nIndica el comportamiento que debe lograrse, la implementación actual y las condiciones que definen la finalización. Incluye los archivos o pasajes de código necesarios para comprender el problema y las órdenes u observaciones ya disponibles del entorno. Un encargo original de corrección de errores puede identificar la entrada que falla, el resultado esperado y la función cuyo comportamiento difiere. Una petición de funcionalidad puede indicar el resultado visible para el usuario y las interfaces que deben seguir siendo coherentes.\n\nEl entrenamiento de agentes del productor utiliza descripciones de incidencias, código de ramas, entornos ejecutables y condiciones verificables de tarea. Mantén alineadas esas partes en una tarea asistida por una aplicación. La propuesta del modelo debe abordar la copia de trabajo y las pruebas reales suministradas, mientras que la aplicación realiza las operaciones sobre archivos o de ejecución y devuelve los resultados. Conserva el resultado de cada operación con consecuencias junto a la continuación.\n\n### Herramientas y desarrollo en varios turnos\n\nEl fabricante documenta el seguimiento de instrucciones, el uso de herramientas y la interacción prolongada como partes centrales del desarrollo de la familia. La configuración publicada del agente de programación proporciona operaciones de lectura y edición de archivos y una acción de finalización. El modelo puede inspeccionar información, solicitar un cambio y continuar a partir de la observación devuelta. Su función es elegir y describir el siguiente paso; el entorno que lo rodea establece lo que ocurrió realmente.\n\nLa versión original también describe las solicitudes paralelas de herramientas como una capacidad observada tras el entrenamiento de agentes. Utiliza operaciones independientes únicamente cuando sus resultados puedan mantenerse asociados a la petición correcta. Una explicación de repositorio puede combinar información de varios archivos, mientras que un parche necesita el contenido y el comportamiento actuales del código afectado. No sustituyas una observación ausente por un resultado plausible del entorno.\n\n### Revisa los cambios candidatos de forma deliberada\n\nLa configuración de agente publicada por el productor separa generación de parches, filtrado, selección y reflexión. El filtrado combina deduplicación semántica con comprobaciones basadas en ejecución; la selección evalúa los candidatos restantes; la reflexión utiliza los resultados anteriores para orientar una ronda posterior. Esas etapas pertenecen al flujo de programación documentado, no son una garantía automática asociada a cualquier respuesta de texto simple.\n\nPara una tarea práctica de código, conserva juntos el parche propuesto, las comprobaciones realmente ejecutadas y sus resultados. Una comparación de posibles correcciones debe explicar la condición que las distingue, especialmente cuando todas parecen plausibles solo a partir de las diferencias de código. Una comprobación fallida puede dar al siguiente turno un problema específico que resolver, en vez de provocar una reescritura sin relación.\n\n### Diferencias de familia y edición\n\nLa versión original del fabricante distingue KAT-Coder del modelo abierto independiente KAT-Dev-32B. Las explicaciones de entrenamiento y las demostraciones de flujos no hacen de cada perfil con nombre de la familia un checkpoint idéntico. Conserva el perfil seleccionado y las instrucciones suministradas del proyecto junto al resultado, y utiliza la interfaz concreta del productor o la configuración del entorno para sus operaciones.\n\nUna entrega útil puede contener una implementación concreta, una explicación del defecto o una refactorización con las pruebas que respaldan su comportamiento. Revisa la lógica cambiada y las salidas reales del entorno antes de tratar una tarea como terminada. La finalidad de ingeniería de software de KAT-Coder resulta más útil cuando sigue vinculada a una petición concreta de desarrollo, el código pertinente y un resultado final que pueda revisarse.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "98f9c5cb949a9c2385c5da6bf78ec0c861b1d7494e4b0b4522c41fb381440bea", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es", "methods": [ { "html": "KAT-Coder-Pro-V1KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de desarrollo que tienen en cuenta el contexto del repositorio. El flujo de su fabricante combina inspección asistida por herramientas, generación de parches, revisión basada en ejecución y reflexión, produciendo código o explicaciones vinculados al comportamiento real del proyecto.
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.
KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de ingeniería de software en un entorno con herramientas. La versión original del fabricante se centra en seguir una petición de desarrollo mediante inspección del repositorio, creación de parches y revisión. Su entrenamiento cubre implementación y mejora de funciones, corrección de errores, refactorización, trabajo de rendimiento, creación de pruebas, comprensión de código y tareas de configuración. Los resultados útiles son código y texto vinculados al comportamiento real del proyecto.
Indica el comportamiento que debe lograrse, la implementación actual y las condiciones que definen la finalización. Incluye los archivos o pasajes de código necesarios para comprender el problema y las órdenes u observaciones ya disponibles del entorno. Un encargo original de corrección de errores puede identificar la entrada que falla, el resultado esperado y la función cuyo comportamiento difiere. Una petición de funcionalidad puede indicar el resultado visible para el usuario y las interfaces que deben seguir siendo coherentes.
El entrenamiento de agentes del productor utiliza descripciones de incidencias, código de ramas, entornos ejecutables y condiciones verificables de tarea. Mantén alineadas esas partes en una tarea asistida por una aplicación. La propuesta del modelo debe abordar la copia de trabajo y las pruebas reales suministradas, mientras que la aplicación realiza las operaciones sobre archivos o de ejecución y devuelve los resultados. Conserva el resultado de cada operación con consecuencias junto a la continuación.
El fabricante documenta el seguimiento de instrucciones, el uso de herramientas y la interacción prolongada como partes centrales del desarrollo de la familia. La configuración publicada del agente de programación proporciona operaciones de lectura y edición de archivos y una acción de finalización. El modelo puede inspeccionar información, solicitar un cambio y continuar a partir de la observación devuelta. Su función es elegir y describir el siguiente paso; el entorno que lo rodea establece lo que ocurrió realmente.
La versión original también describe las solicitudes paralelas de herramientas como una capacidad observada tras el entrenamiento de agentes. Utiliza operaciones independientes únicamente cuando sus resultados puedan mantenerse asociados a la petición correcta. Una explicación de repositorio puede combinar información de varios archivos, mientras que un parche necesita el contenido y el comportamiento actuales del código afectado. No sustituyas una observación ausente por un resultado plausible del entorno.
La configuración de agente publicada por el productor separa generación de parches, filtrado, selección y reflexión. El filtrado combina deduplicación semántica con comprobaciones basadas en ejecución; la selección evalúa los candidatos restantes; la reflexión utiliza los resultados anteriores para orientar una ronda posterior. Esas etapas pertenecen al flujo de programación documentado, no son una garantía automática asociada a cualquier respuesta de texto simple.
Para una tarea práctica de código, conserva juntos el parche propuesto, las comprobaciones realmente ejecutadas y sus resultados. Una comparación de posibles correcciones debe explicar la condición que las distingue, especialmente cuando todas parecen plausibles solo a partir de las diferencias de código. Una comprobación fallida puede dar al siguiente turno un problema específico que resolver, en vez de provocar una reescritura sin relación.
La versión original del fabricante distingue KAT-Coder del modelo abierto independiente KAT-Dev-32B. Las explicaciones de entrenamiento y las demostraciones de flujos no hacen de cada perfil con nombre de la familia un checkpoint idéntico. Conserva el perfil seleccionado y las instrucciones suministradas del proyecto junto al resultado, y utiliza la interfaz concreta del productor o la configuración del entorno para sus operaciones.
Una entrega útil puede contener una implementación concreta, una explicación del defecto o una refactorización con las pruebas que respaldan su comportamiento. Revisa la lógica cambiada y las salidas reales del entorno antes de tratar una tarea como terminada. La finalidad de ingeniería de software de KAT-Coder resulta más útil cuando sigue vinculada a una petición concreta de desarrollo, el código pertinente y un resultado final que pueda revisarse.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites KAT-Coder-Pro-V1 | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites Depende del modelo | Predeterminado— |
Campomessages[].content | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: Conversación textual | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
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 |
Parámetrocontrol_scope | ContratoConversación textual; stream es un booleano y su valor predeterminado es false. |
Parámetrooutput_modalities | Contratotext |
Parámetrohosted_operations | Contratofalse |
Parámetromultimodal_input_binding | Contratonull |
Alias de método: /chat/completions
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.00114 / 1K tokens Salida · Tokens de salida $0.00456 / 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 importe 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":"KAT-Coder-Pro-V1","messages":[{"role":"user","content":"hello"}],"stream":false}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model="KAT-Coder-Pro-V1", messages=[{"role":"user","content":"hello"}], stream=False)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\njson 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 las cabeceras. 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 KAT-Coder-Pro-V1
/chat/completions
KAT-Coder-Pro-V1KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de desarrollo que tienen en cuenta el contexto del repositorio. El flujo de su fabricante combina inspección asistida por herramientas, generación de parches, revisión basada en ejecución y reflexión, produciendo código o explicaciones vinculados al comportamiento real del proyecto.
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.
KAT-Coder es la familia de modelos de programación de Kuaishou para tareas de ingeniería de software en un entorno con herramientas. La versión original del fabricante se centra en seguir una petición de desarrollo mediante inspección del repositorio, creación de parches y revisión. Su entrenamiento cubre implementación y mejora de funciones, corrección de errores, refactorización, trabajo de rendimiento, creación de pruebas, comprensión de código y tareas de configuración. Los resultados útiles son código y texto vinculados al comportamiento real del proyecto.
Indica el comportamiento que debe lograrse, la implementación actual y las condiciones que definen la finalización. Incluye los archivos o pasajes de código necesarios para comprender el problema y las órdenes u observaciones ya disponibles del entorno. Un encargo original de corrección de errores puede identificar la entrada que falla, el resultado esperado y la función cuyo comportamiento difiere. Una petición de funcionalidad puede indicar el resultado visible para el usuario y las interfaces que deben seguir siendo coherentes.
El entrenamiento de agentes del productor utiliza descripciones de incidencias, código de ramas, entornos ejecutables y condiciones verificables de tarea. Mantén alineadas esas partes en una tarea asistida por una aplicación. La propuesta del modelo debe abordar la copia de trabajo y las pruebas reales suministradas, mientras que la aplicación realiza las operaciones sobre archivos o de ejecución y devuelve los resultados. Conserva el resultado de cada operación con consecuencias junto a la continuación.
El fabricante documenta el seguimiento de instrucciones, el uso de herramientas y la interacción prolongada como partes centrales del desarrollo de la familia. La configuración publicada del agente de programación proporciona operaciones de lectura y edición de archivos y una acción de finalización. El modelo puede inspeccionar información, solicitar un cambio y continuar a partir de la observación devuelta. Su función es elegir y describir el siguiente paso; el entorno que lo rodea establece lo que ocurrió realmente.
La versión original también describe las solicitudes paralelas de herramientas como una capacidad observada tras el entrenamiento de agentes. Utiliza operaciones independientes únicamente cuando sus resultados puedan mantenerse asociados a la petición correcta. Una explicación de repositorio puede combinar información de varios archivos, mientras que un parche necesita el contenido y el comportamiento actuales del código afectado. No sustituyas una observación ausente por un resultado plausible del entorno.
La configuración de agente publicada por el productor separa generación de parches, filtrado, selección y reflexión. El filtrado combina deduplicación semántica con comprobaciones basadas en ejecución; la selección evalúa los candidatos restantes; la reflexión utiliza los resultados anteriores para orientar una ronda posterior. Esas etapas pertenecen al flujo de programación documentado, no son una garantía automática asociada a cualquier respuesta de texto simple.
Para una tarea práctica de código, conserva juntos el parche propuesto, las comprobaciones realmente ejecutadas y sus resultados. Una comparación de posibles correcciones debe explicar la condición que las distingue, especialmente cuando todas parecen plausibles solo a partir de las diferencias de código. Una comprobación fallida puede dar al siguiente turno un problema específico que resolver, en vez de provocar una reescritura sin relación.
La versión original del fabricante distingue KAT-Coder del modelo abierto independiente KAT-Dev-32B. Las explicaciones de entrenamiento y las demostraciones de flujos no hacen de cada perfil con nombre de la familia un checkpoint idéntico. Conserva el perfil seleccionado y las instrucciones suministradas del proyecto junto al resultado, y utiliza la interfaz concreta del productor o la configuración del entorno para sus operaciones.
Una entrega útil puede contener una implementación concreta, una explicación del defecto o una refactorización con las pruebas que respaldan su comportamiento. Revisa la lógica cambiada y las salidas reales del entorno antes de tratar una tarea como terminada. La finalidad de ingeniería de software de KAT-Coder resulta más útil cuando sigue vinculada a una petición concreta de desarrollo, el código pertinente y un resultado final que pueda revisarse.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites KAT-Coder-Pro-V1 | 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.00114 / 1K tokens Salida · Tokens de salida $0.00456 / 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 importe 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": "KAT-Coder-Pro-V1",\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': 'KAT-Coder-Pro-V1', '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': 'KAT-Coder-Pro-V1', '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 las cabeceras. 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 KAT-Coder-Pro-V1
/chat/completions