LLM generates absurd time ranges in calendar_query despite required fields (120k token overflow)

[PhilflowIO]

Problem

Despite fixing #24 by making both time_range_start and time_range_end required fields, LLMs still generate absurd time ranges that cause token overflow.

Example Query

User asks: "When is my next appointment?"

LLM generates:

{
  "tool": "calendar_query",
  "query": {
    "time_range_start": "2025-10-31T10:35:42.459+01:00",
    "time_range_end": "2099-12-31T23:59:59.000Z"
  }
}

Result: 120k tokens consumed (just from holidays!) 💸

Root Cause

The LLM interprets "next appointment" as "all future appointments until end of time" → uses 2099 as end date → massive result set.

Making the fields required didn't solve the underlying issue: LLMs don't understand the performance implications of their parameter choices.

Local Workaround (Low Priority)

I've fixed this locally by providing date/time context to the LLM:

• Either via a dedicated "get current time" tool
• Or by injecting current date/time into the prompt

This helps the LLM generate reasonable time ranges (e.g., "now + 7 days" instead of "now + 74 years").

Priority: Low (workaround works well for now)

Potential Solutions (Future)

When we revisit this, consider:

1. Max range validation (e.g., reject ranges > 365 days)
2. Better tool description (add examples: "next event" → 7 days max)
3. Add max_results parameter (safety net to cap token usage)
4. Separate specialized tool (get_next_events with implicit sensible range)
5. Hybrid approach (combine multiple strategies)

Related

• Original issue: Query tools can be called without filters, defeating their purpose #24
• Fixed making fields required, but didn't address LLM behavior pattern

[PhilflowIO]

Out of scope: Add it to the system prompt!