BudEcosystem/Bud-Decision-Studio

Run open decision models on your own computer.
Give a model a situation and a few questions; get a calibrated probability for every answer, in milliseconds.
The LM Studio of Jev-like "System One" models, from Bud Ecosystem.

Documentation: the user manual, installation, guides, API reference and developer docs are in site/docs/, built from the Markdown in site/docs-src/. Open site/docs/index.html in a browser, or serve the site/ folder.

One line, and the app opens when it is done:

Or download from the latest release:

NVIDIA GB10 (DGX Spark) and other ARM64 Linux computers use the arm64 / aarch64 files.

1. It checks your computer: graphics, processor, memory and free disk.
2. It asks where models should run: the GPU (recommended when there is one) or the processor. Each choice says what it installs and how big it is.
3. It installs the engine by itself: a private Python with the PyTorch build that matches your hardware, and every model library. There is nothing else to set up, and nothing is installed outside the app's own folder.
4. You choose which models to download. Nothing downloads until you pick; two models suited to your computer are ticked for you. They download one at a time in the background.

You can switch between the GPU and the processor later on the System page.

A decision model does not write text. You give it a situation (an email, a support ticket, a log line, a JSON object) and typed questions, and it returns the probability of every answer you allowed, in one fast pass. There are six kinds of question:

Playground. Write a situation and questions (start blank with New, or from an example), press Decide, and read each answer as a chart. The model button (Ctrl+L) loads any model; the JSON and Code tabs show the exact request.	Models. Eleven open models in one table: what each is good at, its size, what it reads and its published results next to Jev. Download, load and eject with one click.
Evaluate. Run one question over many labelled examples on several models: a leaderboard, calibration and threshold charts, and a recommendation.	History. Every decision, from the Playground or any program, kept on this computer: filter by template, model, answer or time, see what needs a human, label the right answers, rerun on another model.
Templates. Reusable decisions with variables, a default model and settings. Every save is a version; compare two versions on real traffic before you switch.	API. The server address and ready-to-run examples in curl, Python, JavaScript and the official TypeSafe SDKs.
Train. Teach a model your own decisions from a spreadsheet of examples, on this computer's GPU. It keeps some examples aside, and the new model is added only if it is better on those without getting worse at general decisions. How it works.

A short video of the whole flow: docs/media/demo.mp4.

A template is a decision you reuse: its questions, the variables that fill in the situation (a message, a plan tier, a screenshot), a default model and settings. It runs on any model. Every save is a new version, so code can pin support-triage@3, follow support-triage@production, or take the latest. Starter templates for every Playground scenario are included.

History keeps every decision on this computer, whichever way it came in: the situation, the questions, the answers, the model, the version and the timing. From there you can label the right answers, turn a decision into a test example, rerun it on another model, or see how version 3 answers compared with version 2 on the same inputs.

# Once: a template with two variables (PUT again with changes and it becomes version 2)
curl -s -X PUT http://127.0.0.1:8420/v1/studio/templates/support-triage -H 'content-type: application/json' -d '{
  "name": "Support triage",
  "variables": {"customer_message": {"type": "string"},
                "account_tier": {"type": "string", "enum": ["free", "pro", "enterprise"], "default": "free"}},
  "state": {"tier": "{{account_tier}}", "message": "{{customer_message}}"},
  "questions": {"department": {"type": "choice", "instructions": "Which department should handle this?",
                               "criteria": ["billing", "technical", "sales"]},
                "urgent": {"type": "noul", "instructions": "Does it need an answer today?"}},
  "model": "laya", "settings": {"act_threshold": 0.85}
}'

# Every time: fill in the variables
curl -s http://127.0.0.1:8420/v1/studio/decisions -H 'content-type: application/json' -d '{
  "template": "support-triage",
  "variables": {"customer_message": "We were billed twice. Refund it today.", "account_tier": "pro"}
}'
# -> {"id": "dec_...", "act": false, "needs_review": ["urgent"], "answers": {...}, "template": {"id": "support-triage", "version": 1}, ...}

Each answer says whether it is sure enough to act on (its certainty against the template's threshold), so your code can act automatically or ask a person. The full reference, with every field, rule and error: docs/studio-api.md.

When a model doesn't decide the way your team would, show it. The Train page takes a spreadsheet of past decisions (a column of text, a column per answer), recommends a model, and trains it on this computer's GPU with LoRA, a small file of changes beside the original weights. It keeps the new model only if it is better on examples it never saw, has not got worse at general decisions it never trained on, and answers exactly the same once saved and reloaded. The trained model then appears beside the others in the Playground, Evaluate and your code, and Export and Import a trained model move it between computers.

Every model, trained by the studio itself on an NVIDIA GB10, measured on examples set aside before training:

Training needs an NVIDIA RTX 30 series or newer (including the GB10) or an Apple M2 or newer; Intel Arc and Core Ultra, AMD on Linux and older NVIDIA cards are experimental. How it works, what it checks, and every run: docs/trainer/README.md and docs/trainer/RESULTS.md.

Every model comes with examples made for it, checked to give the right answers: CLM 8B opens on a web agent choosing its next action, Lev on a question with 77 options, Kev 4B on a refund policy with exceptions, Laya Multilingual on a Japanese message, Jev-Omni on a receipt photo. Choosing a model in the Playground shows its own example (unless you have written your own), and the Models page lists them under Try it. scripts/model-examples.py checks that each model still answers its examples as intended.

Weights come from each publisher's Hugging Face repository and stay in the standard Hugging Face cache, shared with your other tools, unless you choose another folder (an external disk, say) on the System page. Each model keeps its own license; its page in the app links to it.

The studio speaks TypeSafe's Jev API and the gateway formats built on it, so code written for Jev works by changing only the base URL. While the app is open, the server is at http://127.0.0.1:8420 (the API page shows the exact address).

curl -s http://127.0.0.1:8420/v1/systemone -H 'content-type: application/json' -d '{
  "model": "laya",
  "state": "The package arrived crushed and the screen is cracked.",
  "questions": {
    "damaged": {"type": "noul", "instructions": "Was the item damaged?"},
    "team": {"type": "choice", "instructions": "Who should handle this?",
             "criteria": {"returns": "refunds and replacements", "shipping": "carriers and delivery", "sales": null}}
  }
}'

# pip install typesafe-sdk
from typesafe_sdk import TypeSafeClient, Noul

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8420", model="laya")
res = client.system_one(state="My card was charged twice for the same order.",
                        questions={"billing": Noul(instructions="Is this a billing problem?")})
print(res.answers["billing"].noul)   # probability of yes

Extensions, accepted on every endpoint: the multi, rank and number question types; "media" for images, audio and video; "settings": {"temperature": 2.0} for calibration; and the header X-Basal-Extensions: 1 to also receive decision, top_probability, probabilities and latency_ms. Without the header, responses are exactly TypeSafe's shape. Interactive API docs are at /docs.

Decisions are kept in History, from every endpoint, for 30 days by default (change it on the History page). Responses name the stored decision in the x-basal-decision-id header. To keep nothing for a call, send "store": false in the body (TypeSafe's own servers ignore it, so the same code runs against both) or the header X-Basal-Store: 0; "answers_only" keeps the answers without the situation. Variables marked sensitive are used for the decision and never written to disk.

Safe by default. The studio listens on this computer only; other websites open in your browser cannot send it requests, and changes (load, download, delete) need the header X-Basal-Client: 1. To serve other machines, start it with --host 0.0.0.0 and set BASAL_API_KEY; clients then send Authorization: Bearer <key>.

git clone https://github.com/BudEcosystem/Bud-Decision-Engine.git && cd Bud-Decision-Engine
./install.sh          # detects your hardware, asks where models run, installs everything into .venv (Windows: install.ps1)
./run.sh              # then open http://127.0.0.1:8420

Build the desktop app: cd desktop && npm install && npx tauri build (details in desktop/README.md). Run the tests: pip install -r requirements-dev.txt, then pytest tests/test_conformance.py and python scripts/e2e.py.

desktop app (desktop/, Tauri)   first run: installer/engine.py detects the hardware and installs PyTorch + libraries
      |                          later runs: starts the studio server and shows it in the window
      v
app window or browser (ui/) --HTTP--> studio server (basal/server.py, FastAPI; never touches the GPU)
                                         +- API formats (basal/api_compat.py): TypeSafe, OpenRouter, Vercel
                                         +- download queue (basal/hub.py): one at a time, smallest first
                                         +- where models run (basal/config.py): the device chosen in setup
                                         +- worker manager (basal/workers.py)
                                         v
                              one process per loaded model (basal/worker.py) --> GPU or processor
                                         +- an adapter per model family (basal/adapters/)