Mercury Decide is Inception’s model for structured decisions over supplied evidence. It combines a shared state with named questions and returns typed answers with probabilities. The result can be a selected category, an estimated yes/no probability or a position on a defined scale. This profile serves a bounded decision that software can interpret; its documented interface does not generate a free-form chat answer.
The producer’s request contains a model, a state and a non-empty map of questions. The question names are preserved in the answer map. Supply the information needed to judge each question, and name the questions around the results the workflow uses, such as category, priority or needs_follow_up. Several questions evaluate the same evidence independently. Their placement in one request does not make a later question depend on an earlier answer.
Inception’s example uses a JSON object for the state. The guide also permits strings, objects or arrays in the state, instructions and criterion descriptions, with instructions optional or null. Preserve useful structure when the evidence already consists of fields, and keep a document or message identifiable when supplying text. For a support case, include the actual request and relevant facts instead of a request to infer missing context.
A noul question represents a yes/no condition. Its output is a probability from 0 to 1 that the positive answer applies. Optional true and false descriptions can specify what counts on each side of the question. For example, ask whether a message explicitly requests a replacement and distinguish that from a general complaint about the item. The probability supplies a numerical judgment; the application chooses the threshold and the resulting workflow action.
Keep the condition narrow enough that the evidence can settle it. If one question mixes whether the user wants help, whether an item is defective and whether the case is urgent, separate those conditions. Retain the returned probability with the question definition so a later reviewer can tell what the number actually measures.
A Choice question uses a map of one to 255 option names and descriptions; descriptions can be null. The returned choice is the highest-probability supplied option. The result also contains a probability for every option and confidence. Define distinct meanings for categories, and include a fallback category when some inputs will lie outside the specific options. Short output keys can identify categories while fuller descriptions establish the boundaries between them.
A routing brief might distinguish an access issue, a product question and a reported defect. State the meaning of each option and provide the message that needs routing. The output is a selected category with a distribution, not an instruction that has already changed a queue or contacted another system. Examine competing probabilities when a case is ambiguous rather than interpreting the winning label as proof of certainty.
A Score question uses an ordered array of one to ten level descriptions, starting at level 0. Its score is the probability-weighted average of the level indices and can fall between levels. The answer contains the legend, per-level probabilities and confidence. Define the order and the criteria for each level, such as no immediate impact, an issue with a workable alternative, and a fully blocked task.
A fractional expected score is useful for prioritization or aggregation. It is different from choosing the single most likely level. Keep the legend with the number so that a score is not interpreted on an unrelated scale. Confidence for Choice and Score is separately reported between 0 and 1; the relevant guide does not define it as identical to the largest option probability or supply a universal formula to reconstruct it.
One piece of evidence can support independent category, urgency and condition questions. A document-review task can ask whether a required topic is present, choose its category and rate its relevance on described levels. Use only source material available in the state, with criteria tied to the decision the workflow needs next. If an action requires an earlier result, make that result explicit in the evidence for the next step instead of assuming the questions form a hidden sequence.
The response returns the model name and an answers map keyed by the supplied question names. Choice probabilities use the option names; Score probabilities use string indices with the legend explaining those indices. Keep the state identifier, question definitions and typed answers associated. This produces an interpretable classification or rating artifact rather than a number detached from the facts that generated it.
Inception documents Mercury Decide through its dedicated decision interface. It does not support the maker’s chat-completion, streaming or tool-calling interfaces, so capabilities from Mercury’s reasoning, voice and code-generation profiles should not be transferred to this model. The decision guide specifies the option and level counts but gives no numerical state-token limit or question-count ceiling; keep shared evidence focused on the questions being evaluated.
Assess probabilities and category boundaries on representative labeled material from the intended task. Review borderline answers against the state and preserve missing information rather than replacing it with invented facts. A useful Mercury Decide result gives a closed decision, its probabilities and the definitions needed to understand it; the surrounding application determines how that result becomes routing, prioritization or a review outcome.
", "aboutText": "Mercury Decide is Inception’s model for structured decisions over supplied evidence. It combines a shared state with named questions and returns typed answers with probabilities. The result can be a selected category, an estimated yes/no probability or a position on a defined scale. This profile serves a bounded decision that software can interpret; its documented interface does not generate a free-form chat answer.\n\n### Shared state and meaningful question names\n\nThe producer’s request contains a model, a state and a non-empty map of questions. The question names are preserved in the answer map. Supply the information needed to judge each question, and name the questions around the results the workflow uses, such as category, priority or needs_follow_up. Several questions evaluate the same evidence independently. Their placement in one request does not make a later question depend on an earlier answer.\n\nInception’s example uses a JSON object for the state. The guide also permits strings, objects or arrays in the state, instructions and criterion descriptions, with instructions optional or null. Preserve useful structure when the evidence already consists of fields, and keep a document or message identifiable when supplying text. For a support case, include the actual request and relevant facts instead of a request to infer missing context.\n\n### Noul: an estimated positive answer\n\nA noul question represents a yes/no condition. Its output is a probability from 0 to 1 that the positive answer applies. Optional true and false descriptions can specify what counts on each side of the question. For example, ask whether a message explicitly requests a replacement and distinguish that from a general complaint about the item. The probability supplies a numerical judgment; the application chooses the threshold and the resulting workflow action.\n\nKeep the condition narrow enough that the evidence can settle it. If one question mixes whether the user wants help, whether an item is defective and whether the case is urgent, separate those conditions. Retain the returned probability with the question definition so a later reviewer can tell what the number actually measures.\n\n### Choice: selecting one named option\n\nA Choice question uses a map of one to 255 option names and descriptions; descriptions can be null. The returned choice is the highest-probability supplied option. The result also contains a probability for every option and confidence. Define distinct meanings for categories, and include a fallback category when some inputs will lie outside the specific options. Short output keys can identify categories while fuller descriptions establish the boundaries between them.\n\nA routing brief might distinguish an access issue, a product question and a reported defect. State the meaning of each option and provide the message that needs routing. The output is a selected category with a distribution, not an instruction that has already changed a queue or contacted another system. Examine competing probabilities when a case is ambiguous rather than interpreting the winning label as proof of certainty.\n\n### Score: an expected position on a rubric\n\nA Score question uses an ordered array of one to ten level descriptions, starting at level 0. Its score is the probability-weighted average of the level indices and can fall between levels. The answer contains the legend, per-level probabilities and confidence. Define the order and the criteria for each level, such as no immediate impact, an issue with a workable alternative, and a fully blocked task.\n\nA fractional expected score is useful for prioritization or aggregation. It is different from choosing the single most likely level. Keep the legend with the number so that a score is not interpreted on an unrelated scale. Confidence for Choice and Score is separately reported between 0 and 1; the relevant guide does not define it as identical to the largest option probability or supply a universal formula to reconstruct it.\n\n### Preparing a useful decision result\n\nOne piece of evidence can support independent category, urgency and condition questions. A document-review task can ask whether a required topic is present, choose its category and rate its relevance on described levels. Use only source material available in the state, with criteria tied to the decision the workflow needs next. If an action requires an earlier result, make that result explicit in the evidence for the next step instead of assuming the questions form a hidden sequence.\n\nThe response returns the model name and an answers map keyed by the supplied question names. Choice probabilities use the option names; Score probabilities use string indices with the legend explaining those indices. Keep the state identifier, question definitions and typed answers associated. This produces an interpretable classification or rating artifact rather than a number detached from the facts that generated it.\n\n### Interface scope and limits\n\nInception documents Mercury Decide through its dedicated decision interface. It does not support the maker’s chat-completion, streaming or tool-calling interfaces, so capabilities from Mercury’s reasoning, voice and code-generation profiles should not be transferred to this model. The decision guide specifies the option and level counts but gives no numerical state-token limit or question-count ceiling; keep shared evidence focused on the questions being evaluated.\n\nAssess probabilities and category boundaries on representative labeled material from the intended task. Review borderline answers against the state and preserve missing information rather than replacing it with invented facts. A useful Mercury Decide result gives a closed decision, its probabilities and the definitions needed to understand it; the surrounding application determines how that result becomes routing, prioritization or a review outcome.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "3ac8a5167d52ea97aa0b947a16fefdac80a273f5a492f5efd9548f80047aae5f", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "inception/mercury-decide:freeMercury Decide evaluates shared text or JSON evidence against named questions and returns typed choices, yes/no probabilities or fractional rubric scores. Inception documents a dedicated decision workflow with up to 255 Choice options and ten Score levels.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mercury Decide is Inception’s model for structured decisions over supplied evidence. It combines a shared state with named questions and returns typed answers with probabilities. The result can be a selected category, an estimated yes/no probability or a position on a defined scale. This profile serves a bounded decision that software can interpret; its documented interface does not generate a free-form chat answer.
The producer’s request contains a model, a state and a non-empty map of questions. The question names are preserved in the answer map. Supply the information needed to judge each question, and name the questions around the results the workflow uses, such as category, priority or needs_follow_up. Several questions evaluate the same evidence independently. Their placement in one request does not make a later question depend on an earlier answer.
Inception’s example uses a JSON object for the state. The guide also permits strings, objects or arrays in the state, instructions and criterion descriptions, with instructions optional or null. Preserve useful structure when the evidence already consists of fields, and keep a document or message identifiable when supplying text. For a support case, include the actual request and relevant facts instead of a request to infer missing context.
A noul question represents a yes/no condition. Its output is a probability from 0 to 1 that the positive answer applies. Optional true and false descriptions can specify what counts on each side of the question. For example, ask whether a message explicitly requests a replacement and distinguish that from a general complaint about the item. The probability supplies a numerical judgment; the application chooses the threshold and the resulting workflow action.
Keep the condition narrow enough that the evidence can settle it. If one question mixes whether the user wants help, whether an item is defective and whether the case is urgent, separate those conditions. Retain the returned probability with the question definition so a later reviewer can tell what the number actually measures.
A Choice question uses a map of one to 255 option names and descriptions; descriptions can be null. The returned choice is the highest-probability supplied option. The result also contains a probability for every option and confidence. Define distinct meanings for categories, and include a fallback category when some inputs will lie outside the specific options. Short output keys can identify categories while fuller descriptions establish the boundaries between them.
A routing brief might distinguish an access issue, a product question and a reported defect. State the meaning of each option and provide the message that needs routing. The output is a selected category with a distribution, not an instruction that has already changed a queue or contacted another system. Examine competing probabilities when a case is ambiguous rather than interpreting the winning label as proof of certainty.
A Score question uses an ordered array of one to ten level descriptions, starting at level 0. Its score is the probability-weighted average of the level indices and can fall between levels. The answer contains the legend, per-level probabilities and confidence. Define the order and the criteria for each level, such as no immediate impact, an issue with a workable alternative, and a fully blocked task.
A fractional expected score is useful for prioritization or aggregation. It is different from choosing the single most likely level. Keep the legend with the number so that a score is not interpreted on an unrelated scale. Confidence for Choice and Score is separately reported between 0 and 1; the relevant guide does not define it as identical to the largest option probability or supply a universal formula to reconstruct it.
One piece of evidence can support independent category, urgency and condition questions. A document-review task can ask whether a required topic is present, choose its category and rate its relevance on described levels. Use only source material available in the state, with criteria tied to the decision the workflow needs next. If an action requires an earlier result, make that result explicit in the evidence for the next step instead of assuming the questions form a hidden sequence.
The response returns the model name and an answers map keyed by the supplied question names. Choice probabilities use the option names; Score probabilities use string indices with the legend explaining those indices. Keep the state identifier, question definitions and typed answers associated. This produces an interpretable classification or rating artifact rather than a number detached from the facts that generated it.
Inception documents Mercury Decide through its dedicated decision interface. It does not support the maker’s chat-completion, streaming or tool-calling interfaces, so capabilities from Mercury’s reasoning, voice and code-generation profiles should not be transferred to this model. The decision guide specifies the option and level counts but gives no numerical state-token limit or question-count ceiling; keep shared evidence focused on the questions being evaluated.
Assess probabilities and category boundaries on representative labeled material from the intended task. Review borderline answers against the state and preserve missing information rather than replacing it with invented facts. A useful Mercury Decide result gives a closed decision, its probabilities and the definitions needed to understand it; the surrounding application determines how that result becomes routing, prioritization or a review outcome.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits inception/mercury-decide:free | 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 / 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 / 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": "inception/mercury-decide:free",\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']='inception/mercury-decide:free'\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 inception/mercury-decide:free
Use the method paths shown above.