Kev-4B is a compact decision model for answering typed questions about a supplied state. The state is the document or record being assessed, and each question defines the options the model can score. Its result is a probability distribution and a typed decision record, making it useful for document classification, routing, triage, extraction choices and checks against stated criteria.
The model combines a frozen Qwen3.5-4B-Base backbone with a LoRA adapter and a pointer head. The backbone has 32 layers, comprising 24 Gated DeltaNet layers and eight full-attention layers. The adapter targets attention, MLP and DeltaNet projections; the pointer head scores the supplied options and converts those scores into probabilities. This is a prefill-only decision workflow, with the options forming the answer space.
Three question types can appear in the same request. A choice question accepts 1–255 named options, optionally with descriptions, and returns the most likely option, a separate confidence value and probabilities for the options. A yes/no question, called noul in the maker’s format, returns the probability of yes. Define the meaning of yes in the question rather than assuming that a high number always means a positive outcome for the application.
An ordered-score question accepts 1–255 levels and returns probabilities for the levels and their expected index. Level indices start at zero. The maker’s result format also carries the level legend and a separate confidence value. An expected index can be fractional: it summarises the distribution over your ordered levels rather than selecting a new textual label. Keep the level order and legend with the result so a rating can be interpreted consistently.
Questions share the same state but are evaluated independently. One question cannot read another question’s answer, and the state is computed once and reused. If a later decision depends on a result from an earlier decision, make that dependency explicit in a subsequent state instead of expecting the questions in one request to form a chain. This makes the shared-state workflow suitable for several independent checks on the same document.
Prepare the state with the evidence the questions actually require. It can be plain text or a JSON object or array rendered as labelled text. Keep field names, units, policy conditions and the relevant source passages clear. Write a specific instruction for each question and give its options meanings that can be distinguished from the record. For an original support-routing task, the state can contain the request and its context, while the choices define delivery, access and product-support categories with short descriptions.
A second question can assess urgency, and an ordered question can rate how much follow-up the request needs. These answer different operational questions, so define each separately. Include an appropriate review or missing-evidence option when the choice task needs one, and retain the full distribution when several categories are plausible. The application decides how to route or review a result; the model supplies the scored record.
Kev-4B is intended for typed decisions over documents of a few thousand tokens. Its maker’s serving profile accepts states up to 65,536 tokens and reserves additional space for each question, while the validated context length for this checkpoint is 8192 tokens. Those are different boundaries: accepting a longer state does not establish equally reliable decisions at every length. Keep decisive passages compact and preserve their labels when preparing a long record for classification.
The released profile is English. Its useful tasks depend on evidence in the supplied state and on the defined options, rather than open-ended chat, summarisation or broad knowledge-based answering. Day-level date arithmetic is a particular limitation: the maker provides a separate date-facts preprocessor that supplies computed intervals. For a deadline check, include the relevant dates and computed day intervals in the state, along with the rule that uses them.
The checkpoint ships with fitted probability calibration, but confidence can change with the document domain and question design. The maker also documents fine-tuning the open checkpoint on task-specific labels and fitting its probability calibration to that workload; this is a separate customization workflow from scoring a supplied state. Choose decision thresholds using labelled examples of the actual workload, and keep uncertain cases visible for review. The maker excludes fully automated consequential decisions about people without human review. Option order can also affect an answer, so retain a stable ordering when comparing results. Assess the chosen label, the separate confidence field and the probability distribution according to the role each plays in your workflow.
The current Kev-4B release described by the maker belongs to Kev 1.0 and uses the Qwen3.5 base. Earlier Qwen3-based and document-stage-only releases remain distinct versions. Keep the chosen edition and question definitions associated with the outputs when developing a task-specific workflow, rather than mixing results from different profiles.
A useful final artifact is a named set of decision records with the original questions, option definitions, distributions and any ordered-level legends. For an answer-quality check, the state should include the proposed answer, the evidence and the criterion being tested. For policy triage, it should include the applicable rule and relevant facts. Preserve that input beside the result so a review can establish why a decision was appropriate or which missing fact needs to be supplied.
", "aboutText": "Kev-4B is a compact decision model for answering typed questions about a supplied state. The state is the document or record being assessed, and each question defines the options the model can score. Its result is a probability distribution and a typed decision record, making it useful for document classification, routing, triage, extraction choices and checks against stated criteria.\n\nThe model combines a frozen Qwen3.5-4B-Base backbone with a LoRA adapter and a pointer head. The backbone has 32 layers, comprising 24 Gated DeltaNet layers and eight full-attention layers. The adapter targets attention, MLP and DeltaNet projections; the pointer head scores the supplied options and converts those scores into probabilities. This is a prefill-only decision workflow, with the options forming the answer space.\n\nThree question types can appear in the same request. A choice question accepts 1–255 named options, optionally with descriptions, and returns the most likely option, a separate confidence value and probabilities for the options. A yes/no question, called noul in the maker’s format, returns the probability of yes. Define the meaning of yes in the question rather than assuming that a high number always means a positive outcome for the application.\n\nAn ordered-score question accepts 1–255 levels and returns probabilities for the levels and their expected index. Level indices start at zero. The maker’s result format also carries the level legend and a separate confidence value. An expected index can be fractional: it summarises the distribution over your ordered levels rather than selecting a new textual label. Keep the level order and legend with the result so a rating can be interpreted consistently.\n\nQuestions share the same state but are evaluated independently. One question cannot read another question’s answer, and the state is computed once and reused. If a later decision depends on a result from an earlier decision, make that dependency explicit in a subsequent state instead of expecting the questions in one request to form a chain. This makes the shared-state workflow suitable for several independent checks on the same document.\n\nPrepare the state with the evidence the questions actually require. It can be plain text or a JSON object or array rendered as labelled text. Keep field names, units, policy conditions and the relevant source passages clear. Write a specific instruction for each question and give its options meanings that can be distinguished from the record. For an original support-routing task, the state can contain the request and its context, while the choices define delivery, access and product-support categories with short descriptions.\n\nA second question can assess urgency, and an ordered question can rate how much follow-up the request needs. These answer different operational questions, so define each separately. Include an appropriate review or missing-evidence option when the choice task needs one, and retain the full distribution when several categories are plausible. The application decides how to route or review a result; the model supplies the scored record.\n\nKev-4B is intended for typed decisions over documents of a few thousand tokens. Its maker’s serving profile accepts states up to 65,536 tokens and reserves additional space for each question, while the validated context length for this checkpoint is 8192 tokens. Those are different boundaries: accepting a longer state does not establish equally reliable decisions at every length. Keep decisive passages compact and preserve their labels when preparing a long record for classification.\n\nThe released profile is English. Its useful tasks depend on evidence in the supplied state and on the defined options, rather than open-ended chat, summarisation or broad knowledge-based answering. Day-level date arithmetic is a particular limitation: the maker provides a separate date-facts preprocessor that supplies computed intervals. For a deadline check, include the relevant dates and computed day intervals in the state, along with the rule that uses them.\n\nThe checkpoint ships with fitted probability calibration, but confidence can change with the document domain and question design. The maker also documents fine-tuning the open checkpoint on task-specific labels and fitting its probability calibration to that workload; this is a separate customization workflow from scoring a supplied state. Choose decision thresholds using labelled examples of the actual workload, and keep uncertain cases visible for review. The maker excludes fully automated consequential decisions about people without human review. Option order can also affect an answer, so retain a stable ordering when comparing results. Assess the chosen label, the separate confidence field and the probability distribution according to the role each plays in your workflow.\n\nThe current Kev-4B release described by the maker belongs to Kev 1.0 and uses the Qwen3.5 base. Earlier Qwen3-based and document-stage-only releases remain distinct versions. Keep the chosen edition and question definitions associated with the outputs when developing a task-specific workflow, rather than mixing results from different profiles.\n\nA useful final artifact is a named set of decision records with the original questions, option definitions, distributions and any ordered-level legends. For an answer-quality check, the state should include the proposed answer, the evidence and the criterion being tested. For policy triage, it should include the applicable rule and relevant facts. Preserve that input beside the result so a review can establish why a decision was appropriate or which missing fact needs to be supplied.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "77016d3c712af33106512696721c3465b7a7f3cb46c2edfa4b58cb775bbb0901", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B scores typed questions about a supplied English document and returns calibrated probabilities over the options you define. Use yes/no, choice and ordered-score questions for classification, routing, triage and checks that need a structured decision rather than generated prose.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Kev-4B is a compact decision model for answering typed questions about a supplied state. The state is the document or record being assessed, and each question defines the options the model can score. Its result is a probability distribution and a typed decision record, making it useful for document classification, routing, triage, extraction choices and checks against stated criteria.
The model combines a frozen Qwen3.5-4B-Base backbone with a LoRA adapter and a pointer head. The backbone has 32 layers, comprising 24 Gated DeltaNet layers and eight full-attention layers. The adapter targets attention, MLP and DeltaNet projections; the pointer head scores the supplied options and converts those scores into probabilities. This is a prefill-only decision workflow, with the options forming the answer space.
Three question types can appear in the same request. A choice question accepts 1–255 named options, optionally with descriptions, and returns the most likely option, a separate confidence value and probabilities for the options. A yes/no question, called noul in the maker’s format, returns the probability of yes. Define the meaning of yes in the question rather than assuming that a high number always means a positive outcome for the application.
An ordered-score question accepts 1–255 levels and returns probabilities for the levels and their expected index. Level indices start at zero. The maker’s result format also carries the level legend and a separate confidence value. An expected index can be fractional: it summarises the distribution over your ordered levels rather than selecting a new textual label. Keep the level order and legend with the result so a rating can be interpreted consistently.
Questions share the same state but are evaluated independently. One question cannot read another question’s answer, and the state is computed once and reused. If a later decision depends on a result from an earlier decision, make that dependency explicit in a subsequent state instead of expecting the questions in one request to form a chain. This makes the shared-state workflow suitable for several independent checks on the same document.
Prepare the state with the evidence the questions actually require. It can be plain text or a JSON object or array rendered as labelled text. Keep field names, units, policy conditions and the relevant source passages clear. Write a specific instruction for each question and give its options meanings that can be distinguished from the record. For an original support-routing task, the state can contain the request and its context, while the choices define delivery, access and product-support categories with short descriptions.
A second question can assess urgency, and an ordered question can rate how much follow-up the request needs. These answer different operational questions, so define each separately. Include an appropriate review or missing-evidence option when the choice task needs one, and retain the full distribution when several categories are plausible. The application decides how to route or review a result; the model supplies the scored record.
Kev-4B is intended for typed decisions over documents of a few thousand tokens. Its maker’s serving profile accepts states up to 65,536 tokens and reserves additional space for each question, while the validated context length for this checkpoint is 8192 tokens. Those are different boundaries: accepting a longer state does not establish equally reliable decisions at every length. Keep decisive passages compact and preserve their labels when preparing a long record for classification.
The released profile is English. Its useful tasks depend on evidence in the supplied state and on the defined options, rather than open-ended chat, summarisation or broad knowledge-based answering. Day-level date arithmetic is a particular limitation: the maker provides a separate date-facts preprocessor that supplies computed intervals. For a deadline check, include the relevant dates and computed day intervals in the state, along with the rule that uses them.
The checkpoint ships with fitted probability calibration, but confidence can change with the document domain and question design. The maker also documents fine-tuning the open checkpoint on task-specific labels and fitting its probability calibration to that workload; this is a separate customization workflow from scoring a supplied state. Choose decision thresholds using labelled examples of the actual workload, and keep uncertain cases visible for review. The maker excludes fully automated consequential decisions about people without human review. Option order can also affect an answer, so retain a stable ordering when comparing results. Assess the chosen label, the separate confidence field and the probability distribution according to the role each plays in your workflow.
The current Kev-4B release described by the maker belongs to Kev 1.0 and uses the Qwen3.5 base. Earlier Qwen3-based and document-stage-only releases remain distinct versions. Keep the chosen edition and question definitions associated with the outputs when developing a task-specific workflow, rather than mixing results from different profiles.
A useful final artifact is a named set of decision records with the original questions, option definitions, distributions and any ordered-level legends. For an answer-quality check, the state should include the proposed answer, the evidence and the criterion being tested. For policy triage, it should include the applicable rule and relevant facts. Preserve that input beside the result so a review can establish why a decision was appropriate or which missing fact needs to be supplied.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits jaredpalmer/kev-4b | Default— |
Fieldprovider | Typeschema | RequirementOptional | Values & limits | Default— |
Fieldquestions | Typeobject | RequirementRequired | Values & limits | Default— |
Fieldsession_id | Typestring | RequirementOptional | Values & limits | Default— |
Fieldstate | Typeschema | RequirementRequired | Values & limits | Default— |
Fieldtrace | Typeschema | RequirementOptional | Values & limits | Default— |
Fielduser | Typestring | RequirementOptional | Values & limits | Default— |
Fieldquestions.<id>.type | Typestring | RequirementRequired | Values & limits noul, choice, score | Default— |
Fieldquestions.<id>.instructions | Typestring|object|array | RequirementRequired | Values & limits | Default— |
Fieldquestions.<id>.criteria | Typeobject|array | RequirementOptional | Values & limits Conditions: choice/score: required; noul: optional. choice criteria is object; score is array with minItems1. | Default— |
Fieldquestions.<id>.criteria.true | Typestring|object|array | RequirementRequired | Values & limits Applies when: noul criteria object supplied | Default— |
Fieldquestions.<id>.criteria.false | Typestring|object|array | RequirementRequired | Values & limits Applies when: noul criteria object supplied | Default— |
noul · Required: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Required: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Required: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, state, questions |
Parametermaterial_types | Contracttext |
Parameteroptional_controls | Contractprovider, session_id, trace, user |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous
Send the exact model ID and retain the complete native response.
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.000084 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.000084 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
{\n "model": "jaredpalmer/kev-4b",\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']='jaredpalmer/kev-4b'\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
Keep every complete returned response, file and content part.
Every supplied question-ID answer with its exact type, noul/choice/score value, confidence, probabilities and legend is retained. Entire original JSON is stored and returned only after settlement.
Preserve original operation and full/partial reply; do not replay POST.
| Field | Type |
|---|---|
Fieldmodel | Typestring |
Fieldid | Typestring |
Fieldprovider | Typestring |
Fieldanswers.<id>.type | Typestring |
Fieldanswers.<id>.noul | Typenumber |
Fieldanswers.<id>.choice | Typestring |
Fieldanswers.<id>.score | Typenumber |
Fieldanswers.<id>.confidence | Typenumber |
Fieldanswers.<id>.probabilities | Typeobject |
Fieldanswers.<id>.legend | Typeobject |
Fieldusage.input_tokens | Typeinteger |
Fieldusage.output_tokens | Typeinteger |
Fieldusage.cost | Typenumber |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required field, representation or value | Next stepCorrect the indicated request field. |
Ailoot Ultra jaredpalmer/kev-4b
Use the method paths shown above.