DEV Community: Lucas

Two Patterns for Reducing LLM Costs in Data-Heavy RAG Apps

Lucas — Tue, 23 Jun 2026 22:02:16 +0000

How we cut token usage significantly in an F1 telemetry analyzer by rethinking what goes into the context window — and when.

When building RAG applications on top of structured data (databases, APIs, telemetry), the naive approach is to dump everything into the context and let the LLM figure it out. It works, but it's expensive and slow. After building F1 Analyst Pro — a chat interface for Formula 1 race analysis backed by FastF1 + Supabase + Claude — we refined two patterns that significantly reduced both token usage and API costs without sacrificing response quality.

This post covers both patterns with real code from the project.

The Problem: Context Bloat

A typical race weekend in F1 Analyst Pro has data across multiple sessions: FP1, FP2, FP3, Qualifying, and Race. Each session has lap-by-lap data for 22 drivers — compound, lap time, position, stint, sector times, tyre life. On top of that: qualifying results, race results, stint summaries, pit stop analysis, key moments, race incidents, and journalist notes.

If you send all of that to the LLM on every query, two things happen:

Cost explodes. A full context dump for a race weekend easily reaches 8,000-12,000 tokens per query. At $3/MTok for Claude Sonnet input, that's $0.024-$0.036 per query — fine for one user, painful for many.
Quality degrades. LLMs perform worse when the context contains irrelevant information. A question about qualifying doesn't need race stint summaries — and including them adds noise that can distract the model from what matters.

The solution is two complementary patterns: conditional context and pre-generation.

Pattern 1: Conditional Context via Intent Detection

Instead of always building the full context, detect what the user is actually asking about and fetch only the relevant data.

Intent Detection

import unicodedata

def _detect_intents(prompt: str) -> dict:
    # Normalize accents so "clasificación" matches "clasificacion"
    p = unicodedata.normalize("NFD", prompt.lower())
    p = "".join(c for c in p if unicodedata.category(c) != "Mn")

    wants_qualy = any(w in p for w in [
        "clasificacion", "qualifying", "q1", "q2", "q3", "pole", "sector"
    ])
    wants_race = any(w in p for w in [
        "carrera", "race", "resultado", "vuelta rapida", "stint", "degradacion"
    ])
    wants_telemetry = any(w in p for w in [
        "telemetria", "aceleracion", "frenada", "velocidad", "throttle", "brake"
    ])
    wants_undercut = any(w in p for w in [
        "undercut", "overcut", "parada", "pit stop", "estrategia de pit"
    ])
    wants_practice = any(w in p for w in [
        "entrenamiento", "practica", "fp1", "fp2", "fp3", "long run", "evolucion"
    ])
    wants_race_sim = any(w in p for w in [
        "race simulation", "simulacion de carrera", "ritmo de fp2"
    ])

    # load_all is the fallback: fires only when no specific intent is detected
    load_all = not any([
        wants_qualy, wants_race, wants_telemetry,
        wants_undercut, wants_practice, wants_race_sim
    ])

    return {
        "wants_qualy": wants_qualy,
        "wants_race": wants_race,
        "wants_telemetry": wants_telemetry,
        "wants_undercut": wants_undercut,
        "wants_practice": wants_practice,
        "wants_race_sim": wants_race_sim,
        "load_all": load_all,
    }

Conditional Context Building

Each intent triggers specific SQL queries. Critically, expensive analyses (undercut/overcut, key moments, race incidents) are only fetched when they're actually relevant:

def build_context(self, prompt: str, gp_name: str, year: int) -> str:
    intents = _detect_intents(prompt)
    context = ""

    # --- QUALIFYING ---
    if intents["wants_qualy"] or intents["load_all"]:
        q_id = self.db.get_session_id(year, gp_name, "Q")
        if q_id:
            q_results = self.db.get_qualifying_results(q_id)
            context += "--- QUALIFYING (Q) ---\n" + q_results.to_string(index=False) + "\n\n"

    # --- RACE ---
    if intents["wants_race"] or intents["wants_undercut"] or intents["load_all"]:
        r_id = self.db.get_session_id(year, gp_name, "R")
        if r_id:
            # Always include stint summary for race queries
            stints = self.db.get_stint_summary(r_id)
            context += "--- RACE STINT SUMMARY ---\n" + stints.to_string(index=False) + "\n\n"

            # Undercut analysis: only when explicitly asked OR general race query
            if intents["wants_undercut"] or intents["wants_race"] or intents["load_all"]:
                pit_df = self.db.get_pit_stop_analysis(r_id)
                if not pit_df.empty:
                    context += "--- UNDERCUT/OVERCUT ANALYSIS ---\n" + pit_df.to_string(index=False) + "\n\n"

            # Key moments: only for race/general queries, not undercut-specific ones
            if intents["wants_race"] or intents["load_all"]:
                km_df = self.db.get_key_moments(r_id)
                if not km_df.empty:
                    context += "--- KEY MOMENTS ---\n" + km_df.to_string(index=False) + "\n\n"

            # Race incidents: always when race data is present
            inc_df = self.db.get_race_incidents(r_id)
            if not inc_df.empty:
                context += "--- RACE INCIDENTS ---\n" + inc_df.to_string(index=False) + "\n\n"

    # --- PRACTICE (FP1/FP2/FP3) ---
    if intents["wants_practice"] or intents["load_all"]:
        for fp_code, fp_label in [("FP1", "PRÁCTICA 1"), ("FP2", "PRÁCTICA 2"), ("FP3", "PRÁCTICA 3")]:
            fp_id = self.db.get_session_id(year, gp_name, fp_code)
            if fp_id:
                best = self.db.get_best_lap_per_driver(fp_id)
                if not best.empty:
                    context += f"--- {fp_label} ({fp_code}) ---\n" + best.to_string(index=False) + "\n\n"

    return context

The Impact

A query like "¿Cuál fue la pole?" used to pull in race stints, pit stop analysis, key moments, and FP laps — all irrelevant. With intent detection, it only fetches qualifying results: ~400 tokens vs ~6,000 tokens for the same question. That's a 15x reduction in input tokens for qualifying-specific queries.

For general race queries (load_all=False, wants_race=True), the context is still substantial but focused — stints, undercut analysis, key moments, incidents — all directly relevant to any race question.

Pattern 2: Pre-Generation for Charts

The standard approach when a user asks for a chart is to let the LLM generate the plotting code, return it to the client, execute it, and display the result. This sounds reasonable but has three problems in practice:

It costs tokens. A matplotlib or Plotly snippet is 50-150 lines of code — all in the output window.
It's unreliable. The LLM may hallucinate API calls, use deprecated methods, or generate code that fails silently.
It's slow. The user waits for the full code generation before seeing anything.

The alternative: generate the chart from real database data before the API call, then tell the LLM the chart exists.

Implementation

def send_message(self, prompt: str, gp_name: str, year: int) -> dict:
    intents = _detect_intents(prompt)

    # Step 1: pre-generate chart if telemetry is requested
    pre_chart = None
    chart_notification = ""

    if intents["wants_telemetry"]:
        drivers = self._extract_drivers(prompt, gp_name, year)
        session_type = self._detect_session_type(prompt)
        qualifying_segment = self._detect_qualifying_segment(prompt)  # Q1/Q2/Q3

        if drivers:
            pre_chart = plot_telemetry_trace(
                laps_data=None,         # fetches directly from FastF1
                gp_name=gp_name,
                year=year,
                drivers=drivers,
                session_type=session_type,
                qualifying_segment=qualifying_segment,
            )
            if pre_chart is not None:
                chart_notification = (
                    f"\n\n[SYSTEM: A telemetry chart comparing "
                    f"{', '.join(drivers)} in {session_type} has been generated. "
                    f"Reference it in your analysis without generating any code.]"
                )

    # Step 2: build context (conditional, as shown above)
    context = self.build_context(prompt, gp_name, year)

    # Step 3: inject chart notification into the user message
    user_content = context + prompt + chart_notification

    # Step 4: call the LLM
    response = self.anthropic.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1000,
        system=self._system_prompt(),
        messages=[{"role": "user", "content": user_content}],
    )

    return {
        "text": response.content[0].text,
        "chart": pre_chart,   # passed to Streamlit for rendering
    }

The Qualifying Segment Detail

One refinement worth highlighting: qualifying telemetry in F1 has three segments (Q1, Q2, Q3). A driver eliminated in Q1 never ran in Q3 — comparing their "best lap in Q" against a Q3 driver's best lap is meaningless.

The pre-generation step handles this by detecting the segment from the prompt:

def _detect_qualifying_segment(self, prompt: str) -> str | None:
    match = re.search(r'\b(q[123])\b', prompt.lower())
    return match.group(1).upper() if match else None

And in plot_telemetry_trace:

if qualifying_segment:
    stint_map = {"Q1": 1, "Q2": 2, "Q3": 3}
    seg_laps = drv_laps[drv_laps["Stint"] == stint_map[qualifying_segment]]
    drv_laps = seg_laps if not seg_laps.empty else drv_laps  # fallback if driver wasn't in that segment

fastest = drv_laps.loc[drv_laps["LapTime"].idxmin()]

The Impact

The pre-generation pattern eliminates chart code from the LLM output entirely. A telemetry response that previously cost ~800 output tokens (code + explanation) now costs ~200 tokens (explanation only). For charts, that's a 75% reduction in output tokens.

More importantly, the chart is guaranteed to use real data — no hallucinated driver codes, no deprecated FastF1 API calls, no silent failures.

Combining Both Patterns

The two patterns compose naturally. Here's what happens for a query like "Show me the telemetry of COL vs GAS in Q2":

Intent detection → wants_telemetry=True, wants_qualy=True
Context building → fetches qualifying results only (~400 tokens)
Pre-generation → generates Q2-filtered telemetry chart for COL and GAS from FastF1 directly
API call → sends qualifying context + chart notification (~600 tokens total input)
Response → LLM references the chart and analyzes the data (~200 tokens output)

Total: ~800 tokens. Without these patterns, the same query would use ~7,000 tokens (full context dump + chart code generation).

What This Doesn't Cover

These patterns work well for structured, database-backed RAG. For unstructured document RAG (PDFs, articles, knowledge bases), vector search with embedding-based retrieval is still the right tool. The key insight is matching the retrieval mechanism to the data structure — keyword/intent-based for tabular data, semantic for text.

The Full Project

F1 Analyst Pro is open source. The patterns described here are implemented in core/consultant_agent.py and core/chart_builder.py.

🏎️ f1-analyst.streamlit.app
📦 github.com/luc45hn/f1-analyst-pro

How I Built a Natural Language F1 Telemetry Analyzer with FastF1 and Claude

Lucas — Sat, 20 Jun 2026 05:36:36 +0000

Ask "Did McLaren's undercut on Ferrari work?" and get a real answer — backed by actual lap data.

The Problem

Formula 1 analysis is data-rich but tool-poor for non-engineers. A journalist covering a race weekend has to juggle timing sheets, telemetry exports, strategy briefings, and their own notes — all in different formats, none of them speaking to each other.

I wanted to build something that let a journalist (or any F1 fan with technical curiosity) ask questions in plain Spanish and get answers grounded in real telemetry data — not hallucinated summaries, not Wikipedia facts, but actual FastF1 lap data from that specific race weekend.

The result is F1 Analyst Pro: a Streamlit chat app that ingests FastF1 session data into Supabase, builds structured context from SQL queries, and sends it to Claude Sonnet for natural language analysis.

Live app: f1-analyst.streamlit.app
Repo: github.com/luc45hn/f1-analyst-pro

The Stack

FastF1 — official F1 telemetry data (laps, car data, weather, race control messages)
Claude Sonnet (claude-sonnet-4-6) — the LLM that interprets queries and generates analysis
Supabase + PostgreSQL — stores ingested session data; queried at runtime to build context
Streamlit — the frontend, deployed on Streamlit Cloud
Plotly — interactive charts for telemetry traces, tyre degradation, pace analysis

Architecture: Intent-Based RAG

This isn't a standard vector search RAG. There are no embeddings, no cosine similarity, no document chunks. Instead, the system uses intent detection + structured SQL queries to build context — which works much better for structured tabular data like lap times.

Here's the flow:

User query
    ↓
Intent detection (keyword matching + regex)
    ↓
SQL queries to Supabase (laps, results, stints, incidents)
    ↓
Structured context string
    ↓
Claude API call
    ↓
Natural language response + optional Plotly chart

Intent Detection

The agent detects what the user is asking about and fetches only the relevant data:

prompt_lower = unicodedata.normalize("NFD", prompt.lower())  # accent-insensitive

wants_qualy    = any(w in prompt_lower for w in ["clasificacion", "qualifying", "q1", "q2", "q3", "pole"])
wants_race     = any(w in prompt_lower for w in ["carrera", "race", "resultado", "vuelta rapida"])
wants_telemetry = any(w in prompt_lower for w in ["telemetria", "aceleracion", "frenada", "velocidad"])
wants_undercut  = any(w in prompt_lower for w in ["undercut", "overcut", "estrategia de pit", "parada"])
wants_practice  = any(w in prompt_lower for w in ["entrenamiento", "fp1", "fp2", "fp3", "long run"])

load_all = not (wants_qualy or wants_race or wants_telemetry or wants_undercut or wants_practice)

Building Context

Each intent triggers specific SQL queries. For a race query, the agent fetches stint summaries, pit stop analysis, key moments, and race incidents:

if wants_race or load_all:
    race_id = self.db.get_session_id(year, gp_name, "R")
    if race_id:
        stint_data = self.db.get_stint_summary(race_id).to_dict("records")
        static_context += "--- RACE STINT SUMMARY ---\n" + str(stint_data) + "\n\n"

        pit_df = self.db.get_pit_stop_analysis(race_id)
        if not pit_df.empty:
            static_context += "--- UNDERCUT/OVERCUT ANALYSIS ---\n" + pit_df.to_string(index=False) + "\n\n"

        key_moments = self.db.get_key_moments(race_id)
        if not key_moments.empty:
            static_context += "--- KEY MOMENTS ---\n" + key_moments.to_string(index=False) + "\n\n"

This context is then passed to Claude as part of the user message — not as a system prompt, but injected into the conversation turn so the model can reason over it.

Data Ingestion with FastF1

FastF1 is the backbone. Loading a session is straightforward:

import fastf1

fastf1.Cache.enable_cache("cache/")
session = fastf1.get_session(2026, "Barcelona Grand Prix", "R")
session.load(laps=True, telemetry=True, weather=True, messages=True)

# Access lap data as a DataFrame
laps = session.laps
print(laps[["Driver", "LapTime", "Compound", "TyreLife", "Position"]].head())

Each session gets ingested into Supabase with extended fields:

lap_record = {
    "driver":           lap["Driver"],
    "lap_number":       int(lap["LapNumber"]),
    "lap_time":         lap_time_seconds,
    "compound":         lap["Compound"],
    "tyre_life":        int(lap["TyreLife"]),
    "stint":            int(lap["Stint"]),
    "position":         int(lap["Position"]) if pd.notna(lap.get("Position")) else None,
    "is_personal_best": bool(lap["IsPersonalBest"]) if pd.notna(lap.get("IsPersonalBest")) else None,
    "speed_fl":         float(lap["SpeedFL"]) if pd.notna(lap.get("SpeedFL")) else None,
    "deleted":          bool(lap["Deleted"]) if pd.notna(lap.get("Deleted")) else None,
    "deleted_reason":   str(lap["DeletedReason"]) if pd.notna(lap.get("DeletedReason")) else None,
}

Having position per lap is what makes undercut/overcut analysis possible — you can track exactly when a driver gained or lost positions relative to their rivals.

Telemetry Traces

The most visually impressive feature. When the user asks for telemetry, the app generates a Plotly chart before calling Claude — then tells the model the chart exists so it can reference it in the analysis.

# chart_builder.py
def plot_telemetry_trace(laps_data, gp_name, year, drivers, session_type="Q", qualifying_segment=None):
    fig = make_subplots(rows=4, cols=1, shared_xaxes=True,
                        subplot_titles=["Speed (km/h)", "Throttle (%)", "Brake", "Gear"])

    for driver in drivers:
        # Filter by qualifying segment (Q1/Q2/Q3) if specified
        drv_laps = laps_df[laps_df["Driver"] == driver]
        if qualifying_segment:
            stint_map = {"Q1": 1, "Q2": 2, "Q3": 3}
            seg_laps = drv_laps[drv_laps["Stint"] == stint_map[qualifying_segment]]
            drv_laps = seg_laps if not seg_laps.empty else drv_laps

        fastest = drv_laps.loc[drv_laps["LapTime"].idxmin()]
        car_data = fastest.get_car_data().add_distance()

        fig.add_trace(go.Scatter(x=car_data["Distance"], y=car_data["Speed"], name=f"{driver} — Speed"), row=1, col=1)
        fig.add_trace(go.Scatter(x=car_data["Distance"], y=car_data["Throttle"], name=f"{driver} — Throttle"), row=2, col=1)
        # ... brake and gear traces

    return fig

The key insight: the model doesn't generate the chart — it's generated from real data and the model is told "a telemetry chart comparing COL vs GAS in Q2 has been generated." This avoids hallucinated matplotlib code appearing in the chat.

Undercut/Overcut Analysis

One of the features I'm most proud of. Given lap-by-lap position data, the system detects pit stop interactions between nearby drivers and assigns a verdict:

def get_pit_stop_analysis(self, session_id: int, position_window=3, lap_window=5):
    # For each pit stop, find rivals within ±3 positions
    # who also pitted within ±5 laps
    # Compare positions 3 laps after the last of the two stops
    # Verdict: UNDERCUT/OVERCUT EXITOSO/FALLIDO or PARADA NEUTRAL

The Monaco 2026 race produced this analysis automatically:

"HAM's undercut over HAD at lap 28 was the most decisive move of the race. Delta: +6.0s. Ferrari entered first and exited well ahead — textbook undercut execution."

Key Moments Detection

The system automatically flags anomalies in race data without being asked:

def get_key_moments(self, session_id: int) -> pd.DataFrame:
    # TRACK_LIMITS: laps where deleted=True
    # PACE_ANOMALY: lap_time > driver's median * 1.15 on green track
    # POSITION_DROP: position worsens 3+ places in one lap without a pit stop
    # PERSONAL_BEST: top 5 fastest personal bests on green track

This is what allowed the app to proactively mention in a race summary: "RUS lost 11 positions at lap 73 — the most significant single-lap position drop of the race."

Race Incidents from Race Control Messages

FastF1 exposes race_control_messages for Race and Sprint sessions. The system ingests these and cross-references them with on-track vs. official position discrepancies:

# Detect penalties that changed final standings
incidents = db.get_race_incidents(race_id)
discrepancies = db.get_position_discrepancies(race_id)

# Cross-reference: if a driver has both an incident AND a position discrepancy,
# the agent explains why their on-track finish differs from the official result

This caught the Barcelona 2026 case where Colapinto finished P8 on track but was penalized to P10 post-race for a yellow flag infringement — the agent explained it correctly without any manual notes.

What It Looks Like

Cost Control

Each query costs roughly $0.02-0.04 in Claude API usage. To prevent runaway costs, there's a per-user daily limit stored in Supabase:

DAILY_COST_LIMIT_USD = 3.00

def check_daily_cost(self, user_email: str) -> float:
    today = date.today()
    result = self.supabase.table("queries") \
        .select("cost") \
        .eq("user_email", user_email) \
        .eq("date", str(today)) \
        .execute()
    return sum(r["cost"] for r in result.data)

If the limit is reached, the agent blocks the query and shows a friendly message — no silent failures.

What's Next

NASCAR equivalent for Argentine driver Baltazar Leguizamón (O'Reilly Auto Parts Series 2026) — different data source, same RAG pattern
Multi-season historical comparison
Race simulation pace analysis (FP2 long run methodology — still being calibrated)

Try It

The app is live and free to try (within daily usage limits):

🏎️ f1-analyst.streamlit.app
📦 github.com/luc45hn/f1-analyst-pro

Built with FastF1, Claude Sonnet, Supabase, Streamlit, and too many late nights watching qualifying sessions.

How to open Google Maps in turn-by-turn navigation mode from a PWA (Android)

Lucas — Sat, 20 Jun 2026 03:14:52 +0000

The next attempt was the standard Maps URL:

window.open(`https://maps.google.com/maps?daddr=${lat},${lng}`, '_blank');

This opens Maps, but in the browser — not the app. And it shows the route preview, not turn-by-turn navigation.

What worked: Android Intent URLs

Android supports a special URL scheme that tells Chrome to launch a native app directly:

window.location.href = `intent://navigation/now?ll=${lat},${lng}&title=Next+stop#Intent;scheme=google.navigation;package=com.google.android.apps.maps;end`;

Breaking it down:

intent:// — tells Chrome this is an Android intent
navigation/now?ll=${lat},${lng} — opens Maps in navigation mode, starting immediately
#Intent;scheme=google.navigation — the URI scheme to use
package=com.google.android.apps.maps — the target app package
end — closes the intent syntax

This opens the Google Maps app directly and starts turn-by-turn navigation automatically — no extra taps needed. It also works with Android Auto.

The full function

export function openNavigation(destination: { lat: number; lng: number }): void {
  window.location.href = `intent://navigation/now?ll=${destination.lat},${destination.lng}&title=Next+stop#Intent;scheme=google.navigation;package=com.google.android.apps.maps;end`;
}

Call it on any user gesture (tap, click) and it works without being blocked by the browser.

The app

The full PWA is open source if you want to see the context:

🔗 GitHub repo
🌐 Live app

Built with React + TypeScript + Vite + Dexie.js + @vis.gl/react-google-maps.

If you're building a PWA that needs to hand off to Google Maps navigation on Android, this intent URL is the cleanest solution I found. Hope it saves you the hour I spent figuring it out.