---
title: The True Cost of an AI Travel Query
description: "Breaking down the infrastructure cost of a single 'Find me a flight' request — LLM inference, tool call API fees, compute, bandwidth, and pricing implications."
canonical: https://nowah.xyz/blog/true-cost-ai-travel-query
lastModified: "2026-08-07T03:54:54.096Z"
---

# The True Cost of an AI Travel Query

Breaking down the infrastructure cost of a single 'Find me a flight' request — LLM inference, tool call API fees, compute, bandwidth, and pricing implications.

"Find me a flight to Tokyo" costs between $0.02 and $0.50 to process. That 25x range is not a typo. It depends on the query's complexity, how many tool calls the agent makes, how much conversation context is loaded, and whether the traveler follows up with "actually, what about Osaka instead?"

Understanding this cost structure is essential for pricing, for infrastructure budgeting, and for product decisions about which features are economically viable. So let me break it down.

## Language model inference: the dominant cost

![Illustration for this section](https://pics.nowah.xyz/website-media/infrastructure-046-img-1.webp)

The largest cost component is language model inference. Every query requires sending the model instructions, conversation history, memory context, and the user's message to the model, then receiving the response. You pay for input tokens and output tokens.

A simple query ("What's the weather in Tokyo?") has a short conversation history, minimal memory context, and a short response. Maybe 2,000 input tokens and 200 output tokens. At current pricing for capable models, that's a few cents.

A complex query ("Plan a two-week trip through Southeast Asia for my family") has extensive context: the model instructions, previous conversation turns, retrieved traveler preferences, and the results from multiple tool calls. Input tokens can reach 10,000-20,000. The response is long and detailed. Output tokens might be 1,000-2,000. The cost is an order of magnitude higher.

The key driver isn't the user's message length. It's the accumulated context. A conversation that has been going for 30 messages has 30 turns of history in the context window. Each new message pays for all the previous context plus the new content. This is why long planning conversations are disproportionately expensive compared to short questions.

## Tool call costs: the multiplier

Each tool call multiplies cost in two ways.

First, the tool call itself consumes language model tokens. The model generates the tool call parameters (tokens out), receives the tool result (tokens in on the next turn), and then reasons about the result (more tokens). A single tool call adds 500-2,000 tokens to the conversation.

Second, external tools have their own API costs. A flight search query to our travel data provider costs money per search. A hotel availability check costs money per check. These costs are smaller than the inference cost but non-zero and additive.

A typical flight search query triggers 3-8 tool calls. A complex [trip planning](/blog/ai-trip-planning-tools-currency-tip-split) query might trigger 10-15 across multiple destinations. Each tool call adds inference tokens plus external API fees. The cost multiplication is real.

## Compute costs: modest but present

![Supporting diagram](https://pics.nowah.xyz/website-media/infrastructure-046-img-2.webp)

Server compute, database queries, and cache operations cost money. For a single query, these costs are small (fractions of a cent). But they're not zero, and at scale they matter for [unit economics](/blog/cost-first-thousand-ai-booked-flights).

Database queries for user profile, trip history, and preference loading happen on every query. Cache lookups for session state and reference data happen on every query. The streaming infrastructure maintains a connection for the duration of the response.

These fixed infrastructure costs per query are relatively stable regardless of query complexity. They're a floor that even the simplest query has to cover.

## Bandwidth: small per token, adds up

Streaming the response to the traveler consumes bandwidth. Each token is a small HTTP event sent over the streaming connection. Individually tiny. Over thousands of queries per day, the aggregate bandwidth is meaningful.

Media content in responses (flight card images, hotel photos) adds more bandwidth than text tokens. But these are typically served through CDN, so the bandwidth cost is edge-served rather than origin-served.

Storage costs for travel documents (PDFs, [boarding passes](/blog/launching-document-management-boarding-passes), passport scans) are low. The documents are small, and access patterns are infrequent. Storage is the least significant cost component.

## The cost spectrum

Let me put concrete ranges on different query types:

**Simple informational.** "What time is my flight?" No tool calls needed (data is in the user's profile). Low context. Short response. Roughly $0.01-0.03.

**Single search.** "Find me flights to Barcelona next week." One flight search tool call. Moderate context. Medium response with flight cards. Roughly $0.05-0.15.

**Comparative search.** "Compare flights to Barcelona and Lisbon for next week." Two search tool calls. Longer context with two result sets. Detailed comparison response. Roughly $0.10-0.25.

**\[Complex planning\]\(/blog/launching\-\[multi\-city\]\(/blog/multi\-city\-flight\-booking\-ai\-agents\)\-itineraries\-complex\-planning\)\.** "Plan our anniversary trip, two weeks in Japan, we like boutique hotels." Multiple search calls, hotel searches, visa checks, weather lookups, itinerary composition. Extended conversation over many turns. Roughly $0.30-0.50+ per message in the later turns.

These ranges are approximate and shift as model pricing changes, but the relative ratios are stable. Complex queries cost 10-25x what simple queries cost.

## Implications for pricing

This cost structure has direct implications for how we think about pricing.

A flat rate per month works if the average query cost times average query volume per user is predictable. It doesn't work if some users consistently run complex planning sessions while others ask simple questions. The heavy users subsidize the light users, which can be fine or not depending on the distribution.

[Rate limiting](/blog/rate-limiting-ai-agent-experience) serves double duty: it prevents abuse and it bounds the maximum cost per user per time period. Our 30 messages per minute limit on the chat endpoint caps the worst-case cost a single user can generate.

Free tiers need careful cost modeling. Offering a free tier means absorbing the cost of free users' queries. If free users average 5 simple queries per day, the cost is manageable. If they average 20 complex planning queries, it's not.

## Building your own cost model

If you're running an AI product, build a per-query cost model.

Measure token consumption by query type. Tag queries by complexity and measure average input and output tokens for each category.

Include tool call costs, both inference tokens and external API fees. Tool calls are the biggest variable in query cost.

Track cost per user per day/month. This is the number that determines whether your pricing works.

Set rate limits as cost guardrails. Don't rely on pricing alone to control costs. Rate limits provide a hard ceiling.

Review costs monthly. Model pricing changes, usage patterns shift, and new features alter the cost profile. A cost model that was accurate three months ago might be wrong today.

---

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).
