Layer-First Pattern Cuts LLM Overload in Map Generation
RidgeText stores map layers server-side instead of passing raw GeoJSON to the LLM, cutting tool-call context from roughly 125,000 tokens down to about 150.
RidgeText, an SMS-based wildfire and trail mapping service, uses an LLM to interpret requests and orchestrate tool calls. While building layered map generation, the team found that passing raw GeoJSON through LLM tool calls simply doesn't scale: a modest 50-500KB wildfire dataset translates to roughly 125,000 tokens, exceeding many context windows and making every call expensive.
Their fix is a layer-first architecture modeled on Mapbox's own source-and-layer design. Each data-fetching tool (retrieve_wildfire_layer, retrieve_trail_layer, etc.) stores its result server-side in an ordered queue and returns only a tiny acknowledgment containing a layer ID and feature count. A final generate_map call drains that queue, projects each layer onto a Mapbox Static API base image, and composites everything with sharp — keeping the LLM's context down to roughly 150 tokens instead of 125,000.
The tradeoff is that the LLM loses direct visibility into layer geometry: it can't answer geometry-specific questions like 'what's the nearest city to my trail' without a dedicated tool, and the layer queue is ephemeral, requiring re-fetching for multi-turn refinements — something the team plans to address by persisting layers to a database.
More broadly, the case illustrates a reusable pattern: when an LLM starts acting as a passive data pipe rather than a reasoning engine, moving the heavy data out of its context — and giving it only small, actionable acknowledgments — keeps the system both cheaper and more reliable.