Efficiency
What Ratel changes in the model's context, and what that saves in tokens and accuracy.
Ratel's value is measured in what the model reads: fewer tokens per turn, with tool selection as good or better.
What changes in the model's context
Ratel does not change your model or your prompts. It changes which tool and skill definitions reach the model on each turn:
| Without Ratel | With Ratel |
|---|---|
| Every tool schema is sent up front | Only the relevant top-K and capability tools are sent |
| The model must choose from one crowded list | Local retrieval ranks candidates for the current request |
| Each integration expands the model's tool surface | One catalog stays searchable behind capability tools |
| Runbooks compete with tool definitions for tokens | Skill bodies load only after the model selects one |
Why it compounds
Without Ratel, prompt cost scales with catalog size: the benchmark sweeps pools from 30 to 600 tools, and the baseline pays for all of them every turn. With Ratel, the model reads the top-K hits plus three capability tools no matter how large the catalog grows. That is the mechanism behind progressive disclosure.
Benchmark-backed numbers
On the BFCL tools suite (Ratel 0.4.0, dense retrieval, ratel-full arm vs
control-baseline), token savings grow with catalog size while accuracy holds at
or near baseline — only the smallest local model gives up a few points:
| Model | Mean total tokens | Accuracy (multiple / simple split) |
|---|---|---|
| Claude Haiku 4.5 | −86% | +26.0 / +6.5 pt |
| Claude Sonnet 4.6 | −87% | +0.5 / +0.5 pt |
| GPT 5.4 Mini | −89% | +1.0 / −1.0 pt |
| Qwen3 4b | −91% | −5.5 / −3.3 pt |
Smaller models gain the most: Haiku 4.5 jumps 26 points on the multiple split once the crowded list is gone.
Benchmark covers the methodology; the live results at benchmark.ratel.sh let you switch model, version, and retrieval method.