Cloudflare Clef är den större täta modellen i Clefs familj av beslutsmodeller, eftertränad från Qwen3.8-27B med dess visuella kodare. Cloudflare kombinerar den basmodellen med ett gemensamt schemahuvud som kopplar evidens till frågorna och poängsätter deras tillåtna alternativ tillsammans. Clef läser en situation och returnerar avgränsade beslut med sannolikheter i en enda framåtpassering. Resultatet är en klassificering, snarare än genererad prosa, en öppen rapport eller ett föreslaget kommando.
Förbered tillståndet och frågeschemat som separata indata. Tillståndet kan vara en sträng eller JSON som representerar en post, en konversation, dokumentinnehåll eller en situation i applikationen. Frågorna har stabila namn som nycklar, och samma namn identifierar deras returnerade svar. Definiera vad varje fråga ska fastställa och beskriv de relevanta alternativen. En supportpost kan fråga vilket team som ska hantera förfrågan, om påverkan är akut och vilket allvarlighetskriterium som gäller, utan att slå ihop dessa olika beslut till en vag kategori.
En noul-fråga returnerar sannolikheten för att ett binärt villkor är sant. En choice-fråga returnerar ett valt namngivet alternativ, sannolikheter per alternativ och konfidens. En score-fråga använder en ordnad lista med beskrivningar, indexerad från noll, och returnerar en förväntad poäng, en teckenförklaring och sannolikheter. En poäng med decimaler är meningsfull eftersom den sammanfattar osäkerhet över ordnade nivåer. Undersök både fördelningen och det valda svaret; två närliggande alternativ kan avslöja en skillnad som indata inte avgör.
För regelkontroller tar du med den faktiska regeltexten och postens fakta. Ett exempel är ett arbetsflöde för dokumentbehandling med frågor om posten är fullständig, vilken granskningskategori som gäller och hur starkt evidensen stöder omedelbar uppmärksamhet. Ställ separata frågor för separata villkor. En modellbedömning av regelefterlevnad bör förbli kopplad till den inskickade regeln och evidensen. Om ett viktigt villkor saknas bör schemat och applikationen ha ett genomtänkt sätt att hantera den osäkerheten.
För visuell evidens anger du en läsbar bild och en fråga om ett synligt förhållande eller en definierad kategori. En kvalitetskontroll av ett formulär kan bedöma läsbarhet, om ett obligatoriskt område finns och vilken av de angivna kvalitetsnivåerna som bäst beskriver det. Tillverkarens gränssnitt med öppna modellvikter accepterar även arrayer med videobildrutor. Behåll bildrutorna i ordning och identifiera händelsen som ska bedömas. Ett avgränsat beslutsschema kan klassificera det materialet, medan en begäran om en berättande beskrivning eller godtyckliga nygenererade fält hör till en annan typ av resultat.
Tillverkarens hostade referens anger en kontext på 65 536 token, en till 64 frågor och upp till fyra inbäddade bilder. PNG-, JPEG- eller WebP-bilder är begränsade till 4 MiB och 16 megapixlar per bild, med totalt 8 MiB avkodade data; hela begärandekroppen är begränsad till 13 MiB och fjärrlänkar till bilder accepteras inte. Indatabudgeten omfattar frågorna och medierna. Lång text kan kapas för att få plats, så bevara avgörande avsnitt och källetiketter. Dessa gränser beskriver tillverkarens hostade bildgränssnitt; kodaren med öppna modellvikter har egna representationer för lokala indata.
Cloudflares utgåva beskriver träning för schemabunden poängsättning och sannolikhetskalibrering. Modellen hämtar relevant evidens för enskilda alternativ och väger sedan samman information mellan fält. Detta kan stödja beslut om flera relaterade frågor i en post, men gör inte en hög sannolikhet till en garanti för att det bakomliggande sakförhållandet är sant. Bedöm svåra, ofullständiga och kategorifrämmande poster likaväl som okomplicerade fall. Användbara beslutskriterier täcker situationer som arbetsflödet faktiskt möter och gör viktiga skillnader uttryckliga.
I ett agentarbetsflöde kan resultatet avgöra vilket definierat nästa steg som bör övervägas. Ange den aktuella observationen och möjliga åtgärder med tydliga beskrivningar och spara sedan det valda alternativet och dess sannolikheter. Den omgivande applikationen tillämpar sin åtgärdspolicy och registrerar vad den gjorde. Håll den utförandeloggen åtskild från beslutsresultatet: Att välja en granskningsväg fastställer inte att en granskare agerade, och att välja ett diagnostiskt steg fastställer inte att steget lyckades.
Den slutliga artefakten är answers-objektet tillsammans med tillståndet och schemat som gav upphov till det. Använd dessa poster för att undersöka oväntade klassificeringar, identifiera tvetydiga kriterier och jämföra resultat med granskade uppgiftsexempel. Om en efterföljande användare behöver en skriftlig förklaring kan beslutet och den ursprungliga evidensen vara indata till ett separat steg för att skriva svaret. Clef tillhandahåller det avgränsade sannolikhetsbaserade beslut som behövs för att välja nästa steg med en tydlig redovisning av vad som bedömdes.
", "aboutText": "Cloudflare Clef är den större täta modellen i Clefs familj av beslutsmodeller, eftertränad från Qwen3.8-27B med dess visuella kodare. Cloudflare kombinerar den basmodellen med ett gemensamt schemahuvud som kopplar evidens till frågorna och poängsätter deras tillåtna alternativ tillsammans. Clef läser en situation och returnerar avgränsade beslut med sannolikheter i en enda framåtpassering. Resultatet är en klassificering, snarare än genererad prosa, en öppen rapport eller ett föreslaget kommando.\n\nFörbered tillståndet och frågeschemat som separata indata. Tillståndet kan vara en sträng eller JSON som representerar en post, en konversation, dokumentinnehåll eller en situation i applikationen. Frågorna har stabila namn som nycklar, och samma namn identifierar deras returnerade svar. Definiera vad varje fråga ska fastställa och beskriv de relevanta alternativen. En supportpost kan fråga vilket team som ska hantera förfrågan, om påverkan är akut och vilket allvarlighetskriterium som gäller, utan att slå ihop dessa olika beslut till en vag kategori.\n\nEn noul-fråga returnerar sannolikheten för att ett binärt villkor är sant. En choice-fråga returnerar ett valt namngivet alternativ, sannolikheter per alternativ och konfidens. En score-fråga använder en ordnad lista med beskrivningar, indexerad från noll, och returnerar en förväntad poäng, en teckenförklaring och sannolikheter. En poäng med decimaler är meningsfull eftersom den sammanfattar osäkerhet över ordnade nivåer. Undersök både fördelningen och det valda svaret; två närliggande alternativ kan avslöja en skillnad som indata inte avgör.\n\nFör regelkontroller tar du med den faktiska regeltexten och postens fakta. Ett exempel är ett arbetsflöde för dokumentbehandling med frågor om posten är fullständig, vilken granskningskategori som gäller och hur starkt evidensen stöder omedelbar uppmärksamhet. Ställ separata frågor för separata villkor. En modellbedömning av regelefterlevnad bör förbli kopplad till den inskickade regeln och evidensen. Om ett viktigt villkor saknas bör schemat och applikationen ha ett genomtänkt sätt att hantera den osäkerheten.\n\nFör visuell evidens anger du en läsbar bild och en fråga om ett synligt förhållande eller en definierad kategori. En kvalitetskontroll av ett formulär kan bedöma läsbarhet, om ett obligatoriskt område finns och vilken av de angivna kvalitetsnivåerna som bäst beskriver det. Tillverkarens gränssnitt med öppna modellvikter accepterar även arrayer med videobildrutor. Behåll bildrutorna i ordning och identifiera händelsen som ska bedömas. Ett avgränsat beslutsschema kan klassificera det materialet, medan en begäran om en berättande beskrivning eller godtyckliga nygenererade fält hör till en annan typ av resultat.\n\nTillverkarens hostade referens anger en kontext på 65 536 token, en till 64 frågor och upp till fyra inbäddade bilder. PNG-, JPEG- eller WebP-bilder är begränsade till 4 MiB och 16 megapixlar per bild, med totalt 8 MiB avkodade data; hela begärandekroppen är begränsad till 13 MiB och fjärrlänkar till bilder accepteras inte. Indatabudgeten omfattar frågorna och medierna. Lång text kan kapas för att få plats, så bevara avgörande avsnitt och källetiketter. Dessa gränser beskriver tillverkarens hostade bildgränssnitt; kodaren med öppna modellvikter har egna representationer för lokala indata.\n\nCloudflares utgåva beskriver träning för schemabunden poängsättning och sannolikhetskalibrering. Modellen hämtar relevant evidens för enskilda alternativ och väger sedan samman information mellan fält. Detta kan stödja beslut om flera relaterade frågor i en post, men gör inte en hög sannolikhet till en garanti för att det bakomliggande sakförhållandet är sant. Bedöm svåra, ofullständiga och kategorifrämmande poster likaväl som okomplicerade fall. Användbara beslutskriterier täcker situationer som arbetsflödet faktiskt möter och gör viktiga skillnader uttryckliga.\n\nI ett agentarbetsflöde kan resultatet avgöra vilket definierat nästa steg som bör övervägas. Ange den aktuella observationen och möjliga åtgärder med tydliga beskrivningar och spara sedan det valda alternativet och dess sannolikheter. Den omgivande applikationen tillämpar sin åtgärdspolicy och registrerar vad den gjorde. Håll den utförandeloggen åtskild från beslutsresultatet: Att välja en granskningsväg fastställer inte att en granskare agerade, och att välja ett diagnostiskt steg fastställer inte att steget lyckades.\n\nDen slutliga artefakten är answers-objektet tillsammans med tillståndet och schemat som gav upphov till det. Använd dessa poster för att undersöka oväntade klassificeringar, identifiera tvetydiga kriterier och jämföra resultat med granskade uppgiftsexempel. Om en efterföljande användare behöver en skriftlig förklaring kan beslutet och den ursprungliga evidensen vara indata till ett separat steg för att skriva svaret. Clef tillhandahåller det avgränsade sannolikhetsbaserade beslut som behövs för att välja nästa steg med en tydlig redovisning av vad som bedömdes.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "eafeb8c5ba29d0a078af25b5ffbf7716540234169fc181d36b242a773e0f01d1", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "cloudflare/clefCloudflare Clef är en multimodal beslutsmodell på 27B parametrar för klassificering, regelkontroller och val i agenters arbetsflöden. Den bedömer ett inskickat tillstånd och typade frågor och returnerar sannolikheter för tillåtna alternativ, valda kategorier och viktade poäng. Den accepterar textbaserad och visuell evidens utan att generera prosa.
Den här beskrivningen omfattar modellens förmågor. Tillgängliga indata, utdata och alternativ i Ailoot anges nedan för den valda metoden.
Cloudflare Clef är den större täta modellen i Clefs familj av beslutsmodeller, eftertränad från Qwen3.8-27B med dess visuella kodare. Cloudflare kombinerar den basmodellen med ett gemensamt schemahuvud som kopplar evidens till frågorna och poängsätter deras tillåtna alternativ tillsammans. Clef läser en situation och returnerar avgränsade beslut med sannolikheter i en enda framåtpassering. Resultatet är en klassificering, snarare än genererad prosa, en öppen rapport eller ett föreslaget kommando.
Förbered tillståndet och frågeschemat som separata indata. Tillståndet kan vara en sträng eller JSON som representerar en post, en konversation, dokumentinnehåll eller en situation i applikationen. Frågorna har stabila namn som nycklar, och samma namn identifierar deras returnerade svar. Definiera vad varje fråga ska fastställa och beskriv de relevanta alternativen. En supportpost kan fråga vilket team som ska hantera förfrågan, om påverkan är akut och vilket allvarlighetskriterium som gäller, utan att slå ihop dessa olika beslut till en vag kategori.
En noul-fråga returnerar sannolikheten för att ett binärt villkor är sant. En choice-fråga returnerar ett valt namngivet alternativ, sannolikheter per alternativ och konfidens. En score-fråga använder en ordnad lista med beskrivningar, indexerad från noll, och returnerar en förväntad poäng, en teckenförklaring och sannolikheter. En poäng med decimaler är meningsfull eftersom den sammanfattar osäkerhet över ordnade nivåer. Undersök både fördelningen och det valda svaret; två närliggande alternativ kan avslöja en skillnad som indata inte avgör.
För regelkontroller tar du med den faktiska regeltexten och postens fakta. Ett exempel är ett arbetsflöde för dokumentbehandling med frågor om posten är fullständig, vilken granskningskategori som gäller och hur starkt evidensen stöder omedelbar uppmärksamhet. Ställ separata frågor för separata villkor. En modellbedömning av regelefterlevnad bör förbli kopplad till den inskickade regeln och evidensen. Om ett viktigt villkor saknas bör schemat och applikationen ha ett genomtänkt sätt att hantera den osäkerheten.
För visuell evidens anger du en läsbar bild och en fråga om ett synligt förhållande eller en definierad kategori. En kvalitetskontroll av ett formulär kan bedöma läsbarhet, om ett obligatoriskt område finns och vilken av de angivna kvalitetsnivåerna som bäst beskriver det. Tillverkarens gränssnitt med öppna modellvikter accepterar även arrayer med videobildrutor. Behåll bildrutorna i ordning och identifiera händelsen som ska bedömas. Ett avgränsat beslutsschema kan klassificera det materialet, medan en begäran om en berättande beskrivning eller godtyckliga nygenererade fält hör till en annan typ av resultat.
Tillverkarens hostade referens anger en kontext på 65 536 token, en till 64 frågor och upp till fyra inbäddade bilder. PNG-, JPEG- eller WebP-bilder är begränsade till 4 MiB och 16 megapixlar per bild, med totalt 8 MiB avkodade data; hela begärandekroppen är begränsad till 13 MiB och fjärrlänkar till bilder accepteras inte. Indatabudgeten omfattar frågorna och medierna. Lång text kan kapas för att få plats, så bevara avgörande avsnitt och källetiketter. Dessa gränser beskriver tillverkarens hostade bildgränssnitt; kodaren med öppna modellvikter har egna representationer för lokala indata.
Cloudflares utgåva beskriver träning för schemabunden poängsättning och sannolikhetskalibrering. Modellen hämtar relevant evidens för enskilda alternativ och väger sedan samman information mellan fält. Detta kan stödja beslut om flera relaterade frågor i en post, men gör inte en hög sannolikhet till en garanti för att det bakomliggande sakförhållandet är sant. Bedöm svåra, ofullständiga och kategorifrämmande poster likaväl som okomplicerade fall. Användbara beslutskriterier täcker situationer som arbetsflödet faktiskt möter och gör viktiga skillnader uttryckliga.
I ett agentarbetsflöde kan resultatet avgöra vilket definierat nästa steg som bör övervägas. Ange den aktuella observationen och möjliga åtgärder med tydliga beskrivningar och spara sedan det valda alternativet och dess sannolikheter. Den omgivande applikationen tillämpar sin åtgärdspolicy och registrerar vad den gjorde. Håll den utförandeloggen åtskild från beslutsresultatet: Att välja en granskningsväg fastställer inte att en granskare agerade, och att välja ett diagnostiskt steg fastställer inte att steget lyckades.
Den slutliga artefakten är answers-objektet tillsammans med tillståndet och schemat som gav upphov till det. Använd dessa poster för att undersöka oväntade klassificeringar, identifiera tvetydiga kriterier och jämföra resultat med granskade uppgiftsexempel. Om en efterföljande användare behöver en skriftlig förklaring kan beslutet och den ursprungliga evidensen vara indata till ett separat steg för att skriva svaret. Clef tillhandahåller det avgränsade sannolikhetsbaserade beslut som behövs för att välja nästa steg med en tydlig redovisning av vad som bedömdes.
POST /v1/systemonetext, imagedecisions| Fält | Typ | Krav | Värden & gränser | Standard |
|---|---|---|---|---|
Fältmodel | Typstring | KravObligatoriskt | Värden & gränser cloudflare/clef | Standard— |
Fältprovider | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältquestions | Typobject | KravObligatoriskt | Värden & gränser | Standard— |
Fältsession_id | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältstate | Typschema | KravObligatoriskt | Värden & gränser | Standard— |
Fälttrace | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältuser | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältquestions.<id>.type | Typstring | KravObligatoriskt | Värden & gränser noul, choice, score | Standard— |
Fältquestions.<id>.instructions | Typstring|object|array | KravObligatoriskt | Värden & gränser | Standard— |
Fältquestions.<id>.criteria | Typobject|array | KravValfritt | Värden & gränser Villkor: choice/score: obligatoriskt; noul: valfritt. Kriterier för choice är ett objekt; score är en array med minItems1. | Standard— |
Fältquestions.<id>.criteria.true | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
Fältquestions.<id>.criteria.false | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
noul · Krävs: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Krävs: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Krävs: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Avtal |
|---|---|
Parametercontent_type | Avtalapplication/json |
Parameterrequired | Avtalmodel, state, questions |
Parametermaterial_types | Avtaltext, image |
Parameteroptional_controls | Avtalprovider, session_id, trace, user |
Parametermultimodal_input_binding | AvtalAnvänd endast den exakt deklarerade representationen av tillstånd eller dokument. Tillverkarens bildfunktioner i sig fastställer inte någon accepterad modellspecifik form för bildindata. |
Livscykel: synchronous
Skicka det exakta modell-ID:t och behåll hela svaret i leverantörens format.
Tariffuppgifter lägger inte till begäransalternativ. Parametrar som stöds anges för den valda metoden.
Matcha varje avgift mot de visade villkoren. Använd ett pris för varje uppsättning alternativa konfigurationer.
| Konfiguration | Prislista | Kontexttoken, fler än | Kontexttoken, upp till och med | Avgift |
|---|---|---|---|---|
| KonfigurationGrundpriser för token | PrislistaGrundpris | Kontexttoken, fler än— | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.00048 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
| KonfigurationNivå 1 för förfrågans längd | Prislista— | Kontexttoken, fler än0 | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.00048 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
Ailoot reserverar ett uppskattat belopp före en begäran. Efter resultatet slutregleras avgiften utifrån uppmätt förbrukning. Slutreglering för strömning använder den slutliga förbrukningsposten. Så fungerar reservation och slutreglering →
{\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
Behåll varje fullständigt returnerat svar, fil och innehållsdel.
Varje angivet svar för ett fråge-ID behålls med sin exakta typ, värdet noul/choice/score, konfidens, sannolikheter och teckenförklaring. Hela det ursprungliga JSON-svaret lagras och returneras först efter avräkning.
Bevara den ursprungliga operationen och hela eller det partiella svaret; upprepa inte POST.
| Fält | Typ |
|---|---|
Fältmodel | Typstring |
Fältid | Typstring |
Fältprovider | Typstring |
Fältanswers.<id>.type | Typstring |
Fältanswers.<id>.noul | Typnumber |
Fältanswers.<id>.choice | Typstring |
Fältanswers.<id>.score | Typnumber |
Fältanswers.<id>.confidence | Typnumber |
Fältanswers.<id>.probabilities | Typobject |
Fältanswers.<id>.legend | Typobject |
Fältusage.input_tokens | Typinteger |
Fältusage.output_tokens | Typinteger |
Fältusage.cost | Typnumber |
| Svar | Villkor | Nästa steg |
|---|---|---|
Svar400 · invalid_request_error | VillkorOgiltigt obligatoriskt fält, ogiltig representation eller ogiltigt värde | Nästa stegKorrigera det angivna fältet i begäran. |
Ailoot Ultra cloudflare/clef
Använd metodsökvägarna som visas ovan.