Upstage: Solar Decide

Solar Decide is a structured decision model from Upstage, listed on api14 under the model id upstage/solar-decide. Upstage positions it as a System One endpoint built on Solar Mini 4, and its main category is decisions. Rather than a general purpose chat model, it is a specialised endpoint whose job is to take a state you provide and return a decision.

The model accepts text input and produces decisions as output. It works by taking a state together with typed questions, and it returns a choice along with the associated result. The context window is 524288 tokens, which is large enough to hold substantial state descriptions, histories or supporting material in a single request. The maximum output is 471859 tokens. Input is text only, and the output modality is decisions rather than free form prose.

Because the model is built around state plus typed questions, the practical use cases follow from that shape. It suits workflows where you already have structured context and need a discrete answer: routing or triage decisions, selecting an option from a defined set, classifying a situation into a category, or resolving a branch in an automated pipeline. Anywhere you would otherwise write rules or a scoring function and want a model to make the call from a described state, this endpoint is the intended fit. It is less suited to open ended generation, summarisation or conversation, since those are not what it returns.

You call it through api14's OpenAI-compatible API using the model id upstage/solar-decide, in the same way you would call any other model on the gateway. The model reports no supported parameters, so you should not rely on tuning options such as temperature or top_p being accepted; send your state and typed questions in the request and read the decision from the response. Because the interface is OpenAI-compatible, existing client libraries and code that already target api14 will work without a rewrite.

The main limitation to keep in mind is scope. Solar Decide returns decisions, not text, so if your application needs an explanation, a summary or a chat reply, a general text model will fit better. Its text only input also means it cannot take images or audio. If your task is genuinely a choice between options given a described state, this model is the direct match; if it is anything else, look elsewhere on api14.