Cloudflare Clef Omni est le modèle multimodal à mélange d’experts de la famille de décision Clef. Il est issu d’un post-entraînement de l’architecture de compréhension Qwen3-Omni-30B-A3B-Instruct, avec 30 milliards de paramètres au total et 3 milliards actifs. Cloudflare y ajoute une tête commune au schéma, qui dirige les éléments probants vers les questions demandées et évalue ensemble leurs options autorisées. Le résultat est une décision typée assortie de probabilités, plutôt qu’une explication, une transcription ou une sortie vocale générée.
Préparez deux éléments principaux : un état décrivant la situation et une correspondance de questions nommées. L’état peut être du texte ou du JSON structuré ; les entrées natives du modèle comprennent aussi les images, l’audio et la vidéo. Chaque question précise la décision à prendre et les réponses autorisées. Conservez des identifiants stables afin qu’une application puisse associer chaque réponse renvoyée à la question d’origine. Des descriptions claires des options donnent un sens à chaque catégorie ; un libellé court et ambigu peut autrement masquer la distinction dont le processus a réellement besoin.
Le format d’enregistrement prévoit trois types de questions. Une question noul porte sur une condition vraie ou fausse et renvoie la probabilité qu’elle soit vraie. Une question choice définit des options nommées et renvoie l’option sélectionnée, les probabilités de chaque option et une valeur de confiance distincte. Une question score définit des critères ordonnés dont les indices commencent à zéro et renvoie un score pondéré par les probabilités, une légende et des probabilités. Le score peut être fractionnaire, car il reflète une distribution entre les niveaux. Une décision apporte donc davantage qu’un simple libellé, tout en restant délimitée par le schéma fourni.
Pour une vérification visuelle, fournissez une image nette et la condition à évaluer. Un exemple serait un dossier d’installation comportant des questions sur la visibilité de l’étiquette d’identification, la catégorie d’état applicable parmi celles définies et le caractère suffisant des éléments fournis pour la vérification. Distinguez les observations : la visibilité d’une étiquette et l’apparence achevée d’une installation sont deux questions différentes. La sortie peut aider une application à orienter le dossier ou à signaler une condition nécessitant une vérification ; elle n’effectue elle-même aucune inspection, ne modifie aucun dossier et ne génère aucun rapport écrit.
Pour l’audio et la vidéo, concentrez les questions sur les éléments que l’extrait fourni permet d’établir. Une vérification concrète d’un équipement pourrait réunir une photo, un enregistrement et une courte vidéo, avec des questions sur la présence d’un son précis ou le mouvement visible d’un composant. Le fabricant décrit le traitement de la piste sonore d’une vidéo avec ses images lorsque toutes les vidéos du dossier comportent du son. Préservez le lien entre les médias et l’état écrit, et évitez de demander au modèle de classer un événement situé en dehors de l’intervalle joint.
Le profil hébergé du fabricant indique un contexte de 64 000 tokens et d’une à 64 questions. Il accepte jusqu’à quatre images, quatre extraits audio et deux vidéos, avec une limite de 300 secondes par extrait audio et de 60 secondes par vidéo. Il s’agit des limites de l’interface documentée du producteur. Les médias et les questions occupent le contexte ; une quantité excessive de médias peut faire échouer la requête, tandis qu’un état textuel long peut être tronqué pour tenir dans la fenêtre. Rassemblez les éléments décisifs dans un dossier ciblé et préparez les questions avant de consacrer la fenêtre à un historique sans rapport.
L’interface hébergée du fabricant reçoit des médias incorporés plutôt que des liens distants. Ses images PNG, JPEG ou WebP sont limitées à 4 MiB et 16 mégapixels chacune, avec un budget total de 8 MiB d’images décodées. Chaque extrait audio est limité à 8 MiB et 300 secondes ; chaque vidéo à 16 MiB et 60 secondes. L’audio et la vidéo réunis ne peuvent dépasser 16 MiB après décodage, et les vidéos sont échantillonnées à deux images par seconde. Ces limites appartiennent à cette interface du producteur ; l’encodeur aux poids ouverts accepte d’autres représentations locales. La capacité audio de l’architecture de compréhension ne signifie pas que ce modèle de décision produit de l’audio : ses composants de génération vocale ne servent pas à l’évaluation des décisions.
Pour l’orientation des demandes d’assistance ou des processus, définissez les catégories et les critères ordonnés à partir des règles de fonctionnement réelles. Un dossier d’assistance pourrait demander quelle équipe doit le traiter, si l’impact est urgent et quel niveau de gravité correspond le mieux aux éléments disponibles. La sortie observable est un ensemble de réponses typées sous les noms de ces questions. Examinez toute la distribution de probabilités lorsque les catégories sont proches et définissez explicitement la façon dont l’application traite les cas incertains. Une probabilité élevée est une évaluation des éléments fournis par le modèle, et non la preuve que la condition a été vérifiée de manière indépendante.
Conservez ensemble l’état, le schéma des questions et les réponses renvoyées lorsque vous examinez un résultat. Vérifiez si les options couvrent la situation réelle, si leurs descriptions se recoupent et si des éléments importants ont été omis ou tronqués. Si une étape ultérieure nécessite une explication écrite, elle peut utiliser la décision et les sources comme entrées d’une étape de rédaction distincte. Le rôle utile de Clef Omni consiste à évaluer des alternatives définies à partir d’éléments multimodaux, afin de choisir l’action suivante sur la base d’entrées et de sorties claires et examinables.
", "aboutText": "Cloudflare Clef Omni est le modèle multimodal à mélange d’experts de la famille de décision Clef. Il est issu d’un post-entraînement de l’architecture de compréhension Qwen3-Omni-30B-A3B-Instruct, avec 30 milliards de paramètres au total et 3 milliards actifs. Cloudflare y ajoute une tête commune au schéma, qui dirige les éléments probants vers les questions demandées et évalue ensemble leurs options autorisées. Le résultat est une décision typée assortie de probabilités, plutôt qu’une explication, une transcription ou une sortie vocale générée.\n\nPréparez deux éléments principaux : un état décrivant la situation et une correspondance de questions nommées. L’état peut être du texte ou du JSON structuré ; les entrées natives du modèle comprennent aussi les images, l’audio et la vidéo. Chaque question précise la décision à prendre et les réponses autorisées. Conservez des identifiants stables afin qu’une application puisse associer chaque réponse renvoyée à la question d’origine. Des descriptions claires des options donnent un sens à chaque catégorie ; un libellé court et ambigu peut autrement masquer la distinction dont le processus a réellement besoin.\n\nLe format d’enregistrement prévoit trois types de questions. Une question noul porte sur une condition vraie ou fausse et renvoie la probabilité qu’elle soit vraie. Une question choice définit des options nommées et renvoie l’option sélectionnée, les probabilités de chaque option et une valeur de confiance distincte. Une question score définit des critères ordonnés dont les indices commencent à zéro et renvoie un score pondéré par les probabilités, une légende et des probabilités. Le score peut être fractionnaire, car il reflète une distribution entre les niveaux. Une décision apporte donc davantage qu’un simple libellé, tout en restant délimitée par le schéma fourni.\n\nPour une vérification visuelle, fournissez une image nette et la condition à évaluer. Un exemple serait un dossier d’installation comportant des questions sur la visibilité de l’étiquette d’identification, la catégorie d’état applicable parmi celles définies et le caractère suffisant des éléments fournis pour la vérification. Distinguez les observations : la visibilité d’une étiquette et l’apparence achevée d’une installation sont deux questions différentes. La sortie peut aider une application à orienter le dossier ou à signaler une condition nécessitant une vérification ; elle n’effectue elle-même aucune inspection, ne modifie aucun dossier et ne génère aucun rapport écrit.\n\nPour l’audio et la vidéo, concentrez les questions sur les éléments que l’extrait fourni permet d’établir. Une vérification concrète d’un équipement pourrait réunir une photo, un enregistrement et une courte vidéo, avec des questions sur la présence d’un son précis ou le mouvement visible d’un composant. Le fabricant décrit le traitement de la piste sonore d’une vidéo avec ses images lorsque toutes les vidéos du dossier comportent du son. Préservez le lien entre les médias et l’état écrit, et évitez de demander au modèle de classer un événement situé en dehors de l’intervalle joint.\n\nLe profil hébergé du fabricant indique un contexte de 64 000 tokens et d’une à 64 questions. Il accepte jusqu’à quatre images, quatre extraits audio et deux vidéos, avec une limite de 300 secondes par extrait audio et de 60 secondes par vidéo. Il s’agit des limites de l’interface documentée du producteur. Les médias et les questions occupent le contexte ; une quantité excessive de médias peut faire échouer la requête, tandis qu’un état textuel long peut être tronqué pour tenir dans la fenêtre. Rassemblez les éléments décisifs dans un dossier ciblé et préparez les questions avant de consacrer la fenêtre à un historique sans rapport.\n\nL’interface hébergée du fabricant reçoit des médias incorporés plutôt que des liens distants. Ses images PNG, JPEG ou WebP sont limitées à 4 MiB et 16 mégapixels chacune, avec un budget total de 8 MiB d’images décodées. Chaque extrait audio est limité à 8 MiB et 300 secondes ; chaque vidéo à 16 MiB et 60 secondes. L’audio et la vidéo réunis ne peuvent dépasser 16 MiB après décodage, et les vidéos sont échantillonnées à deux images par seconde. Ces limites appartiennent à cette interface du producteur ; l’encodeur aux poids ouverts accepte d’autres représentations locales. La capacité audio de l’architecture de compréhension ne signifie pas que ce modèle de décision produit de l’audio : ses composants de génération vocale ne servent pas à l’évaluation des décisions.\n\nPour l’orientation des demandes d’assistance ou des processus, définissez les catégories et les critères ordonnés à partir des règles de fonctionnement réelles. Un dossier d’assistance pourrait demander quelle équipe doit le traiter, si l’impact est urgent et quel niveau de gravité correspond le mieux aux éléments disponibles. La sortie observable est un ensemble de réponses typées sous les noms de ces questions. Examinez toute la distribution de probabilités lorsque les catégories sont proches et définissez explicitement la façon dont l’application traite les cas incertains. Une probabilité élevée est une évaluation des éléments fournis par le modèle, et non la preuve que la condition a été vérifiée de manière indépendante.\n\nConservez ensemble l’état, le schéma des questions et les réponses renvoyées lorsque vous examinez un résultat. Vérifiez si les options couvrent la situation réelle, si leurs descriptions se recoupent et si des éléments importants ont été omis ou tronqués. Si une étape ultérieure nécessite une explication écrite, elle peut utiliser la décision et les sources comme entrées d’une étape de rédaction distincte. Le rôle utile de Clef Omni consiste à évaluer des alternatives définies à partir d’éléments multimodaux, afin de choisir l’action suivante sur la base d’entrées et de sorties claires et examinables.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "835bfb7e275ee5c0efe57efb89f304cdb8cc23a70653d5d4b7116a1ce332879c", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-ch", "methods": [ { "html": "cloudflare/clef-omniCloudflare Clef Omni est un modèle de décision multimodal reposant sur une architecture MoE de 30 milliards de paramètres au total, dont 3 milliards actifs. Il évalue le texte, l’état structuré et les médias fournis à l’aide de questions typées, puis renvoie des probabilités et des décisions délimitées. Sa sortie prend la forme d’un choix, d’une probabilité que la condition soit vraie ou d’un score ordonné, plutôt que d’un texte généré.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Cloudflare Clef Omni est le modèle multimodal à mélange d’experts de la famille de décision Clef. Il est issu d’un post-entraînement de l’architecture de compréhension Qwen3-Omni-30B-A3B-Instruct, avec 30 milliards de paramètres au total et 3 milliards actifs. Cloudflare y ajoute une tête commune au schéma, qui dirige les éléments probants vers les questions demandées et évalue ensemble leurs options autorisées. Le résultat est une décision typée assortie de probabilités, plutôt qu’une explication, une transcription ou une sortie vocale générée.
Préparez deux éléments principaux : un état décrivant la situation et une correspondance de questions nommées. L’état peut être du texte ou du JSON structuré ; les entrées natives du modèle comprennent aussi les images, l’audio et la vidéo. Chaque question précise la décision à prendre et les réponses autorisées. Conservez des identifiants stables afin qu’une application puisse associer chaque réponse renvoyée à la question d’origine. Des descriptions claires des options donnent un sens à chaque catégorie ; un libellé court et ambigu peut autrement masquer la distinction dont le processus a réellement besoin.
Le format d’enregistrement prévoit trois types de questions. Une question noul porte sur une condition vraie ou fausse et renvoie la probabilité qu’elle soit vraie. Une question choice définit des options nommées et renvoie l’option sélectionnée, les probabilités de chaque option et une valeur de confiance distincte. Une question score définit des critères ordonnés dont les indices commencent à zéro et renvoie un score pondéré par les probabilités, une légende et des probabilités. Le score peut être fractionnaire, car il reflète une distribution entre les niveaux. Une décision apporte donc davantage qu’un simple libellé, tout en restant délimitée par le schéma fourni.
Pour une vérification visuelle, fournissez une image nette et la condition à évaluer. Un exemple serait un dossier d’installation comportant des questions sur la visibilité de l’étiquette d’identification, la catégorie d’état applicable parmi celles définies et le caractère suffisant des éléments fournis pour la vérification. Distinguez les observations : la visibilité d’une étiquette et l’apparence achevée d’une installation sont deux questions différentes. La sortie peut aider une application à orienter le dossier ou à signaler une condition nécessitant une vérification ; elle n’effectue elle-même aucune inspection, ne modifie aucun dossier et ne génère aucun rapport écrit.
Pour l’audio et la vidéo, concentrez les questions sur les éléments que l’extrait fourni permet d’établir. Une vérification concrète d’un équipement pourrait réunir une photo, un enregistrement et une courte vidéo, avec des questions sur la présence d’un son précis ou le mouvement visible d’un composant. Le fabricant décrit le traitement de la piste sonore d’une vidéo avec ses images lorsque toutes les vidéos du dossier comportent du son. Préservez le lien entre les médias et l’état écrit, et évitez de demander au modèle de classer un événement situé en dehors de l’intervalle joint.
Le profil hébergé du fabricant indique un contexte de 64 000 tokens et d’une à 64 questions. Il accepte jusqu’à quatre images, quatre extraits audio et deux vidéos, avec une limite de 300 secondes par extrait audio et de 60 secondes par vidéo. Il s’agit des limites de l’interface documentée du producteur. Les médias et les questions occupent le contexte ; une quantité excessive de médias peut faire échouer la requête, tandis qu’un état textuel long peut être tronqué pour tenir dans la fenêtre. Rassemblez les éléments décisifs dans un dossier ciblé et préparez les questions avant de consacrer la fenêtre à un historique sans rapport.
L’interface hébergée du fabricant reçoit des médias incorporés plutôt que des liens distants. Ses images PNG, JPEG ou WebP sont limitées à 4 MiB et 16 mégapixels chacune, avec un budget total de 8 MiB d’images décodées. Chaque extrait audio est limité à 8 MiB et 300 secondes ; chaque vidéo à 16 MiB et 60 secondes. L’audio et la vidéo réunis ne peuvent dépasser 16 MiB après décodage, et les vidéos sont échantillonnées à deux images par seconde. Ces limites appartiennent à cette interface du producteur ; l’encodeur aux poids ouverts accepte d’autres représentations locales. La capacité audio de l’architecture de compréhension ne signifie pas que ce modèle de décision produit de l’audio : ses composants de génération vocale ne servent pas à l’évaluation des décisions.
Pour l’orientation des demandes d’assistance ou des processus, définissez les catégories et les critères ordonnés à partir des règles de fonctionnement réelles. Un dossier d’assistance pourrait demander quelle équipe doit le traiter, si l’impact est urgent et quel niveau de gravité correspond le mieux aux éléments disponibles. La sortie observable est un ensemble de réponses typées sous les noms de ces questions. Examinez toute la distribution de probabilités lorsque les catégories sont proches et définissez explicitement la façon dont l’application traite les cas incertains. Une probabilité élevée est une évaluation des éléments fournis par le modèle, et non la preuve que la condition a été vérifiée de manière indépendante.
Conservez ensemble l’état, le schéma des questions et les réponses renvoyées lorsque vous examinez un résultat. Vérifiez si les options couvrent la situation réelle, si leurs descriptions se recoupent et si des éléments importants ont été omis ou tronqués. Si une étape ultérieure nécessite une explication écrite, elle peut utiliser la décision et les sources comme entrées d’une étape de rédaction distincte. Le rôle utile de Clef Omni consiste à évaluer des alternatives définies à partir d’éléments multimodaux, afin de choisir l’action suivante sur la base d’entrées et de sorties claires et examinables.
POST /v1/systemonetext, imagedecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites cloudflare/clef-omni | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions | Typeobject | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champstate | Typeschema | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions.<id>.type | Typestring | ExigenceObligatoire | Valeurs et limites noul, choice, score | Par défaut— |
Champquestions.<id>.instructions | Typestring|object|array | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champquestions.<id>.criteria | Typeobject|array | ExigenceFacultatif | Valeurs et limites Conditions: choice/score : obligatoire ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems1. | Par défaut— |
Champquestions.<id>.criteria.true | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
Champquestions.<id>.criteria.false | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
noul · Obligatoire : state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatoire : state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatoire : state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, state, questions |
Paramètrematerial_types | Contrattext, image |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | ContratUtilisez uniquement la représentation exacte déclarée de l’état ou du document. La capacité du fabricant à traiter des images ne suffit pas à établir un format de transport d’image accepté pour le modèle concerné. |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Tokens de contexte, plus de | Tokens de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Tokens de contexte, plus de— | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.0003 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Tokens de contexte, plus de0 | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.0003 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\n "model": "cloudflare/clef-omni",\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-omni'\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
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Chaque réponse fournie pour un identifiant de question est conservée avec son type exact, sa valeur noul/choice/score, son niveau de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est enregistrée et renvoyée uniquement après la facturation définitive.
Conservez l’opération d’origine et la réponse complète ou partielle ; ne répétez pas le POST.
| Champ | Type |
|---|---|
Champmodel | Typestring |
Champid | Typestring |
Champprovider | Typestring |
Champanswers.<id>.type | Typestring |
Champanswers.<id>.noul | Typenumber |
Champanswers.<id>.choice | Typestring |
Champanswers.<id>.score | Typenumber |
Champanswers.<id>.confidence | Typenumber |
Champanswers.<id>.probabilities | Typeobject |
Champanswers.<id>.legend | Typeobject |
Champusage.input_tokens | Typeinteger |
Champusage.output_tokens | Typeinteger |
Champusage.cost | Typenumber |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamp obligatoire, représentation ou valeur invalide | Étape suivanteCorrigez le champ indiqué dans la requête. |
Ailoot Ultra cloudflare/clef-omni
Utilisez les chemins de méthode indiqués ci-dessus.