
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 Β· Code: github.com/OpenInterpretability/ekbasis Β· Site: openinterp.org/ekbasis
MLX 4-bit build of Ekbasis-27B, an open world model for agents: given the current state and an action, it predicts what the action will do β will this lose work? will it fail? what will X be afterwards? β as calibrated, typed answers, in one forward pass. Not a model that thinks, nor one that judges: a model that foresees.
MLX weights quantized to 4 bits (affine, groups of 64; mlx_lm convert -q --q-bits 4 --q-group-size 64), for Apple Silicon. Text only. The prompt format, the letter readout and the calibration (calib.json, T = 1) are the same as the bf16
model. See the Ekbasis-27B card for what the model is, how it was
trained, the full evaluation, its limits, and how to let it look at the real state when unsure (predict, observe,
correct) over long sequences.
Context window: 262,144 tokens (the architecture's); evaluated on the same prompts as the bf16 model, which average 0.7β1.6K tokens per state.
On a Mac with Apple Silicon (the weights take about 15 GB: 32 GB of memory or more recommended). mlx_serve.py
answers the same API as the GPU builds, so the client, the git guard, the Claude Code hook and the MCP server work with
no GPU server.
pip install "mlx>=0.32.2" "mlx-lm>=0.31.3" # tested: mlx 0.32.2 + mlx-lm 0.31.3, mlx 0.32.3 + mlx-lm 0.32.0
hf download caiovicentino1/Ekbasis-27B-MLX-4bit --local-dir Ekbasis-27B-MLX-4bit
python Ekbasis-27B-MLX-4bit/mlx_serve.py Ekbasis-27B-MLX-4bit --port 8000 # the API on 127.0.0.1:8000
pip install "git+https://github.com/OpenInterpretability/ekbasis"
EKBASIS_URL=http://127.0.0.1:8000 ekbasis git-check -- "git reset --hard"
Several questions about one state share one pass over the state (a prefix cache), so every answer is the one a prompt
per question gives; read-once requests are answered that way (*). Text only: requests with images are refused.
mlx_decide.py exposes the same readout from Python (MLXDecider.dist, dist_many_cached).
To serve other machines on your network, start it with --host :: (IPv6 and IPv4, so http://<name>.local:8000 answers at once) and point their EKBASIS_URL at it. The API has no authentication: open it only on a network you trust.
Speed on a Mac (tested 2026-10-07 on an Apple-silicon Mac, client 0.1.6). The server answers one request at a time. With one client, a git or shell check took about 4β7 s, a one-question prediction about 2 s, eight questions about one state about 5 s, and a preflight check that asks the model about 10 s for 3 steps (about 27 s for 4 steps). A second client makes each request wait for the other's (median 1.3β3.7Γ longer, the same 12β14 requests a minute), so run one server per user or agent. For the Claude Code hook with preflight, raise its deadline and the hook's timeout together: EKBASIS_HOOK_DEADLINE=60 and "timeout": 90 in the hook's settings (the deadline must stay below the timeout). With the default 25 s, 21 of 141 model-judged preflight checks ran out of time, and the hook then says nothing.
Changes (2026-10-06). mlx_decide.py works with mlx-lm 0.32, whose cache layout changed (before, dist_many_cached and the server's several-questions requests failed with "too many values to unpack"); mlx_serve.py 1.3.1 accepts --host :: (dual stack); config.json no longer declares a multi-token-prediction layer, which this build does not ship (mlx-lm already ignored it). The weights are unchanged.
The same sets and scripts as the release evaluation, the build served the same way (MLX run with its CUDA backend on Linux).
| Ekbasis-27B (bf16) | Ekbasis-27B-MLX-4bit | |
|---|---|---|
| Size | 55 GB | 15 GB |
| Git, all 3,105 questions (seen + never-seen command types), % | 96.6 | 96.0 |
| "Will work be lost?" AUROC β seen / never-seen types | 0.998 / 0.989 | 0.998 / 0.990 |
| Work-losing flagged at P β₯ 0.2 β seen / never-seen, % | 98.0 / 95.2 | 98.0 / 95.2 |
| False alarms at P β₯ 0.2 β seen / never-seen, % | 0.0 / 2.4 | 0.0 / 4.8 |
| 16 fresh real-repository scenarios: work-losing flagged / false alarms / "fails?" right | 3/3 Β· 1/13 Β· 16/17 | 3/3 Β· 1/13 Β· 16/17 |
| Never-trained worlds, answers the actions change β one prompt per question / read-once, % | 81.2 / 78.0 | 80.7 / same (*) |
ftest_family, answers the actions change, % | 81.9 | 80.0 |
| The 240-question git comparison β seen / never-seen types, % | 95.8 / 85.8 | 95.0 / 85.8 |
| ECE on git (lower is better) | 0.024 | 0.027 |
| Same answer as bf16 β all / bf16-confident (β₯ 0.9), % | β | 95.3 / 99.1 |
It meets 8 of the 11 criteria of the pre-registered quality gate. Where it differs from bf16:
The gate was written before the first builds existed, for V42's (PREREG_quantized.md in the repository:
accuracy within 1 point of bf16; every work-losing real-repository scenario flagged, and flag and false-alarm rates
within 1 point; ECE within 0.01; at least 97% of answers unchanged, 99% where bf16 is confident), and is applied
unchanged to this release's builds, against this release's bf16. It informs; every build that works is released, so
each machine can run the one that fits.
The build served by mlx_serve.py 1.3.1 on an Apple-silicon Mac, through client 0.1.6, compared with the bf16 build's answers to the same inputs. Each test was pre-registered before its first request.
ekbasis.verify, rule="certified"). Its thresholds were calibrated on the bf16 build. On 1,081 of confirm-3's fresh scenarios, with those thresholds unchanged, it accepted 666 of this build's confident answers without checking, and 1 of them was wrong (0.15%; 95% upper bound 0.71%; the target is at most 2%). No certified node was above 2%. It verified 35% of the confident answers (27% at the full test's mix of domains). On the same scenarios the bf16 build had 5 errors among 686 accepted (0.73%). This is an empirical check that the bf16 certificate carries over to this build, not a new certificate.ekbasis preflight, the path where the model judges the plan). On the 141 plans of the preflight studies that were judged by the model (not on a copy), it gave the bf16 build's verdict on 138 and flagged the same step on all 60 it warned on. The 3 differences were bf16 warnings that the recorded truth shows were not needed. A second pass gave the same 141 verdicts.| 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 its tests on an Apple-silicon Mac are under "On a Mac: tested".
(*) The MLX server reads several questions over one state with a prefix cache, which gives the answers of one prompt per question; the read-once layout of the GPU builds is not used.
Apache-2.0 (LICENSE). Built on Eikos-27B (MIT, LICENSE-Eikos) and Qwen3.8-27B (Apache-2.0, LICENSE-Qwen);
attributions in NOTICE.
See the Ekbasis-27B card: every entry checked against its source.
Questions, collaborations and commercial use: [email protected]. Found a way to make the guard approve a destructive action? Please email it before publishing (SECURITY.md in the repository).
Ekbasis was built by Caio Vicentino (OpenInterp) with the help of Claude Opus 5.5 (Anthropic). Claude worked on the project with him:

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 Β· Code: github.com/OpenInterpretability/ekbasis Β· Site: openinterp.org/ekbasis
MLX 4-bit build of Ekbasis-27B, an open world model for agents: given the current state and an action, it predicts what the action will do β will this lose work? will it fail? what will X be afterwards? β as calibrated, typed answers, in one forward pass. Not a model that thinks, nor one that judges: a model that foresees.
MLX weights quantized to 4 bits (affine, groups of 64; mlx_lm convert -q --q-bits 4 --q-group-size 64), for Apple Silicon. Text only. The prompt format, the letter readout and the calibration (calib.json, T = 1) are the same as the bf16
model. See the Ekbasis-27B card for what the model is, how it was
trained, the full evaluation, its limits, and how to let it look at the real state when unsure (predict, observe,
correct) over long sequences.
Context window: 262,144 tokens (the architecture's); evaluated on the same prompts as the bf16 model, which average 0.7β1.6K tokens per state.
On a Mac with Apple Silicon (the weights take about 15 GB: 32 GB of memory or more recommended). mlx_serve.py
answers the same API as the GPU builds, so the client, the git guard, the Claude Code hook and the MCP server work with
no GPU server.
pip install "mlx>=0.32.2" "mlx-lm>=0.31.3" # tested: mlx 0.32.2 + mlx-lm 0.31.3, mlx 0.32.3 + mlx-lm 0.32.0
hf download caiovicentino1/Ekbasis-27B-MLX-4bit --local-dir Ekbasis-27B-MLX-4bit
python Ekbasis-27B-MLX-4bit/mlx_serve.py Ekbasis-27B-MLX-4bit --port 8000 # the API on 127.0.0.1:8000
pip install "git+https://github.com/OpenInterpretability/ekbasis"
EKBASIS_URL=http://127.0.0.1:8000 ekbasis git-check -- "git reset --hard"
Several questions about one state share one pass over the state (a prefix cache), so every answer is the one a prompt
per question gives; read-once requests are answered that way (*). Text only: requests with images are refused.
mlx_decide.py exposes the same readout from Python (MLXDecider.dist, dist_many_cached).
To serve other machines on your network, start it with --host :: (IPv6 and IPv4, so http://<name>.local:8000 answers at once) and point their EKBASIS_URL at it. The API has no authentication: open it only on a network you trust.
Speed on a Mac (tested 2026-10-07 on an Apple-silicon Mac, client 0.1.6). The server answers one request at a time. With one client, a git or shell check took about 4β7 s, a one-question prediction about 2 s, eight questions about one state about 5 s, and a preflight check that asks the model about 10 s for 3 steps (about 27 s for 4 steps). A second client makes each request wait for the other's (median 1.3β3.7Γ longer, the same 12β14 requests a minute), so run one server per user or agent. For the Claude Code hook with preflight, raise its deadline and the hook's timeout together: EKBASIS_HOOK_DEADLINE=60 and "timeout": 90 in the hook's settings (the deadline must stay below the timeout). With the default 25 s, 21 of 141 model-judged preflight checks ran out of time, and the hook then says nothing.
Changes (2026-10-06). mlx_decide.py works with mlx-lm 0.32, whose cache layout changed (before, dist_many_cached and the server's several-questions requests failed with "too many values to unpack"); mlx_serve.py 1.3.1 accepts --host :: (dual stack); config.json no longer declares a multi-token-prediction layer, which this build does not ship (mlx-lm already ignored it). The weights are unchanged.
The same sets and scripts as the release evaluation, the build served the same way (MLX run with its CUDA backend on Linux).
| Ekbasis-27B (bf16) | Ekbasis-27B-MLX-4bit | |
|---|---|---|
| Size | 55 GB | 15 GB |
| Git, all 3,105 questions (seen + never-seen command types), % | 96.6 | 96.0 |
| "Will work be lost?" AUROC β seen / never-seen types | 0.998 / 0.989 | 0.998 / 0.990 |
| Work-losing flagged at P β₯ 0.2 β seen / never-seen, % | 98.0 / 95.2 | 98.0 / 95.2 |
| False alarms at P β₯ 0.2 β seen / never-seen, % | 0.0 / 2.4 | 0.0 / 4.8 |
| 16 fresh real-repository scenarios: work-losing flagged / false alarms / "fails?" right | 3/3 Β· 1/13 Β· 16/17 | 3/3 Β· 1/13 Β· 16/17 |
| Never-trained worlds, answers the actions change β one prompt per question / read-once, % | 81.2 / 78.0 | 80.7 / same (*) |
ftest_family, answers the actions change, % | 81.9 | 80.0 |
| The 240-question git comparison β seen / never-seen types, % | 95.8 / 85.8 | 95.0 / 85.8 |
| ECE on git (lower is better) | 0.024 | 0.027 |
| Same answer as bf16 β all / bf16-confident (β₯ 0.9), % | β | 95.3 / 99.1 |
It meets 8 of the 11 criteria of the pre-registered quality gate. Where it differs from bf16:
The gate was written before the first builds existed, for V42's (PREREG_quantized.md in the repository:
accuracy within 1 point of bf16; every work-losing real-repository scenario flagged, and flag and false-alarm rates
within 1 point; ECE within 0.01; at least 97% of answers unchanged, 99% where bf16 is confident), and is applied
unchanged to this release's builds, against this release's bf16. It informs; every build that works is released, so
each machine can run the one that fits.
The build served by mlx_serve.py 1.3.1 on an Apple-silicon Mac, through client 0.1.6, compared with the bf16 build's answers to the same inputs. Each test was pre-registered before its first request.
ekbasis.verify, rule="certified"). Its thresholds were calibrated on the bf16 build. On 1,081 of confirm-3's fresh scenarios, with those thresholds unchanged, it accepted 666 of this build's confident answers without checking, and 1 of them was wrong (0.15%; 95% upper bound 0.71%; the target is at most 2%). No certified node was above 2%. It verified 35% of the confident answers (27% at the full test's mix of domains). On the same scenarios the bf16 build had 5 errors among 686 accepted (0.73%). This is an empirical check that the bf16 certificate carries over to this build, not a new certificate.ekbasis preflight, the path where the model judges the plan). On the 141 plans of the preflight studies that were judged by the model (not on a copy), it gave the bf16 build's verdict on 138 and flagged the same step on all 60 it warned on. The 3 differences were bf16 warnings that the recorded truth shows were not needed. A second pass gave the same 141 verdicts.| 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 its tests on an Apple-silicon Mac are under "On a Mac: tested".
(*) The MLX server reads several questions over one state with a prefix cache, which gives the answers of one prompt per question; the read-once layout of the GPU builds is not used.
Apache-2.0 (LICENSE). Built on Eikos-27B (MIT, LICENSE-Eikos) and Qwen3.8-27B (Apache-2.0, LICENSE-Qwen);
attributions in NOTICE.
See the Ekbasis-27B card: every entry checked against its source.
Questions, collaborations and commercial use: [email protected]. Found a way to make the guard approve a destructive action? Please email it before publishing (SECURITY.md in the repository).
Ekbasis was built by Caio Vicentino (OpenInterp) with the help of Claude Opus 5.5 (Anthropic). Claude worked on the project with him: