Inception: Mercury Decide

Inception: Mercury Decide is a structured decision model from Inception. Rather than a general purpose chat model, it is built around a specific job: taking a state you provide along with typed questions and returning a decision. It is served as a System One endpoint, which describes the style of inference Inception uses for this model. If your application needs an answer in the form of a choice, a score, or a yes/no rather than a paragraph of prose, this is the model category it belongs to.

On the input side, Mercury Decide accepts text. The state you send and the questions you attach to it are both text, and the questions are typed, meaning each question carries an expected answer form. The output is a decision rather than free form text, matching the typed questions you supply. The context window is 65,536 tokens, and the maximum output is 58,982 tokens, so long states and many questions can fit in a single request.

The practical uses follow directly from that shape. Anywhere you would otherwise write rule logic or a classifier to pick between options, score an item, or answer a yes/no question about a body of text, Mercury Decide can produce that decision from a state you describe in the request. Examples include routing or triage decisions, gating steps in a pipeline where a boolean result is enough, and scoring candidates against criteria. Because the output is already a decision, you avoid parsing free form text and can hand the result straight to the next stage of your system.

You call it through api14's OpenAI-compatible API using the model id "inception/mercury-decide". Because the API is OpenAI-compatible, existing OpenAI client libraries and tooling work with a base URL change. Note that this model lists no supported parameters, so do not rely on sampling controls such as temperature or top_p being accepted; send the state and typed questions in the request and read the decision from the response. Check the live price table on this page for current rates.

One thing to weigh before adopting it: the model is text in and decisions out. It is not the right fit when you need generated prose, summaries, translations, or other free form text, and it is not multimodal, so images, audio and similar inputs are out of scope. If your task is producing written content rather than resolving a typed question, a general text generation model will serve you better.