Drex 1.5 is Nace.AI’s text decision model. It evaluates supplied facts against closed questions and returns numerical, typed answers rather than an open-ended written response. A request combines one state with named questions, and the result identifies each answer using the same question name. This gives a workflow a concrete category, probability or rubric position to consume while leaving the action taken on that result to the application.
The state is the information every question concerns. Drex accepts a JSON string, object, array, number, boolean or null, with the state field required. Supply meaningful evidence even though null passes the producer’s validation. A string suits a message, document or transcript; an object suits facts already organized into fields. Retain the information that affects the decision, and omit unrelated fields when the material is long. Keep a stable input format when interpreting probability thresholds, because changing the representation can change the answer.
Drex 1.5 reads text only. The documented interface rejects images, audio, video and PDF content within either the state or questions, including encoded media and media-content objects. Prepare a caption, recognized document text or a transcript before using that material as evidence. A text address is not a fetched document or image: the model cannot open it. For a support request, the useful state is the actual message and relevant context, not a reference to material the model has not received.
A noul question asks whether a condition holds and returns a number from 0 to 1 representing the estimated probability of yes. Define the question through non-empty instructions or at least one non-empty true/false criterion. For example, ask whether a message reports a broken feature and define whether slow behavior counts as broken. Drex does not impose a built-in yes/no cutoff; the consuming workflow chooses how to interpret the probability.
A choice question selects one supplied label from an unordered set and returns a probability for every label. The criteria are an object whose keys are the returned labels, with each description a string or null. Use short, stable keys and describe category boundaries clearly. An illustrative routing task can distinguish an access problem, a product defect and a general question, with an other category for messages that do not fit. The selected label is useful for routing; the distribution helps identify cases where two options remain difficult to separate.
A score question uses an ordered array of level labels. Indices begin at 0, and the returned score is the sum of each level index multiplied by its probability. It can therefore fall between named levels. For a severity scale, define what separates a cosmetic issue, an issue with a workaround and a fully blocked task. The result includes the level legend and probabilities as well as the expected score. Keep the fractional score for averaging or trends; selecting the most probable level and rounding the expected score answer different questions.
The producer allows one to 512 questions about the same state. Give each a non-empty, meaningful identifier, such as category or severity, so the corresponding answer can be understood without looking up a numbered question. Separate independent concerns into their own questions rather than combining several requirements into one unclear criterion. A single message can support a category choice, a severity score and a condition check, each retaining its own meaning.
Choice and score answers include confidence separately from their probability distributions. The producer explicitly distinguishes confidence from the highest option probability; do not calculate one from the other. For a yes/no decision, retain the raw probability with the chosen outcome. For an uncertain choice, inspect the competing probabilities instead of treating the winning label alone as evidence of certainty. Define review thresholds around the consequences of a wrong positive or negative result and use representative labeled cases to assess them.
Drex 1.5 documents a state allowance of 131,072 tokens and a row allowance of 139,264 tokens. The row allowance concerns the state plus the longest single question, including its instructions and options; it is not the sum of every question in the request. The serialized state and questions together must also fit within 1,048,576 UTF-8 bytes. A request can satisfy the byte limit and still exceed a token limit. The older 1.0 edition separately lists 32,768 tokens for both state and row, so its limits should not be carried over to 1.5.
Nace documents drex-v1.5 as a versioned producer identifier, while drex-latest is a moving alias. Keep the intended edition explicit when a workflow depends on its limits. A malformed question, missing state or oversized input is a validation problem that needs corrected input rather than a changed category or guessed answer. Prepare the criteria around observable evidence and retain the typed result, the original facts and the question definition together. That makes the decision usable for routing, prioritization or review without mistaking a probability for a guaranteed verdict.
", "aboutText": "Drex 1.5 is Nace.AI’s text decision model. It evaluates supplied facts against closed questions and returns numerical, typed answers rather than an open-ended written response. A request combines one state with named questions, and the result identifies each answer using the same question name. This gives a workflow a concrete category, probability or rubric position to consume while leaving the action taken on that result to the application.\n\n### Preparing the state\n\nThe state is the information every question concerns. Drex accepts a JSON string, object, array, number, boolean or null, with the state field required. Supply meaningful evidence even though null passes the producer’s validation. A string suits a message, document or transcript; an object suits facts already organized into fields. Retain the information that affects the decision, and omit unrelated fields when the material is long. Keep a stable input format when interpreting probability thresholds, because changing the representation can change the answer.\n\nDrex 1.5 reads text only. The documented interface rejects images, audio, video and PDF content within either the state or questions, including encoded media and media-content objects. Prepare a caption, recognized document text or a transcript before using that material as evidence. A text address is not a fetched document or image: the model cannot open it. For a support request, the useful state is the actual message and relevant context, not a reference to material the model has not received.\n\n### Yes/no probability, choice or score\n\nA noul question asks whether a condition holds and returns a number from 0 to 1 representing the estimated probability of yes. Define the question through non-empty instructions or at least one non-empty true/false criterion. For example, ask whether a message reports a broken feature and define whether slow behavior counts as broken. Drex does not impose a built-in yes/no cutoff; the consuming workflow chooses how to interpret the probability.\n\nA choice question selects one supplied label from an unordered set and returns a probability for every label. The criteria are an object whose keys are the returned labels, with each description a string or null. Use short, stable keys and describe category boundaries clearly. An illustrative routing task can distinguish an access problem, a product defect and a general question, with an other category for messages that do not fit. The selected label is useful for routing; the distribution helps identify cases where two options remain difficult to separate.\n\nA score question uses an ordered array of level labels. Indices begin at 0, and the returned score is the sum of each level index multiplied by its probability. It can therefore fall between named levels. For a severity scale, define what separates a cosmetic issue, an issue with a workaround and a fully blocked task. The result includes the level legend and probabilities as well as the expected score. Keep the fractional score for averaging or trends; selecting the most probable level and rounding the expected score answer different questions.\n\n### Shared evidence and reading the result\n\nThe producer allows one to 512 questions about the same state. Give each a non-empty, meaningful identifier, such as category or severity, so the corresponding answer can be understood without looking up a numbered question. Separate independent concerns into their own questions rather than combining several requirements into one unclear criterion. A single message can support a category choice, a severity score and a condition check, each retaining its own meaning.\n\nChoice and score answers include confidence separately from their probability distributions. The producer explicitly distinguishes confidence from the highest option probability; do not calculate one from the other. For a yes/no decision, retain the raw probability with the chosen outcome. For an uncertain choice, inspect the competing probabilities instead of treating the winning label alone as evidence of certainty. Define review thresholds around the consequences of a wrong positive or negative result and use representative labeled cases to assess them.\n\n### Version and size limits\n\nDrex 1.5 documents a state allowance of 131,072 tokens and a row allowance of 139,264 tokens. The row allowance concerns the state plus the longest single question, including its instructions and options; it is not the sum of every question in the request. The serialized state and questions together must also fit within 1,048,576 UTF-8 bytes. A request can satisfy the byte limit and still exceed a token limit. The older 1.0 edition separately lists 32,768 tokens for both state and row, so its limits should not be carried over to 1.5.\n\nNace documents drex-v1.5 as a versioned producer identifier, while drex-latest is a moving alias. Keep the intended edition explicit when a workflow depends on its limits. A malformed question, missing state or oversized input is a validation problem that needs corrected input rather than a changed category or guessed answer. Prepare the criteria around observable evidence and retain the typed result, the original facts and the question definition together. That makes the decision usable for routing, prioritization or review without mistaking a probability for a guaranteed verdict.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "c7702beb64179a2e4d09ac048e69e231e80d511ab80a4d44bf84f71aa5516b87", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 evaluates supplied text or JSON against typed questions and returns probabilities, a chosen label or a fractional rubric score. Nace.AI documents text-only decisions for classification, routing and prioritization, with version-specific state and request limits.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Drex 1.5 is Nace.AI’s text decision model. It evaluates supplied facts against closed questions and returns numerical, typed answers rather than an open-ended written response. A request combines one state with named questions, and the result identifies each answer using the same question name. This gives a workflow a concrete category, probability or rubric position to consume while leaving the action taken on that result to the application.
The state is the information every question concerns. Drex accepts a JSON string, object, array, number, boolean or null, with the state field required. Supply meaningful evidence even though null passes the producer’s validation. A string suits a message, document or transcript; an object suits facts already organized into fields. Retain the information that affects the decision, and omit unrelated fields when the material is long. Keep a stable input format when interpreting probability thresholds, because changing the representation can change the answer.
Drex 1.5 reads text only. The documented interface rejects images, audio, video and PDF content within either the state or questions, including encoded media and media-content objects. Prepare a caption, recognized document text or a transcript before using that material as evidence. A text address is not a fetched document or image: the model cannot open it. For a support request, the useful state is the actual message and relevant context, not a reference to material the model has not received.
A noul question asks whether a condition holds and returns a number from 0 to 1 representing the estimated probability of yes. Define the question through non-empty instructions or at least one non-empty true/false criterion. For example, ask whether a message reports a broken feature and define whether slow behavior counts as broken. Drex does not impose a built-in yes/no cutoff; the consuming workflow chooses how to interpret the probability.
A choice question selects one supplied label from an unordered set and returns a probability for every label. The criteria are an object whose keys are the returned labels, with each description a string or null. Use short, stable keys and describe category boundaries clearly. An illustrative routing task can distinguish an access problem, a product defect and a general question, with an other category for messages that do not fit. The selected label is useful for routing; the distribution helps identify cases where two options remain difficult to separate.
A score question uses an ordered array of level labels. Indices begin at 0, and the returned score is the sum of each level index multiplied by its probability. It can therefore fall between named levels. For a severity scale, define what separates a cosmetic issue, an issue with a workaround and a fully blocked task. The result includes the level legend and probabilities as well as the expected score. Keep the fractional score for averaging or trends; selecting the most probable level and rounding the expected score answer different questions.
The producer allows one to 512 questions about the same state. Give each a non-empty, meaningful identifier, such as category or severity, so the corresponding answer can be understood without looking up a numbered question. Separate independent concerns into their own questions rather than combining several requirements into one unclear criterion. A single message can support a category choice, a severity score and a condition check, each retaining its own meaning.
Choice and score answers include confidence separately from their probability distributions. The producer explicitly distinguishes confidence from the highest option probability; do not calculate one from the other. For a yes/no decision, retain the raw probability with the chosen outcome. For an uncertain choice, inspect the competing probabilities instead of treating the winning label alone as evidence of certainty. Define review thresholds around the consequences of a wrong positive or negative result and use representative labeled cases to assess them.
Drex 1.5 documents a state allowance of 131,072 tokens and a row allowance of 139,264 tokens. The row allowance concerns the state plus the longest single question, including its instructions and options; it is not the sum of every question in the request. The serialized state and questions together must also fit within 1,048,576 UTF-8 bytes. A request can satisfy the byte limit and still exceed a token limit. The older 1.0 edition separately lists 32,768 tokens for both state and row, so its limits should not be carried over to 1.5.
Nace documents drex-v1.5 as a versioned producer identifier, while drex-latest is a moving alias. Keep the intended edition explicit when a workflow depends on its limits. A malformed question, missing state or oversized input is a validation problem that needs corrected input rather than a changed category or guessed answer. Prepare the criteria around observable evidence and retain the typed result, the original facts and the question definition together. That makes the decision usable for routing, prioritization or review without mistaking a probability for a guaranteed verdict.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits nace-ai/drex-v1.5 | 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.00008 / 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.00008 / 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": "nace-ai/drex-v1.5",\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']='nace-ai/drex-v1.5'\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 nace-ai/drex-v1.5
Use the method paths shown above.