Cloudflare Clef es el modelo denso más grande de la familia de decisión Clef, obtenido mediante posentrenamiento de Qwen3.8-27B con su codificador visual. Cloudflare combina esa arquitectura base con un cabezal de esquema conjunto que dirige la evidencia a las preguntas y puntúa sus opciones permitidas de forma conjunta. Clef lee una situación y devuelve decisiones acotadas con probabilidades en una sola pasada de inferencia. Su salida es un resultado de clasificación, en lugar de prosa generada, un informe abierto o una propuesta de comando.
Prepara el estado y el esquema de preguntas como entradas distintas. El estado puede ser una cadena de texto o JSON que represente un registro, una conversación, el contenido de un documento o una situación de una aplicación. Las preguntas se identifican mediante nombres estables, y esos mismos nombres identifican las respuestas devueltas. Define qué debe establecer cada pregunta y describe las opciones pertinentes. Un registro de soporte puede preguntar qué equipo debe atender la solicitud, si el impacto es urgente y qué criterio de gravedad corresponde, sin combinar esas decisiones diferentes en una categoría vaga.
Una pregunta noul devuelve la probabilidad de verdadero para una condición binaria. Una pregunta choice devuelve una opción con nombre seleccionada, probabilidades por opción y confianza. Una pregunta score usa una lista ordenada de descripciones, con índices desde cero, y devuelve una puntuación esperada, una leyenda y las probabilidades. Una puntuación fraccionaria tiene significado porque resume la incertidumbre entre niveles ordenados. Examina la distribución además de la respuesta seleccionada; dos opciones próximas pueden revelar una distinción que la entrada no resuelve.
Para comprobar políticas, incluye el texto real de la regla y los hechos del registro. Un ejemplo es un flujo de procesamiento de documentos con preguntas sobre si el registro está completo, qué categoría de revisión corresponde y con qué fuerza la evidencia respalda una atención inmediata. Haz preguntas separadas para condiciones separadas. Una evaluación del modelo sobre el cumplimiento debe permanecer vinculada a la regla y la evidencia proporcionadas. Si falta una condición importante, el esquema y la aplicación deben tener una forma deliberada de manejar esa incertidumbre.
Para evidencia visual, proporciona una imagen legible y una pregunta sobre una condición visible o una categoría definida. Una comprobación de calidad de un formulario podría evaluar la legibilidad, si está presente un área obligatoria y cuál de los niveles de calidad proporcionados lo describe mejor. La interfaz de pesos abiertos del fabricante también acepta arreglos de fotogramas de video. Mantén los fotogramas en orden e identifica el evento que se debe evaluar. Un esquema de decisión acotado puede clasificar ese material, mientras que una solicitud de descripción narrativa o de campos nuevos arbitrarios corresponde a otro tipo de salida.
La referencia de la interfaz alojada del fabricante indica un contexto de 65,536 tokens, de una a 64 preguntas y hasta cuatro imágenes incrustadas. Sus imágenes PNG, JPEG o WebP están limitadas a 4 MiB y 16 megapíxeles cada una, con un total decodificado de 8 MiB; el cuerpo completo de la solicitud está limitado a 13 MiB y no se aceptan enlaces remotos a imágenes. El presupuesto de entrada incluye las preguntas y los medios. El texto largo puede truncarse para ajustarse, por lo que conviene conservar los pasajes decisivos y las etiquetas de origen. Estos límites describen la interfaz de imágenes alojada del productor; el codificador de pesos abiertos tiene sus propias representaciones de entradas locales.
La publicación de Cloudflare describe un entrenamiento para puntuación sujeta a esquemas y calibración de probabilidades. El modelo extrae evidencia pertinente para opciones individuales y luego considera la información entre campos. Esto puede apoyar decisiones sobre varias preguntas relacionadas en un mismo registro, pero no convierte una probabilidad alta en una garantía de que el hecho subyacente sea verdadero. Evalúa registros difíciles, incompletos y fuera de las categorías, además de casos sencillos. Los criterios de decisión útiles cubren las situaciones que el flujo de trabajo realmente encuentra y hacen explícitas las distinciones importantes.
Para un flujo de trabajo de agentes, la salida puede determinar qué siguiente paso definido debe considerarse. Proporciona la observación actual y las acciones candidatas con descripciones claras, y conserva después la opción seleccionada y sus probabilidades. La aplicación que lo integra aplica su política de actuación y registra lo que hizo. Mantén ese registro de ejecución separado del resultado de la decisión: seleccionar una ruta de revisión no establece que un revisor haya actuado, y seleccionar un paso de diagnóstico no establece que ese paso haya tenido éxito.
El artefacto final es el objeto de respuestas junto con el estado y el esquema que lo produjeron. Usa esos registros para examinar clasificaciones inesperadas, identificar criterios ambiguos y comparar resultados con ejemplos revisados de la tarea. Si un usuario posterior necesita una explicación escrita, la decisión y la evidencia original pueden ser entradas de un paso separado de redacción de respuestas. Clef proporciona la decisión probabilística acotada necesaria para elegir esa siguiente etapa con un registro claro de lo que se evaluó.
", "aboutText": "Cloudflare Clef es el modelo denso más grande de la familia de decisión Clef, obtenido mediante posentrenamiento de Qwen3.8-27B con su codificador visual. Cloudflare combina esa arquitectura base con un cabezal de esquema conjunto que dirige la evidencia a las preguntas y puntúa sus opciones permitidas de forma conjunta. Clef lee una situación y devuelve decisiones acotadas con probabilidades en una sola pasada de inferencia. Su salida es un resultado de clasificación, en lugar de prosa generada, un informe abierto o una propuesta de comando.\n\nPrepara el estado y el esquema de preguntas como entradas distintas. El estado puede ser una cadena de texto o JSON que represente un registro, una conversación, el contenido de un documento o una situación de una aplicación. Las preguntas se identifican mediante nombres estables, y esos mismos nombres identifican las respuestas devueltas. Define qué debe establecer cada pregunta y describe las opciones pertinentes. Un registro de soporte puede preguntar qué equipo debe atender la solicitud, si el impacto es urgente y qué criterio de gravedad corresponde, sin combinar esas decisiones diferentes en una categoría vaga.\n\nUna pregunta noul devuelve la probabilidad de verdadero para una condición binaria. Una pregunta choice devuelve una opción con nombre seleccionada, probabilidades por opción y confianza. Una pregunta score usa una lista ordenada de descripciones, con índices desde cero, y devuelve una puntuación esperada, una leyenda y las probabilidades. Una puntuación fraccionaria tiene significado porque resume la incertidumbre entre niveles ordenados. Examina la distribución además de la respuesta seleccionada; dos opciones próximas pueden revelar una distinción que la entrada no resuelve.\n\nPara comprobar políticas, incluye el texto real de la regla y los hechos del registro. Un ejemplo es un flujo de procesamiento de documentos con preguntas sobre si el registro está completo, qué categoría de revisión corresponde y con qué fuerza la evidencia respalda una atención inmediata. Haz preguntas separadas para condiciones separadas. Una evaluación del modelo sobre el cumplimiento debe permanecer vinculada a la regla y la evidencia proporcionadas. Si falta una condición importante, el esquema y la aplicación deben tener una forma deliberada de manejar esa incertidumbre.\n\nPara evidencia visual, proporciona una imagen legible y una pregunta sobre una condición visible o una categoría definida. Una comprobación de calidad de un formulario podría evaluar la legibilidad, si está presente un área obligatoria y cuál de los niveles de calidad proporcionados lo describe mejor. La interfaz de pesos abiertos del fabricante también acepta arreglos de fotogramas de video. Mantén los fotogramas en orden e identifica el evento que se debe evaluar. Un esquema de decisión acotado puede clasificar ese material, mientras que una solicitud de descripción narrativa o de campos nuevos arbitrarios corresponde a otro tipo de salida.\n\nLa referencia de la interfaz alojada del fabricante indica un contexto de 65,536 tokens, de una a 64 preguntas y hasta cuatro imágenes incrustadas. Sus imágenes PNG, JPEG o WebP están limitadas a 4 MiB y 16 megapíxeles cada una, con un total decodificado de 8 MiB; el cuerpo completo de la solicitud está limitado a 13 MiB y no se aceptan enlaces remotos a imágenes. El presupuesto de entrada incluye las preguntas y los medios. El texto largo puede truncarse para ajustarse, por lo que conviene conservar los pasajes decisivos y las etiquetas de origen. Estos límites describen la interfaz de imágenes alojada del productor; el codificador de pesos abiertos tiene sus propias representaciones de entradas locales.\n\nLa publicación de Cloudflare describe un entrenamiento para puntuación sujeta a esquemas y calibración de probabilidades. El modelo extrae evidencia pertinente para opciones individuales y luego considera la información entre campos. Esto puede apoyar decisiones sobre varias preguntas relacionadas en un mismo registro, pero no convierte una probabilidad alta en una garantía de que el hecho subyacente sea verdadero. Evalúa registros difíciles, incompletos y fuera de las categorías, además de casos sencillos. Los criterios de decisión útiles cubren las situaciones que el flujo de trabajo realmente encuentra y hacen explícitas las distinciones importantes.\n\nPara un flujo de trabajo de agentes, la salida puede determinar qué siguiente paso definido debe considerarse. Proporciona la observación actual y las acciones candidatas con descripciones claras, y conserva después la opción seleccionada y sus probabilidades. La aplicación que lo integra aplica su política de actuación y registra lo que hizo. Mantén ese registro de ejecución separado del resultado de la decisión: seleccionar una ruta de revisión no establece que un revisor haya actuado, y seleccionar un paso de diagnóstico no establece que ese paso haya tenido éxito.\n\nEl artefacto final es el objeto de respuestas junto con el estado y el esquema que lo produjeron. Usa esos registros para examinar clasificaciones inesperadas, identificar criterios ambiguos y comparar resultados con ejemplos revisados de la tarea. Si un usuario posterior necesita una explicación escrita, la decisión y la evidencia original pueden ser entradas de un paso separado de redacción de respuestas. Clef proporciona la decisión probabilística acotada necesaria para elegir esa siguiente etapa con un registro claro de lo que se evaluó.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "6a3d192f778a17a51a6505d990be454e29f1d299ec0b6365758ebed45da2c1cf", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "cloudflare/clefCloudflare Clef es un modelo multimodal de decisión de 27B parámetros para clasificación, comprobaciones de políticas y decisiones en flujos de trabajo de agentes. Evalúa un estado proporcionado y preguntas tipadas, y devuelve probabilidades para las alternativas permitidas, categorías seleccionadas y puntuaciones ponderadas. Acepta evidencia textual y visual sin generar prosa.
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.
Cloudflare Clef es el modelo denso más grande de la familia de decisión Clef, obtenido mediante posentrenamiento de Qwen3.8-27B con su codificador visual. Cloudflare combina esa arquitectura base con un cabezal de esquema conjunto que dirige la evidencia a las preguntas y puntúa sus opciones permitidas de forma conjunta. Clef lee una situación y devuelve decisiones acotadas con probabilidades en una sola pasada de inferencia. Su salida es un resultado de clasificación, en lugar de prosa generada, un informe abierto o una propuesta de comando.
Prepara el estado y el esquema de preguntas como entradas distintas. El estado puede ser una cadena de texto o JSON que represente un registro, una conversación, el contenido de un documento o una situación de una aplicación. Las preguntas se identifican mediante nombres estables, y esos mismos nombres identifican las respuestas devueltas. Define qué debe establecer cada pregunta y describe las opciones pertinentes. Un registro de soporte puede preguntar qué equipo debe atender la solicitud, si el impacto es urgente y qué criterio de gravedad corresponde, sin combinar esas decisiones diferentes en una categoría vaga.
Una pregunta noul devuelve la probabilidad de verdadero para una condición binaria. Una pregunta choice devuelve una opción con nombre seleccionada, probabilidades por opción y confianza. Una pregunta score usa una lista ordenada de descripciones, con índices desde cero, y devuelve una puntuación esperada, una leyenda y las probabilidades. Una puntuación fraccionaria tiene significado porque resume la incertidumbre entre niveles ordenados. Examina la distribución además de la respuesta seleccionada; dos opciones próximas pueden revelar una distinción que la entrada no resuelve.
Para comprobar políticas, incluye el texto real de la regla y los hechos del registro. Un ejemplo es un flujo de procesamiento de documentos con preguntas sobre si el registro está completo, qué categoría de revisión corresponde y con qué fuerza la evidencia respalda una atención inmediata. Haz preguntas separadas para condiciones separadas. Una evaluación del modelo sobre el cumplimiento debe permanecer vinculada a la regla y la evidencia proporcionadas. Si falta una condición importante, el esquema y la aplicación deben tener una forma deliberada de manejar esa incertidumbre.
Para evidencia visual, proporciona una imagen legible y una pregunta sobre una condición visible o una categoría definida. Una comprobación de calidad de un formulario podría evaluar la legibilidad, si está presente un área obligatoria y cuál de los niveles de calidad proporcionados lo describe mejor. La interfaz de pesos abiertos del fabricante también acepta arreglos de fotogramas de video. Mantén los fotogramas en orden e identifica el evento que se debe evaluar. Un esquema de decisión acotado puede clasificar ese material, mientras que una solicitud de descripción narrativa o de campos nuevos arbitrarios corresponde a otro tipo de salida.
La referencia de la interfaz alojada del fabricante indica un contexto de 65,536 tokens, de una a 64 preguntas y hasta cuatro imágenes incrustadas. Sus imágenes PNG, JPEG o WebP están limitadas a 4 MiB y 16 megapíxeles cada una, con un total decodificado de 8 MiB; el cuerpo completo de la solicitud está limitado a 13 MiB y no se aceptan enlaces remotos a imágenes. El presupuesto de entrada incluye las preguntas y los medios. El texto largo puede truncarse para ajustarse, por lo que conviene conservar los pasajes decisivos y las etiquetas de origen. Estos límites describen la interfaz de imágenes alojada del productor; el codificador de pesos abiertos tiene sus propias representaciones de entradas locales.
La publicación de Cloudflare describe un entrenamiento para puntuación sujeta a esquemas y calibración de probabilidades. El modelo extrae evidencia pertinente para opciones individuales y luego considera la información entre campos. Esto puede apoyar decisiones sobre varias preguntas relacionadas en un mismo registro, pero no convierte una probabilidad alta en una garantía de que el hecho subyacente sea verdadero. Evalúa registros difíciles, incompletos y fuera de las categorías, además de casos sencillos. Los criterios de decisión útiles cubren las situaciones que el flujo de trabajo realmente encuentra y hacen explícitas las distinciones importantes.
Para un flujo de trabajo de agentes, la salida puede determinar qué siguiente paso definido debe considerarse. Proporciona la observación actual y las acciones candidatas con descripciones claras, y conserva después la opción seleccionada y sus probabilidades. La aplicación que lo integra aplica su política de actuación y registra lo que hizo. Mantén ese registro de ejecución separado del resultado de la decisión: seleccionar una ruta de revisión no establece que un revisor haya actuado, y seleccionar un paso de diagnóstico no establece que ese paso haya tenido éxito.
El artefacto final es el objeto de respuestas junto con el estado y el esquema que lo produjeron. Usa esos registros para examinar clasificaciones inesperadas, identificar criterios ambiguos y comparar resultados con ejemplos revisados de la tarea. Si un usuario posterior necesita una explicación escrita, la decisión y la evidencia original pueden ser entradas de un paso separado de redacción de respuestas. Clef proporciona la decisión probabilística acotada necesaria para elegir esa siguiente etapa con un registro claro de lo que se evaluó.
POST /v1/systemonetext, imagedecisions| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites cloudflare/clef | Predeterminado— |
Campoprovider | Tiposchema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campoquestions | Tipoobject | RequisitoObligatorio | Valores y límites | Predeterminado— |
Camposession_id | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campostate | Tiposchema | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campotrace | Tiposchema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campouser | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campoquestions.<id>.type | Tipostring | RequisitoObligatorio | Valores y límites noul, choice, score | Predeterminado— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoOpcional | Valores y límites Condiciones: choice/score: obligatorios; noul: opcional. Los criterios de choice son un objeto; score es un arreglo con minItems1. | Predeterminado— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObligatorio | Valores y límites Se aplica cuando: Se proporcionó el objeto de criterios noul | Predeterminado— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObligatorio | Valores y límites Se aplica cuando: Se proporcionó el objeto de criterios noul | Predeterminado— |
noul · Obligatorio: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatorio: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatorio: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, state, questions |
Parámetromaterial_types | Contratotext, image |
Parámetrooptional_controls | Contratoprovider, session_id, trace, user |
Parámetromultimodal_input_binding | ContratoUsa únicamente la representación exacta declarada de estado o documento. La capacidad de imagen del fabricante por sí sola no establece un formato de entrada de imagen aceptado específico del modelo. |
Ciclo de vida: synchronous
Envía el ID exacto del modelo y conserva la respuesta nativa completa.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
Relaciona cada cargo con las condiciones mostradas. Usa una tarifa para cada conjunto de configuraciones alternativas.
| Configuración | Tabla de tarifas | Tokens de contexto, más de | Tokens de contexto, hasta inclusive | Cargo |
|---|---|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Tokens de contexto, más de— | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.00048 / 1K tokens Salida · Tokens de salida $0 / 1K tokens Entrada · Lectura de caché — / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
| ConfiguraciónNivel 1 por longitud de la solicitud | Tabla de tarifas— | Tokens de contexto, más de0 | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.00048 / 1K tokens Salida · Tokens de salida $0 / 1K tokens Entrada · Lectura de caché — / 1K tokens Entrada · Escritura en caché — / 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": "cloudflare/clef",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='cloudflare/clef'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\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\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Se conserva cada respuesta al ID de pregunta proporcionado con su tipo exacto, valor noul/choice/score, confianza, probabilidades y leyenda. El JSON original completo se almacena y devuelve únicamente después de liquidar el cargo.
Conserva la operación original y la respuesta completa o parcial; no repitas el POST.
| Campo | Tipo |
|---|---|
Campomodel | Tipostring |
Campoid | Tipostring |
Campoprovider | Tipostring |
Campoanswers.<id>.type | Tipostring |
Campoanswers.<id>.noul | Tiponumber |
Campoanswers.<id>.choice | Tipostring |
Campoanswers.<id>.score | Tiponumber |
Campoanswers.<id>.confidence | Tiponumber |
Campoanswers.<id>.probabilities | Tipoobject |
Campoanswers.<id>.legend | Tipoobject |
Campousage.input_tokens | Tipointeger |
Campousage.output_tokens | Tipointeger |
Campousage.cost | Tiponumber |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampo obligatorio, representación o valor no válido | Siguiente pasoCorrige el campo indicado de la solicitud. |
Ailoot Ultra cloudflare/clef
Usa las rutas de método indicadas arriba.