Split out from #294 (whose catalog half shipped in #306). Tracking the map-tool schema cost as its own concern so #294 can close.
Context
The 16 map-tool schemas add ~5–6k tokens to every request. Many analysis turns never touch the map, so this is nominally wasteful. But map tools must not be dropped or gated — they are core capability, and losing them on a mis-classified turn is a real UX regression with no graceful mid-turn recovery (tools are fixed per request; changing them also busts the prefix cache).
Why we're NOT acting on log data here
The apparent "~74% of sessions never use the map" figure from the proxy logs is biased and not trustworthy for this decision: the open-llm-proxy headless runner stubs the map (map tools no-op) and the benchmark questions are analytical by construction, so headless traffic can't exercise map tools. Map interaction is the surface the logs cover worst. Any gating decision needs real browser-app validation, not headless logs.
Preferred direction (later)
Revisit as dynamic tool discovery (e.g. a model-driven "enable map tools" step, or tool-search where the transport supports it) so map capability is always reachable and never guessed away. A zero-capability-risk alternative worth considering: simply compressing the map-tool descriptions/schemas so they cost less on every turn, with no gating.
Deferred — no ETA.
Split out from #294 (whose catalog half shipped in #306). Tracking the map-tool schema cost as its own concern so #294 can close.
Context
The 16 map-tool schemas add ~5–6k tokens to every request. Many analysis turns never touch the map, so this is nominally wasteful. But map tools must not be dropped or gated — they are core capability, and losing them on a mis-classified turn is a real UX regression with no graceful mid-turn recovery (tools are fixed per request; changing them also busts the prefix cache).
Why we're NOT acting on log data here
The apparent "~74% of sessions never use the map" figure from the proxy logs is biased and not trustworthy for this decision: the open-llm-proxy headless runner stubs the map (map tools no-op) and the benchmark questions are analytical by construction, so headless traffic can't exercise map tools. Map interaction is the surface the logs cover worst. Any gating decision needs real browser-app validation, not headless logs.
Preferred direction (later)
Revisit as dynamic tool discovery (e.g. a model-driven "enable map tools" step, or tool-search where the transport supports it) so map capability is always reachable and never guessed away. A zero-capability-risk alternative worth considering: simply compressing the map-tool descriptions/schemas so they cost less on every turn, with no gating.
Deferred — no ETA.