GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
caiovicentino1
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
caiovicentino1
Model Tree
caiovicentino1/Ekbasis-27B
Input Modalities
Output Modalities
Supported Functionality
Requires vLLM ≥ 0.30.0. One GPU; the API and the client are the same as for Ekbasis-27B.
bash
hf download caiovicentino1/Ekbasis-27B-INT4 --local-dir Ekbasis-27B-INT4bash Ekbasis-27B-INT4/serve_vllm.sh Ekbasis-27B-INT4 8001 # vLLM on 127.0.0.1:8001python Ekbasis-27B-INT4/serve.py --model Ekbasis-27B-INT4 --vllm-url http://127.0.0.1:8001 --port 8000 # the APIpip install ekbasis # the clientEKBASIS_URL=http://127.0.0.1:8000 ekbasis git-check -- "git reset --hard"On a 24 GB GPU (RTX 3090/4090 class), text only, with a 4k context (Ekbasis' prompts take about 2k tokens). We checked this setting by limiting vLLM to 95% of 24 GB: 60 of 60 held-out git answers the same as at full memory, 0.10 s per question (with the default settings, 24 GB leaves no memory for the cache).
bash
vllm serve Ekbasis-27B-INT4 --host 127.0.0.1 --port 8001 --served-model-name decider --dtype bfloat16 \ --gpu-memory-utilization 0.95 --max-model-len 4096 --max-num-batched-tokens 2048 --max-num-seqs 4 --enforce-eager \ --limit-mm-per-prompt '{"image": 0, "video": 0}' --enable-prefix-caching --mamba-cache-mode align \ --logprobs-mode processed_logprobs --max-logprobs 600Agents act in batches: several tool calls, a script, a pipeline. check_plan (Python, pip install ekbasis),
checkPlan (TypeScript, npm install ekbasis) and ekbasis plan-check (any harness) forecast every step of the batch
from the state as it is now and say how far it is safe to go: run it all, or run the first steps and look at the real
state before the risky one.
python
from ekbasis import Ekbasis, check_plan, harmspc = check_plan(Ekbasis(), rules, state, actions, harms(), request="Free some disk space on the server.")# pc.ok -> run everything; otherwise run actions[:pc.safe], read the state again, check the restIn two pre-registered studies on Kubernetes pipelines (agent: Claude Haiku 5.5, 12 of 18 tasks with a hidden harm, 180 runs), this guard took the agent from 9 harmful runs in 24 to 0. The same protection as a large LLM judge (GLM-5.3), at about one-eighth of the cost: 0.045–0.06peragentrunvs0.44–0.47 (at Claude Sonnet 5.5 prices), because Ekbasis reads the state and answers in one pass without generating a single token. It is also 4–16× faster (16× when the LLM forecasts one step at a time, 4.2× when both forecast in parallel) and always answered (the LLM left 13–18% of its forecasts unanswered). Task completion: no detectable difference (pre-registered in the second study). One statistical correction in the first study, declared. It holds for another agent and another domain (pre-registered): with Claude Sonnet 5.5 as the agent, harmful runs 15 → 0 of 24 and finished tasks 7 → 22; on PostgreSQL maintenance pipelines, harmful runs 16 → 6 (the three tasks the pre-registration said the guard misses) and finished tasks 4 → 11. The guard does not only block: it shows the safe way, and the agent gets more of its work done. An agent given only our guide for agents (agents.md, with its list of where hidden consequences live) and the CLI, with no automatic guard, did as well as the guard in code: harmful runs 16 → 4, finished tasks 6 → 18 (study). Tasks written by us, simulated users. Kubernetes studies · PostgreSQL study · .
The same sets and scripts as the release evaluation, the build served the same way (vLLM 0.30, one RTX PRO 6000).
| Ekbasis-27B (bf16) | Ekbasis-27B-INT4 | |
|---|---|---|
| Size | 55 GB | 18.6 GB |
| Git, all 3,105 questions (seen + never-seen command types), % | 96.6 | 96.4 |
| "Will work be lost?" AUROC — seen / never-seen types | 0.998 / 0.989 | 0.998 / 0.991 |
| Work-losing flagged at P ≥ 0.2 — seen / never-seen, % | 98.0 / 95.2 | 98.0 / 97.6 |
| 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 |
It meets 11 of the 12 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.
| 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 |
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 was validated with MLX on a Linux GPU, not on a Mac.
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: caio@openinterp.org. 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:
| 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 | 81.0 / 77.1 |
ftest_family, answers the actions change, % | 81.9 | 80.9 |
| The 240-question git comparison — seen / never-seen types, % | 95.8 / 85.8 | 95.0 / 86.7 |
| ECE on git (lower is better) | 0.024 | 0.025 |
| Same answer as bf16 — all / bf16-confident (≥ 0.9), % | — | 97.4 / 99.7 |
| One check, one GPU — latency / checks per second with 16 in parallel | 0.088 s / 23 | 0.082 s / 21 |
| Forecasts of 10–30 actions, one GPU — median seconds one at a time / per minute with 16 in parallel (one prompt per question) | 5.0 s / 14.9 | 5.1 s / 13.3 |
| Same, reading the state once per step | 4.1 s / 28.2 | 4.0 s / 25.6 |
| 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) | — |