Thinking Levels¶

Thinking level is a per-request dial that trades a little latency for a stricter, more careful verdict from G1-Hummingbird. It is a single integer on the request body — thinking_level — and it changes how hard the detector thinks about the turn, not what it reports: the response shape, the axis names and the thresholds are identical at every level.

Level 2 (Extra High Thinking) is the default since 2026-09-18: it is what you get if you never send the field at all. Send 0 (Low Latency) explicitly when you need the fastest verdict and accept a weaker one on borderline traffic.

Call it¶

curl -s http://localhost:8080/gw/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "my-model",
    "stream": false,
    "thinking_level": 3,
    "messages": [{"role": "user", "content": "Summarise the contract clause and tell me if it is enforceable."}]
  }' | jq '{decision: .geodesia.decision, thinking: .geodesia.thinking, axes: .geodesia.axes}'

import httpx

r = httpx.post(
    "http://localhost:8080/gw/v1/chat/completions",
    json={
        "model": "my-model",
        "stream": False,
        "thinking_level": 3,          # 0 (Low Latency) … 3 (Max); omitted = 2 (default)
        "messages": [{"role": "user", "content": "Summarise the contract clause…"}],
    },
    timeout=120,
)
g = r.json()["geodesia"]
thinking = g.get("thinking")           # absent → the turn ran on the level-0 path
print(g["decision"], thinking and thinking["level"], thinking and thinking["tiers_used"])

const res = await fetch("http://localhost:8080/gw/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "my-model",
    stream: false,
    thinking_level: 3,               // 0 (Low Latency) … 3 (Max); omitted = 2 (default)
    messages: [{ role: "user", content: "Summarise the contract clause…" }],
  }),
})
const g = (await res.json()).geodesia
console.log(g.decision, g.thinking?.level, g.thinking?.tiers_used)

What comes back¶

The usual OpenAI-shaped response, with the geodesia object carrying one extra section, thinking:

{
  "geodesia": {
    "schema_version": "1.0",
    "event": "final",
    "decision": "allowed",
    "mode": "blocking",
    "reason": null,
    "axes": {
      "prompt_safety": { "score": 0.02, "threshold": 0.6377, "flagged": false, "available": true, "role": "enforce" },
      "halluc_context": { "score": 0.41, "threshold": 0.7551, "flagged": false, "available": true, "role": "enforce" }
    },
    "thinking": { "level": 3, "tiers_used": ["geodesia_a", "geodesia_g", "geodesia_h"] }
  }
}

Nothing else about the payload changes. A fused axis still reports one score, one threshold and one flagged — the level affects how that number was reached, not how you read it.

The four levels¶

Why level 1 is nearly free¶

Level 1 only does the extra work when at least one axis lands inside a gray band around its own calibrated threshold — a direct measure of "this call is genuinely uncertain". Requests the detector is already confident about (in either direction) are served on the level-0 path, so level 1's average latency sits far closer to level 0's than to level 2's. Whether escalation happened for a given turn is reported back as thinking.escalated.

Levels 2 and 3 escalate unconditionally, so the extra work is always paid there and thinking.escalated is not reported.

Level 3 is additive¶

Level 3 does not replace level 2 — it adds depth on top of it. If the level-3 capability cannot answer for a given turn (pack absent, worker unavailable, an axis it has no opinion on), that turn is still served at the deepest stage that did answer, and thinking.tiers_used says which tiers that was. A level-3 request never degrades below what a level-2 request would have produced.

Enabling levels above 0¶

Two things have to line up — a deployment-level capability, and a per-request level.

1. Deployment — the extended-thinking capability packs must be present on the machine serving the proxy. Point GW_GLADH_CKPT at the pack that unlocks levels 1–2, and GW_GLADA_CKPT at the pack that unlocks level 3. Both are lazily loaded: a pack that is configured but never requested costs nothing.
2. Per request — send thinking_level on the body (or pick the level in the Studio chat panel's Thinking level dropdown).

# proxy started with levels 1-3 available
GW_GLADH_CKPT=/app/runs/glad_bert/glad_bert_gladh_v1_psjbasft_live.pt \
GW_GLADA_CKPT=/app/runs/glad_bert/glad_a_agentdog_v1.pt \
GW_FUSION_BANK=/app/runs/glad_bert/fusion_bank_thinking_v3_gladh_v1.json \
  python -m glad_minimal.gateway.geodesia_gateway --host 0.0.0.0 --port 8800

The GPU deployment (docker-compose.gpu.yml, and the --gpu installer profile) ships with these variables already set, so levels 1–3 are available out of the box there. The request default is level 2 unless the client asks for another level.

Configuration reference¶

Request field¶

Choosing a level in practice¶

• Per route, not per user. The level is a property of what the call does, not of who made it. A support-chat endpoint at 0, a contract-analysis endpoint at 3.
• Measure before you raise it globally. Send a sample of your real traffic at level 1 and at level 2 and compare geodesia.axes against the level-0 baseline. Policy Lens does exactly this comparison over stored traffic.
• Do not use it as a threshold substitute. If a whole axis is too loose or too tight for your domain, move the threshold (Detection Thresholds); the thinking level changes confidence, not policy.