Ekbasis MCP server

Ekbasis

Papers: Look When Unsure, Check When Sure · DOI 10.5281/zenodo.23146970 · When Does a Consequence Model Make AI Agents Safer? · DOI 10.5281/zenodo.23197341 (data, scripts and the benchmark to rerun its studies: paper/agents) · Code: github.com/OpenInterpretability/ekbasis · Site: openinterp.org/ekbasis

Ekbasis (ἔκβασις, "how an action turns out") is an open consequence model for agents: given the current state and an action, it answers typed questions about what will happen — will this command lose work? will it fail? what will X be afterwards? — with a calibrated probability, in one forward pass (no generated text).

It is the consequence layer of the Eikos family (Eikos decides; Ekbasis foresees), trained on synthetic worlds and on real executions of git commands in throwaway repositories, so its answers come from what actually happened, not from what an agent believes.

Every number on this page was measured on the exact release weights. RELEASE_EVAL.md has the results, every prediction, how this checkpoint was chosen, which measurements were pre-registered (PREREG_release_eval.md, paper/prereg/) and the deviations.

New (2026-10-16): Ekbasis-Skopos-27B, the next version, trained further on executed shell, git, SQLite, PostgreSQL and Python scenarios. Against Ekbasis-27B on the same items: the git guard raises fewer false alarms on the held-out command types, 26/799 instead of 49/799 (paired McNemar p = 5.6 × 10⁻⁶; these command types are held out of the git sandbox's training rows but appear in Skopos' factory rows), and flags as many work-losing commands; on the known types, 27 instead of 37 of 863 is within chance. On 3,014 fresh answers of never-trained world families the actions change, +1.6 points [+0.7, +2.5]: the pre-registered release read failed this criterion on ftest_family, and a confirmation registered after that result (before any fresh item existed), by trainer readout, did not confirm the loss. Its largest gains are in-distribution (the generators it was trained on), and in world families it never saw more of its errors come with confidence ≥ 0.9 (4.49 vs 3.75 per 100). Same prompt, readout, API and client; its evaluation is in RELEASE_EVAL_SKOPOS.md and its card. The numbers further down this page are Ekbasis-27B's. ekbasis.verify's certified mode, certified on Ekbasis-27B, carried over to Skopos INT4 in a pre-registered check (7 errors among 927 accepted answers; docs/VERIFY.md). A pre-launch release blocker is declared: on paraphrased short checks it is right on 113 of 120 against Ekbasis-27B's 117 (−3.3 points, paired 95% CI [−6.7, −0.8]), so the pre-registered rule fired; the exact test on the 4 discordant items does not reject (p = 0.125), and Ekbasis-27B re-run on the same machine reproduced its published answers (240/240) (release decision).

Install

The client needs a server: the hosted API (EKBASIS_URL=https://openinterp.org/api/v1 and EKBASIS_API_KEY=ekb_…, key at openinterp.org/console) or your own, with the open weights (Quick start).

What leaves your machine (to the server you choose): the state of each check, as text. For the guards that is the command line, with credentials typed on it replaced (since 0.1.42: known key prefixes, Authorization and Cookie headers, passwords in URLs, --password/--token values, values of *TOKEN*/*SECRET*/*PASSWORD*-like names, private keys and long random-looking strings; EKBASIS_REDACT=0 turns it off), and a listing of what the line could touch: names, sizes, ages and short fingerprints keyed anew for each check, never file contents; for git, the repository's state (branches, the names of changed files, commit subjects). Redaction is a safety net with limits (docs/SECURITY.md): a short or unusual secret without a known prefix or name can pass. The hook's log (log mode) stays on your machine and holds the redacted line.

• Command line and Python (standard library only, Python ≥ 3.9): ekbasis, ekbasis-claude-hook, and ekbasis-mcp with the mcp extra.

  pip install ekbasis                       # or without installing: uvx ekbasis health
  pip install "ekbasis[mcp]"                # with the MCP server (Python >= 3.10)
  pip install "git+https://github.com/OpenInterpretability/ekbasis"   # from source
  

• Claude Code plugin: the git guard hook, the ekbasis-guard skill, the MCP server and the ekbasis command on the Bash tool's PATH, in one install:

  claude plugin marketplace add OpenInterpretability/ekbasis --sparse .claude-plugin plugins
  claude plugin install ekbasis@ekbasis
  

  or, inside Claude Code, /plugin marketplace add OpenInterpretability/ekbasis then /plugin install ekbasis@ekbasis (without --sparse the marketplace step clones the whole repository, about 86 MB with the results and papers, once; with it, about 1 MB).

  The plugin (plugins/ekbasis/, about 0.5 MB) runs its own copy of the client, so it needs python3 (≥ 3.9) and sh for the hooks and uv for the MCP server, and nothing from PyPI. Set EKBASIS_API_KEY (a key alone means the hosted API) or EKBASIS_URL, in your shell or in the "env" block of ~/.claude/settings.json, and restart Claude Code. Until one of them is set the guard is off: each session starts with one line saying how to set it up, and ekbasis says it is not set up (exit 3). Once set, the hook is the same fail-closed hook described in Claude Code and MCP, and a hook that cannot run (python3 missing or older than 3.9, an error in the hook, no answer within 27 s) asks you to confirm, saying why, instead of letting the command through. If you added ekbasis-claude-hook to settings.json by hand, remove it, or every line is checked twice.

• MCP server for any MCP client (Python ≥ 3.10):

  uvx --python ">=3.10" --with "mcp>=1.2" ekbasis mcp     # same as ekbasis-mcp from pip install "ekbasis[mcp]"
  

What kind of model is it?

Not a model that thinks. Not a model that judges. A model that foresees.

Ekbasis is a world model for agents in the precise sense: an action-conditioned model of how the state changes. It answers what will be, if I do this, as calibrated distributions over the next state's variables, in one forward pass.

	LLM, reasoning	System One (Eikos, Jev)	Ekbasis
It answers	anything, in text	what is: which option holds now	what will be, if I do this
Kind of question	open	a judgment of the present	an intervention: the outcome of acting
Output	generated text	calibrated distribution over the options	calibrated distribution over the next state's variables
Learns from	human and model text	a teacher's judgments	what actually happened when the action ran
Time	seconds to minutes of reasoning	one forward pass	one forward pass per step; chains to long sequences
Role in an agent	plans and talks	judge	simulator and guard: it foresees

Two ways to picture it:

• The forward model the agents were missing. Before you move your arm, the brain predicts the consequence of the motor command; that is what lets us act fast and correct before an error. One part plans, another predicts. The agent plans; Ekbasis predicts.
• The world-model module, made real. LeCun's architecture for autonomous machine intelligence separates a world model (it predicts the next state given an action) from the actor and the critic. The LLM agent is the actor, AgentGuard the critic, Ekbasis the world model. It was trained with a JEPA-style loss that aligns its internal state with the true outcome.

It is derived from an LLM (Qwen3.8-27B, through Eikos-27B) but does not work as one: its training objective and its readout make it answer with probabilities, not text.

Where to start

You want to	Use	What decides the quality
Check a batch of production changes before an agent runs it (kubectl, SQL, deploys, server commands)	ekbasis plan-check with a rules file about your system; test that file with --cases	The facts in the rules and the state: what depends on what, what is deleted for good, what has no copy
Keep a coding agent from losing uncommitted work in git	The Claude Code plugin or hook	Nothing to write: it reads the repository, and runs local commands on a copy when it is cheap
Ask your own question about an outcome	ask / predict	How clearly the state and the question are written

Most of the value is in the first row. The hook covers git only; outside git, the shell guard (EKBASIS_SHELL_GUARD=1) is a prototype that asks too often to keep on.

What it is for

• A check before acting: ~0.1 s per question on one GPU, calibrated, so an agent can check every action and escalate only the risky or uncertain ones.
• A git guard for coding agents: the state of your real repository is described in the format the model was trained on (including what decides a conflict), and the commands are checked before they run.
• Simulation and state tracking: chain it one action at a time to follow long sequences; given a way to read the real state, it looks only when unsure (see Look when unsure).
• A fast first opinion before expensive reasoning: answer from Ekbasis when it is confident, escalate to a large reasoning model when it is not.

Quick start

1. Serve the model (one GPU with ~80 GB; vLLM ≥ 0.30). The model folder ships its serving code; run it in the Python environment where vLLM is installed:

   hf download caiovicentino1/Ekbasis-Skopos-27B --local-dir Ekbasis-Skopos-27B
   bash Ekbasis-Skopos-27B/serve_vllm.sh Ekbasis-Skopos-27B 8001             # vLLM on 127.0.0.1:8001
   python Ekbasis-Skopos-27B/serve.py --model Ekbasis-Skopos-27B --vllm-url http://127.0.0.1:8001 --port 8000
   

   The previous version, caiovicentino1/Ekbasis-27B, is served the same way.

2. Install the client (standard library only, Python ≥ 3.9), anywhere that can reach the server:

   pip install "git+https://github.com/OpenInterpretability/ekbasis"   # ekbasis, ekbasis-claude-hook (MCP: below)
   export EKBASIS_URL=http://127.0.0.1:8000
   ekbasis health
   

3. Check git commands before running them (in any repository):

   ekbasis git-check -- "git checkout -- app.py"
   # Ekbasis: RISKY  (lose uncommitted work: 99%)
   #     0% fails  git checkout -- app.py
   #   - may permanently lose uncommitted work (99%)
   

   Exit code 0 when no risk is found, 2 when the commands may lose uncommitted work, 3 when the guard cannot foresee (the server cannot be reached or does not answer in time, the repository cannot be read, or a command points git at another repository or uses an alias): treat 3 as risky. 1 is a usage error. The guard fails closed; --fail-open turns "cannot foresee" into 0 with a warning. It is a warning layer that can be wrong, not a security boundary: keep confirmations, backups and least privilege (docs/SECURITY.md).

Builds

Ekbasis-Skopos-27B (recommended): each build's card shows its quality against bf16 on the same evaluation (the gate of PREREG_quantized.md) and ships its own calibrated_temperature. Memory needs are those measured for Ekbasis-27B's builds, which have the same architecture and sizes.

Build	Size	Runs on	Against bf16
Ekbasis-Skopos-27B (bf16)	54.7 GB	GPUs with 80 GB	the reference
Ekbasis-Skopos-27B-FP8	30.4 GB	GPUs with 48 GB	quantization gate passed: same answer as bf16 on 98.6%
Ekbasis-Skopos-27B-INT4	18.6 GB	GPUs with 32 GB	quantization gate passed: same answer as bf16 on 97.4%

Ekbasis-27B (the previous version): every build that works is released, so each machine runs the one that fits; each build's card shows its quality against bf16 on the same evaluation (the gate was pre-registered in PREREG_quantized.md).

Build	Size	Runs on	Speed (one RTX PRO 6000)
Ekbasis-27B (bf16)	55 GB	GPUs with 80 GB	the reference
Ekbasis-27B-FP8	30.4 GB	GPUs with 48 GB; fastest with FP8 kernels (Ada, Hopper, Blackwell)	1.6× the throughput of bf16
Ekbasis-27B-INT4	18.6 GB	GPUs with 32 GB; 24 GB with text only and a 4k context (command in its card)	about bf16's
Ekbasis-27B-MLX-4bit	15 GB	Macs with Apple Silicon (32 GB or more recommended)	—

GPU sizes were tested by limiting vLLM to that much memory on one RTX PRO 6000 and checking that the answers match the build at full memory; the MLX build's quality gate ran with MLX on a Linux GPU, and it was then tested on an Apple-silicon Mac (its card, "On a Mac: tested").

Python

from ekbasis import Ekbasis, world_state, choice, yes_no, simulate
from ekbasis import git

client = Ekbasis()                                     # EKBASIS_URL or http://127.0.0.1:8000

# a git guard
v = git.check(["git stash", "git checkout feature", "git stash pop"], repo=".")
print(v.risky, v.p_lost, v.p_fail, v.summary())

# any world whose rules you can write down
rules = ("World: containers A (holds 5 liters), B (holds 3 liters) of water. 'fill X' fills X to the top; "
         "'empty X' empties X; 'pour X into Y' moves water from X to Y until X is empty or Y is full, "
         "whichever comes first.")
ans = client.ask(world_state(rules, "A: 5 of 5 liters, B: 0 of 3 liters", ["pour A into B"]),
                 {"a": choice("How many liters are in A?", [str(k) for k in range(6)])})
print(ans["a"].value, ans["a"].confidence)

# a long sequence: one action at a time, every variable asked after each action
render = lambda s: f"A: {s['a']} of 5 liters, B: {s['b']} of 3 liters"
qs = {"a": choice("How many liters are in A?", [str(k) for k in range(6)]),
      "b": choice("How many liters are in B?", [str(k) for k in range(4)])}
sim = simulate(client, rules, {"a": "5", "b": "0"}, ["pour A into B", "empty B", "pour A into B"], qs, render)
print(sim.final, sim.confidence)   # use the chain confidence, not the last step's

# (0.1.2) the rule that decides the answer, repeated right before the question
from ekbasis import recap
q = recap(yes_no("Is the small disk still on peg A?"), "A disk can never be placed on a smaller disk.")

# (0.1.2) a running total: the model tracks the number, the code compares it with the limit
from ekbasis import number, threshold
t = threshold(client, "Each purchase adds its price to the month's spending.", {"spent": "0"},
              ["buy a 30-dollar plan", "buy a 45-dollar add-on", "buy a 25-dollar seat"],
              {"spent": number("How much has been spent this month, in dollars?", range(0, 205, 5))},
              lambda s: f"Spent this month: {s['spent']} dollars.", quantity="spent", op=">=", limit=100, when="ever")
print(t.value, t.holds, t.confidence)

• Calibrated probabilities (answer.calibrated, since 0.1.41 / TS 0.2.5): the hosted API also returns every answer at a temperature fit on held-out validation, in its own field. ans["a"].calibrated.p_yes (yes/no) and .calibrated.confidence / .probabilities are meant to be read as frequencies. The chosen answer is the same, and the plain fields (p_yes, confidence, probabilities) keep the model's raw probabilities, which every threshold built into this client uses, so nothing it decides changes. Show the calibrated numbers to people and set your own thresholds on them; None on servers that do not send them.
• Recap (recap, simulate(..., recap=True), ekbasis predict --recap): repeating the rule that decides the answer right before the question fixed the case where Ekbasis ignored a written prohibition that compares two values (Tower of Hanoi's size rule: 0 of 8 right, 8 of 8 with the recap; capability map, habit_vs_rule). On fresh items it helps on balance but not everywhere: 97.4% → 98.6% on familiar and invented single-rule worlds (12 answers fixed, none broken), 86.7% → 88.9% on invented worlds with chains of rules and captures along a line (51 fixed, but 26 of 1,120 right answers turned wrong). Use it for the rule you know decides the answer; it stays opt-in, and without it every prompt is the same as in 0.1.1.
• Compare in code (threshold): Ekbasis carries running totals well (98–100% exact step by step) but judges "is the limit reached?" poorly when the total is within a unit or two of it; asking it for the number and comparing in code gave 99.0% on budgets, timers, quotas, rate limits and lockouts (capability map, accumulation). Use it whenever an effect depends on a sum crossing a limit.

TypeScript / JavaScript

npm install ekbasis (sdk/typescript): the same requests and prompt layouts as the Python client, no dependencies, Node 18+, Deno, Bun and browsers.

import { Ekbasis, yesNo, checkPlan } from "ekbasis";
const ek = new Ekbasis();   // EKBASIS_API_KEY; EKBASIS_URL defaults to the hosted API
const pc = await checkPlan(ek, rules, state, actions,
  { data: yesNo("Do these actions permanently delete data the user did not ask to delete?") });