Upstage Solar Decide is a structured decision model built on Solar Mini 4. It reads a supplied state and typed questions, then returns a decision for each question with calibrated probability information. The manufacturer describes a single-forward-pass decision process that generates no prose. Its intended applications include routing, classification and policy checks, with the model’s Korean understanding highlighted as part of its Solar Mini 4 foundation.
Prepare the state as a string or structured JSON describing the facts to assess. The maker’s interface serializes JSON values into the prompt. A question schema separately defines what to decide, which options are allowed and how an ordered assessment should be interpreted. Use stable names for the questions: their answers return under the same names, making the result easy to associate with the original workflow condition. Keep the factual state distinct from the instructions and criteria that define the decision.
The three question types have different outputs. A choice question returns the selected option, probabilities across the named alternatives and a confidence value. A noul question returns the probability of true for a yes/no condition. A score question returns a probability-weighted score, an indexed legend, probabilities and confidence. An ordered score can be fractional because it reflects the distribution across criteria. Preserve these fields rather than collapsing every result into a bare label or treating confidence as an explanatory sentence.
For support routing, supply the actual message and relevant history, then ask separate questions for intent, urgency and a defined condition such as whether the message expresses dissatisfaction. Describe categories by their meaning and give the urgency scale a deliberate order. An example schema can distinguish a delivery-status request, an account-access problem and an unrelated issue, while the urgency criteria run from no immediate action to immediate review. The observable result is a typed assessment of those choices, not a drafted reply to the customer.
For policy checks, include the relevant rule and the record facts together in the state. Define each condition narrowly enough that its answer can be inspected. A document workflow might ask whether required information is present, which review category applies and how strongly the record meets an ordered completeness standard. A score or probability does not independently verify the facts in the record. If decisive information is missing, the application needs a deliberate treatment of that uncertainty instead of interpreting a selected option as conclusive proof.
The manufacturer specifies a 512K-token context window for Solar Decide. Prepare large documents as the text or structured state the decision requires; a large context does not imply automatic parsing of an arbitrary file. Preserve source boundaries and the passages relevant to the criteria. Use focused questions rather than expecting an open-ended summary of the document. The model’s output remains bounded by the question types and options, regardless of how much material is included in the state.
A choice question accepts two to 26 options in the documented producer interface. The maker explains that this route reads decisions from single-token labels A through Z, so more than 26 candidates must be narrowed or split into several questions. This limit applies to choice options, rather than being a general limit on document length or a limit copied from another decision-model family. Define candidate descriptions so their meanings are distinct, and use a hierarchical decision only when that hierarchy matches the actual workflow.
For Korean-language records, keep the source meaning, names and identifiers intact and describe the decision criteria clearly. The typed result can use stable application labels while assessing natural-language evidence. When a record mixes languages or uses domain terminology, retain the relevant definitions in the state. A fluent interpretation of a term is not enough to establish that the classification criteria match the business rule, so inspect representative ambiguous cases as well as straightforward ones.
Use the returned probabilities and confidence according to the workflow’s decision policy. Preserve the distribution and ordered legend when an assessment lies between categories. Set the treatment of uncertain results from reviewed task examples, rather than inventing a universal probability threshold. The application performs any resulting routing, escalation or review action and records its outcome. Solar Decide supplies the bounded model assessment used to consider that action; selecting a route does not establish that a later action was executed.
The useful final artifact is the answers object together with the state and question definitions that produced it. These records make it possible to inspect a surprising classification, distinguish missing evidence from ambiguous criteria and compare the assessment with a reviewed case. If a user needs a written explanation or a conversational response, the decision and source material can feed a separate writing step. Solar Decide’s specific role is producing typed probability-backed decisions from supplied text, rather than generating that explanation itself.
", "aboutText": "Upstage Solar Decide is a structured decision model built on Solar Mini 4. It reads a supplied state and typed questions, then returns a decision for each question with calibrated probability information. The manufacturer describes a single-forward-pass decision process that generates no prose. Its intended applications include routing, classification and policy checks, with the model’s Korean understanding highlighted as part of its Solar Mini 4 foundation.\n\nPrepare the state as a string or structured JSON describing the facts to assess. The maker’s interface serializes JSON values into the prompt. A question schema separately defines what to decide, which options are allowed and how an ordered assessment should be interpreted. Use stable names for the questions: their answers return under the same names, making the result easy to associate with the original workflow condition. Keep the factual state distinct from the instructions and criteria that define the decision.\n\nThe three question types have different outputs. A choice question returns the selected option, probabilities across the named alternatives and a confidence value. A noul question returns the probability of true for a yes/no condition. A score question returns a probability-weighted score, an indexed legend, probabilities and confidence. An ordered score can be fractional because it reflects the distribution across criteria. Preserve these fields rather than collapsing every result into a bare label or treating confidence as an explanatory sentence.\n\nFor support routing, supply the actual message and relevant history, then ask separate questions for intent, urgency and a defined condition such as whether the message expresses dissatisfaction. Describe categories by their meaning and give the urgency scale a deliberate order. An example schema can distinguish a delivery-status request, an account-access problem and an unrelated issue, while the urgency criteria run from no immediate action to immediate review. The observable result is a typed assessment of those choices, not a drafted reply to the customer.\n\nFor policy checks, include the relevant rule and the record facts together in the state. Define each condition narrowly enough that its answer can be inspected. A document workflow might ask whether required information is present, which review category applies and how strongly the record meets an ordered completeness standard. A score or probability does not independently verify the facts in the record. If decisive information is missing, the application needs a deliberate treatment of that uncertainty instead of interpreting a selected option as conclusive proof.\n\nThe manufacturer specifies a 512K-token context window for Solar Decide. Prepare large documents as the text or structured state the decision requires; a large context does not imply automatic parsing of an arbitrary file. Preserve source boundaries and the passages relevant to the criteria. Use focused questions rather than expecting an open-ended summary of the document. The model’s output remains bounded by the question types and options, regardless of how much material is included in the state.\n\nA choice question accepts two to 26 options in the documented producer interface. The maker explains that this route reads decisions from single-token labels A through Z, so more than 26 candidates must be narrowed or split into several questions. This limit applies to choice options, rather than being a general limit on document length or a limit copied from another decision-model family. Define candidate descriptions so their meanings are distinct, and use a hierarchical decision only when that hierarchy matches the actual workflow.\n\nFor Korean-language records, keep the source meaning, names and identifiers intact and describe the decision criteria clearly. The typed result can use stable application labels while assessing natural-language evidence. When a record mixes languages or uses domain terminology, retain the relevant definitions in the state. A fluent interpretation of a term is not enough to establish that the classification criteria match the business rule, so inspect representative ambiguous cases as well as straightforward ones.\n\nUse the returned probabilities and confidence according to the workflow’s decision policy. Preserve the distribution and ordered legend when an assessment lies between categories. Set the treatment of uncertain results from reviewed task examples, rather than inventing a universal probability threshold. The application performs any resulting routing, escalation or review action and records its outcome. Solar Decide supplies the bounded model assessment used to consider that action; selecting a route does not establish that a later action was executed.\n\nThe useful final artifact is the answers object together with the state and question definitions that produced it. These records make it possible to inspect a surprising classification, distinguish missing evidence from ambiguous criteria and compare the assessment with a reviewed case. If a user needs a written explanation or a conversational response, the decision and source material can feed a separate writing step. Solar Decide’s specific role is producing typed probability-backed decisions from supplied text, rather than generating that explanation itself.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "b9c6e772dcc51cd10f0f15cbd07a6c8185706506f31c4aa6cfb7a9a637cc8cae", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "upstage/solar-decideUpstage Solar Decide is a text decision model built on Solar Mini 4. It evaluates a supplied state and typed questions, returning named choices, true-probabilities or weighted scores with probability information. Its bounded output supports classification, routing and policy checks 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.
Upstage Solar Decide is a structured decision model built on Solar Mini 4. It reads a supplied state and typed questions, then returns a decision for each question with calibrated probability information. The manufacturer describes a single-forward-pass decision process that generates no prose. Its intended applications include routing, classification and policy checks, with the model’s Korean understanding highlighted as part of its Solar Mini 4 foundation.
Prepare the state as a string or structured JSON describing the facts to assess. The maker’s interface serializes JSON values into the prompt. A question schema separately defines what to decide, which options are allowed and how an ordered assessment should be interpreted. Use stable names for the questions: their answers return under the same names, making the result easy to associate with the original workflow condition. Keep the factual state distinct from the instructions and criteria that define the decision.
The three question types have different outputs. A choice question returns the selected option, probabilities across the named alternatives and a confidence value. A noul question returns the probability of true for a yes/no condition. A score question returns a probability-weighted score, an indexed legend, probabilities and confidence. An ordered score can be fractional because it reflects the distribution across criteria. Preserve these fields rather than collapsing every result into a bare label or treating confidence as an explanatory sentence.
For support routing, supply the actual message and relevant history, then ask separate questions for intent, urgency and a defined condition such as whether the message expresses dissatisfaction. Describe categories by their meaning and give the urgency scale a deliberate order. An example schema can distinguish a delivery-status request, an account-access problem and an unrelated issue, while the urgency criteria run from no immediate action to immediate review. The observable result is a typed assessment of those choices, not a drafted reply to the customer.
For policy checks, include the relevant rule and the record facts together in the state. Define each condition narrowly enough that its answer can be inspected. A document workflow might ask whether required information is present, which review category applies and how strongly the record meets an ordered completeness standard. A score or probability does not independently verify the facts in the record. If decisive information is missing, the application needs a deliberate treatment of that uncertainty instead of interpreting a selected option as conclusive proof.
The manufacturer specifies a 512K-token context window for Solar Decide. Prepare large documents as the text or structured state the decision requires; a large context does not imply automatic parsing of an arbitrary file. Preserve source boundaries and the passages relevant to the criteria. Use focused questions rather than expecting an open-ended summary of the document. The model’s output remains bounded by the question types and options, regardless of how much material is included in the state.
A choice question accepts two to 26 options in the documented producer interface. The maker explains that this route reads decisions from single-token labels A through Z, so more than 26 candidates must be narrowed or split into several questions. This limit applies to choice options, rather than being a general limit on document length or a limit copied from another decision-model family. Define candidate descriptions so their meanings are distinct, and use a hierarchical decision only when that hierarchy matches the actual workflow.
For Korean-language records, keep the source meaning, names and identifiers intact and describe the decision criteria clearly. The typed result can use stable application labels while assessing natural-language evidence. When a record mixes languages or uses domain terminology, retain the relevant definitions in the state. A fluent interpretation of a term is not enough to establish that the classification criteria match the business rule, so inspect representative ambiguous cases as well as straightforward ones.
Use the returned probabilities and confidence according to the workflow’s decision policy. Preserve the distribution and ordered legend when an assessment lies between categories. Set the treatment of uncertain results from reviewed task examples, rather than inventing a universal probability threshold. The application performs any resulting routing, escalation or review action and records its outcome. Solar Decide supplies the bounded model assessment used to consider that action; selecting a route does not establish that a later action was executed.
The useful final artifact is the answers object together with the state and question definitions that produced it. These records make it possible to inspect a surprising classification, distinguish missing evidence from ambiguous criteria and compare the assessment with a reviewed case. If a user needs a written explanation or a conversational response, the decision and source material can feed a separate writing step. Solar Decide’s specific role is producing typed probability-backed decisions from supplied text, rather than generating that explanation itself.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits upstage/solar-decide | 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.0002 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read $0.0002 / 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.0002 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read $0.0002 / 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": "upstage/solar-decide",\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']='upstage/solar-decide'\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 upstage/solar-decide
Use the method paths shown above.