Decision Studio

Open Decision Foundation Models

One prompt. Several decisions. Explore Kai, Lex, Eos, Sol, Nox and Lux with eight LLM-routing scenarios plus 36 model-specific English scenarios. Route a prompt before calling an LLM, compare a batch of contexts with shared questions, or ask several related questions about one case.

Decision collection

The deployed service also includes a server-authoritative Tetris Race playground. It can compare any two configured Decision models, Jev Cloud, or a SystemOne upstream without exposing provider credentials to the browser. Both runners receive the same seeded piece sequence but keep independent boards, requests, actions, timing, and traces.

The race length follows the server's configured limit (120 steps by default, up to 2,000 when enabled). “Until first failure” is bounded by that server guard; reaching it without a game-over is shown as inconclusive, not as a win. A provider failure or incomplete run has no score winner. For equal completed step races, the speed percentage compares complete server-observed adapter calls on both sides, including direct Decision response attestation; a provider's inference-only time is diagnostic.

Tetris local endpoints must run the strict Decision API and echo the selected Hugging Face repository ID exactly (for example, llm-semantic-router/Decision-1.0-Lux-9B) in the response model field. Legacy wire aliases such as decision-lux are intentionally rejected; this makes an outdated or misrouted Gateway fail closed instead of attributing one model's play to another.

Click the model name beneath the dice to switch. The first tab, LLM routing, combines Choice, Score, and Noul questions to assess the target LLM capability, complexity, speed priority, whether the request has multiple steps, whether a factual claim needs source verification, and the necessary tool. Its examples cover quick arithmetic, architecture, code, screenshots, translation, proofs, and two distinct fact-checking tasks. Choose One context to inspect several aspects of one case, or Batch contexts to apply shared questions to a compact list of inputs. Single-context results show every candidate probability without opening a detail row; in the batch matrix, open a row for the full distribution. Each model and mode keeps its own draft.

The default example is a quick LLM-routing prompt tested across all six models. Some routing examples use model-specific wording so the same task is clear to both compact encoders and larger decoders; switching models shows the actual prompt and questions sent to that model. The screenshot example classifies the text request as requiring vision downstream; Studio does not inspect the image itself. Other examples cover reviews, deliveries, account security, stock requests, travel refunds, purchasing policy, expenses and document sensitivity. Desktop input and output panels keep equal heights with independent scrolling; actions and statistics remain visible. Context/question pairs are combined into real GPU batches. The API accepts up to 1,024 state/question decisions per batch within its byte and token budgets; live microbatch capacity belongs to the selected runtime. An unavailable batch worker is reported explicitly.

Complete input includes context, instructions, candidates and special tokens. Nothing is truncated. Examples are curated demonstrations, not benchmark results; probabilities do not guarantee correctness. One shared context in the request does not imply that the model encodes it only once. Context IDs only associate inputs with outputs; they are not model evidence.

The editor runs on this CPU Space. Production direct mode maps each canonical model ID to its own private vllm-sr decision serve instance; the authenticated pull-queue deployment remains an explicit rollback mode. Switching clears old results, and an unavailable or misidentified model never silently falls back to another. Requests and results are not application-logged.

Historical presentation metadata · Request contract · Deployment. Active revision and manifest pins come from the deployment registry and are checked against each live Decision runtime service; the presentation file is not a serving allowlist. Studio code is MIT licensed. Models have their own Apache-2.0 project licenses and retained third-party notices. This repository contains no model weights or worker credentials.