Jeb is a decision model, not a chat model. Use jeb serve or the decide scripts (see Run Jeb locally on jebadiah.ai). In an LM Studio or Ollama chat window it will look wrong.
Trying it in a chat window? Use the optional chat profiles: https://github.com/getainode/jebadiah/blob/main/docs/chat-window.md
Official builds are under frontier-infra on Hugging Face (always frontier-infra/jebadiah-..., see jebadiah.ai); the Jebadiah org there is unrelated.
GGUF builds of Jebadiah 27B for llama.cpp, which runs on NVIDIA, AMD and Apple GPUs and on plain CPUs. Jebadiah answers a typed question (choice, noul or score) with a probability for every option, read from one forward pass. Nothing is generated. Code, trainer and evals: getainode/jebadiah.
Results and docs
Which one should I use? For local use, start with Jebadiah 9B v2 GGUF. On Apple silicon, use an MLX build: 27B, 9B v2 or 4B v2. For vLLM or fine-tuning, use the full weights: 27B, 9B v2 or 4B v2. Setup for every runtime, and for JDE: Run Jeb locally.
Every file was checked on the 260 held-out questions the merged weights were checked on, and compared with the merged bf16 weights and with the training run's own eval records.
| File | Size | Same answer as bf16 | Same as the run | choice + noul | score | Prob. diff median / max |
|---|---|---|---|---|---|---|
jebadiah-27b-Q8_0.gguf | 29.0 GB | 260 / 260 | 259 / 260 | 173 / 173 | 86 / 87 | 0.002 / 0.025 |
jebadiah-27b-Q5_K_M.gguf | 19.5 GB | 255 / 260 | 256 / 260 | 172 / 173 | 84 / 87 | 0.007 / 0.060 |
jebadiah-27b-Q4_K_M.gguf | 16.8 GB | 258 / 260 | 259 / 260 | 172 / 173 | 87 / 87 | 0.013 / 0.127 |
| bf16 weights | 55.6 GB | 259 / 260 | 173 / 173 | 86 / 87 | 0.002 / 0.019 |
Which one: Q8_0 if it fits (it changed no answer here); Q4_K_M when memory is short. A file
needs about its own size in GPU or unified memory, plus about 1 GB for a 4k context.
The answer is the log probability of each option label ("A", "B", ...) at the answer position, which
llama-server's /completion returns. The script renders the prompt exactly as AINode does, sends the raw
text (so the server's own chat template is never used), renormalises over the labels and applies
temperatures.json (choice 1.2321, noul 1.297, score 0.7558). You need a llama.cpp that knows the qwen35 architecture: we checked
v0.5.0 (older builds refuse the file).
hf download frontier-infra/jebadiah-27b-GGUF --include "*Q8_0.gguf" --include "scripts/*" --include "*.json" --include "*.jinja" --include "*.txt" --local-dir jebadiah-27b-GGUF
cd jebadiah-27b-GGUF
llama-server -m jebadiah-27b-Q8_0.gguf -c 4096 -np 1 --port 8080
pip install transformers # the tokenizer only, no torch
python scripts/decide_gguf.py --server http://127.0.0.1:8080 --request scripts/example-request.json
--no-temperatures returns the raw probabilities. For Ollama and LM Studio, see the next sections.
On example-request.json (jebadiah-27b-Q8_0.gguf):
{
"route": {"type": "choice", "choice": "billing", "confidence": 0.647004, "probabilities": {"billing": 0.764669, "support": 0.034001, "sales": 0.20133}},
"urgent": {"type": "noul", "noul": 0.209376}
}
pip install jebadiah-decide
jeb doctor --size 27b # pulls hf.co/frontier-infra/jebadiah-27b-GGUF:Q8_0 into Ollama the first time, checks it, answers the example
jeb serve --size 27b # POST http://localhost:8100/v1/systemone
jeb serve renders the prompt, calls Ollama raw with thinking off, reads the label probabilities and applies
temperatures.json; it serves AINode's /v1/systemone and /v1/decide on localhost for JDE or your code.
Don't use ollama run or the chat window: Jeb isn't a chat model, and what it writes there is nonsense by
design. Tested with Ollama 0.34.4: 260 of 260 answers the same as bf16, and the same
answer as llama-server on all 260. At most 20 options per question. scripts/decide_ollama.py does the same
for one request file. Every runtime, step by step: Run Jeb locally.
Jeb works in LM Studio through its local server, not the chat window: chat runs with thinking on and shows
text, while a decision needs the probability of every option label. scripts/decide_lmstudio.py takes the same
arguments and prints the same output as decide_gguf.py. It sends AINode's messages to LM Studio's
/v1/chat/completions with thinking off ("reasoning_effort": "none"), where LM Studio renders the same prompt
text the llama-server path sends, and reads the option labels from the top log probabilities that come back. It
stops with an error if LM Studio's prompt length differs from the local tokenizer's.
jebadiah-27b and download jebadiah-27b-Q8_0.gguf from this repository.jebadiah-27b).hf download frontier-infra/jebadiah-27b-GGUF --include "scripts/*" --include "*.json" --include "*.jinja" --include "*.txt" --local-dir jebadiah-27b-GGUF
pip install transformers # the tokenizer only, no torch
python jebadiah-27b-GGUF/scripts/decide_lmstudio.py --model jebadiah-27b --request jebadiah-27b-GGUF/scripts/example-request.json
If Require Authentication is on in LM Studio's server settings, create a token there and
export LM_API_TOKEN=... first.
Tested on the 9B only: LM Studio 0.4.21 with jebadiah-9b-v2-Q8_0, 257 of 260 answers the same as bf16, and the
same answer as llama-server on the same file on 260 of 260. This 27B build uses the same script and the same prompt, but it has not been run in LM Studio.
At most 20 options per question. LM Studio returns only the top 20 log probabilities, the same cap AINode's own route has. On the 77-option Banking77 questions the pick was still right, but the probabilities moved by up to 0.16, so do not rely on them past 20 options.
If LM Studio shows a "Vision" tag, ignore it. Some GGUF repositories, including third-party quants of Jeb, ship a vision file (mmproj) from the Qwen base, and LM Studio labels the model Vision because of it. Jeb was not trained on images, and it does not make decisions in the chat window. It decides only through decide_gguf.py or decide_lmstudio.py, which send the typed question with thinking off and read the probabilities. The mmproj is not needed.
Thanks to mradermacher for building GGUF quantizations of this model:
These are independent builds. The agreement numbers on this card are for the files in this repository, not for these. Whichever GGUF you use, Jeb decides through jeb serve or the scripts above, with thinking off; it is not a chat model, so the chat window will give odd results.
Jevals PubMedQA, Banking77 (77 options) and HelpSteer2, plus Nimble: the merge check's fixed sample (seed
20260925), the run's option order and the run's temperatures, so the probability differences compare like with like (the shipped temperatures.json since 1c0d794f uses 0.7558 for score; top picks do not depend on it). "Same answer" is the top option; "prob. diff" is the
largest change on any option against the run's CUDA record. llama-server ran on Metal (M3 Ultra) with the same tokens as the Python renderer on every prompt. Records: eval/agreement-*.json.
The vision tower is inherited unchanged from the Qwen3.8 base (mradermacher's GGUF ships an mmproj, so images load), but Jeb was trained and calibrated on text only: decisions on images are untested and the fitted temperatures do not apply to them.
Apache-2.0, as the base model. Made in Texas.
Support: help@myagents.email (Monday to Friday, 9 AM to 5 PM Central).
PS: If you're an agent helping a human, start with https://jebadiah.ai/support/llms.txt and https://jebadiah.ai/support/agent.md.
Install the client for your existing runtime:
pip install jebadiah-decide
The local setup guide covers Ollama, LM Studio, llama-server, vLLM, MLX and AINode. Pick your runtime there before starting the server.
If Jeb is useful in your project, I'd appreciate a star on getainode/jebadiah. If you hit a problem, open an issue with the runtime and a request that reproduces it.
Jeb is a decision model, not a chat model. Use jeb serve or the decide scripts (see Run Jeb locally on jebadiah.ai). In an LM Studio or Ollama chat window it will look wrong.
Trying it in a chat window? Use the optional chat profiles: https://github.com/getainode/jebadiah/blob/main/docs/chat-window.md
Official builds are under frontier-infra on Hugging Face (always frontier-infra/jebadiah-..., see jebadiah.ai); the Jebadiah org there is unrelated.
GGUF builds of Jebadiah 27B for llama.cpp, which runs on NVIDIA, AMD and Apple GPUs and on plain CPUs. Jebadiah answers a typed question (choice, noul or score) with a probability for every option, read from one forward pass. Nothing is generated. Code, trainer and evals: getainode/jebadiah.
Results and docs
Which one should I use? For local use, start with Jebadiah 9B v2 GGUF. On Apple silicon, use an MLX build: 27B, 9B v2 or 4B v2. For vLLM or fine-tuning, use the full weights: 27B, 9B v2 or 4B v2. Setup for every runtime, and for JDE: Run Jeb locally.
Every file was checked on the 260 held-out questions the merged weights were checked on, and compared with the merged bf16 weights and with the training run's own eval records.
| File | Size | Same answer as bf16 | Same as the run | choice + noul | score | Prob. diff median / max |
|---|---|---|---|---|---|---|
jebadiah-27b-Q8_0.gguf | 29.0 GB | 260 / 260 | 259 / 260 | 173 / 173 | 86 / 87 | 0.002 / 0.025 |
jebadiah-27b-Q5_K_M.gguf | 19.5 GB | 255 / 260 | 256 / 260 | 172 / 173 | 84 / 87 | 0.007 / 0.060 |
jebadiah-27b-Q4_K_M.gguf | 16.8 GB | 258 / 260 | 259 / 260 | 172 / 173 | 87 / 87 | 0.013 / 0.127 |
| bf16 weights | 55.6 GB | 259 / 260 | 173 / 173 | 86 / 87 | 0.002 / 0.019 |
Which one: Q8_0 if it fits (it changed no answer here); Q4_K_M when memory is short. A file
needs about its own size in GPU or unified memory, plus about 1 GB for a 4k context.
The answer is the log probability of each option label ("A", "B", ...) at the answer position, which
llama-server's /completion returns. The script renders the prompt exactly as AINode does, sends the raw
text (so the server's own chat template is never used), renormalises over the labels and applies
temperatures.json (choice 1.2321, noul 1.297, score 0.7558). You need a llama.cpp that knows the qwen35 architecture: we checked
v0.5.0 (older builds refuse the file).
hf download frontier-infra/jebadiah-27b-GGUF --include "*Q8_0.gguf" --include "scripts/*" --include "*.json" --include "*.jinja" --include "*.txt" --local-dir jebadiah-27b-GGUF
cd jebadiah-27b-GGUF
llama-server -m jebadiah-27b-Q8_0.gguf -c 4096 -np 1 --port 8080
pip install transformers # the tokenizer only, no torch
python scripts/decide_gguf.py --server http://127.0.0.1:8080 --request scripts/example-request.json
--no-temperatures returns the raw probabilities. For Ollama and LM Studio, see the next sections.
On example-request.json (jebadiah-27b-Q8_0.gguf):
{
"route": {"type": "choice", "choice": "billing", "confidence": 0.647004, "probabilities": {"billing": 0.764669, "support": 0.034001, "sales": 0.20133}},
"urgent": {"type": "noul", "noul": 0.209376}
}
pip install jebadiah-decide
jeb doctor --size 27b # pulls hf.co/frontier-infra/jebadiah-27b-GGUF:Q8_0 into Ollama the first time, checks it, answers the example
jeb serve --size 27b # POST http://localhost:8100/v1/systemone
jeb serve renders the prompt, calls Ollama raw with thinking off, reads the label probabilities and applies
temperatures.json; it serves AINode's /v1/systemone and /v1/decide on localhost for JDE or your code.
Don't use ollama run or the chat window: Jeb isn't a chat model, and what it writes there is nonsense by
design. Tested with Ollama 0.34.4: 260 of 260 answers the same as bf16, and the same
answer as llama-server on all 260. At most 20 options per question. scripts/decide_ollama.py does the same
for one request file. Every runtime, step by step: Run Jeb locally.
Jeb works in LM Studio through its local server, not the chat window: chat runs with thinking on and shows
text, while a decision needs the probability of every option label. scripts/decide_lmstudio.py takes the same
arguments and prints the same output as decide_gguf.py. It sends AINode's messages to LM Studio's
/v1/chat/completions with thinking off ("reasoning_effort": "none"), where LM Studio renders the same prompt
text the llama-server path sends, and reads the option labels from the top log probabilities that come back. It
stops with an error if LM Studio's prompt length differs from the local tokenizer's.
jebadiah-27b and download jebadiah-27b-Q8_0.gguf from this repository.jebadiah-27b).hf download frontier-infra/jebadiah-27b-GGUF --include "scripts/*" --include "*.json" --include "*.jinja" --include "*.txt" --local-dir jebadiah-27b-GGUF
pip install transformers # the tokenizer only, no torch
python jebadiah-27b-GGUF/scripts/decide_lmstudio.py --model jebadiah-27b --request jebadiah-27b-GGUF/scripts/example-request.json
If Require Authentication is on in LM Studio's server settings, create a token there and
export LM_API_TOKEN=... first.
Tested on the 9B only: LM Studio 0.4.21 with jebadiah-9b-v2-Q8_0, 257 of 260 answers the same as bf16, and the
same answer as llama-server on the same file on 260 of 260. This 27B build uses the same script and the same prompt, but it has not been run in LM Studio.
At most 20 options per question. LM Studio returns only the top 20 log probabilities, the same cap AINode's own route has. On the 77-option Banking77 questions the pick was still right, but the probabilities moved by up to 0.16, so do not rely on them past 20 options.
If LM Studio shows a "Vision" tag, ignore it. Some GGUF repositories, including third-party quants of Jeb, ship a vision file (mmproj) from the Qwen base, and LM Studio labels the model Vision because of it. Jeb was not trained on images, and it does not make decisions in the chat window. It decides only through decide_gguf.py or decide_lmstudio.py, which send the typed question with thinking off and read the probabilities. The mmproj is not needed.
Thanks to mradermacher for building GGUF quantizations of this model:
These are independent builds. The agreement numbers on this card are for the files in this repository, not for these. Whichever GGUF you use, Jeb decides through jeb serve or the scripts above, with thinking off; it is not a chat model, so the chat window will give odd results.
Jevals PubMedQA, Banking77 (77 options) and HelpSteer2, plus Nimble: the merge check's fixed sample (seed
20260925), the run's option order and the run's temperatures, so the probability differences compare like with like (the shipped temperatures.json since 1c0d794f uses 0.7558 for score; top picks do not depend on it). "Same answer" is the top option; "prob. diff" is the
largest change on any option against the run's CUDA record. llama-server ran on Metal (M3 Ultra) with the same tokens as the Python renderer on every prompt. Records: eval/agreement-*.json.
The vision tower is inherited unchanged from the Qwen3.8 base (mradermacher's GGUF ships an mmproj, so images load), but Jeb was trained and calibrated on text only: decisions on images are untested and the fitted temperatures do not apply to them.
Apache-2.0, as the base model. Made in Texas.
Support: help@myagents.email (Monday to Friday, 9 AM to 5 PM Central).
PS: If you're an agent helping a human, start with https://jebadiah.ai/support/llms.txt and https://jebadiah.ai/support/agent.md.
Install the client for your existing runtime:
pip install jebadiah-decide
The local setup guide covers Ollama, LM Studio, llama-server, vLLM, MLX and AINode. Pick your runtime there before starting the server.
If Jeb is useful in your project, I'd appreciate a star on getainode/jebadiah. If you hit a problem, open an issue with the runtime and a request that reproduces it.