Unit Economics of AI-Booked Flights: What We Model Before Launch

Every AI travel team eventually stares at a spreadsheet with cost columns and a revenue column. We do that *before* public scale, not after. Early per-booking cost is usually higher than mature unit economics. The reasons are instructive, and they shape model choice, caching, and when we subsidize.

LLM inference: the largest variable cost

The largest variable cost component in an AI-booked flight is the language model inference that powers the agent's reasoning. Every conversation turn requires the model to process the conversation history, reason about the traveler's request, decide which tools to call, and generate a response. Each of these steps consumes computational resources that are billed by token volume.

A single booking conversation is not a single inference call. The agent typically makes three to ten tool calls during a booking flow. The traveler says "find me a flight to London next week." The agent calls a search tool. The results return. The agent processes the results, ranks them, and presents options. The traveler asks a follow-up question. The agent reasons again. The traveler selects an option. The agent initiates the booking flow. Each step involves model inference.

The cost per conversation varies significantly based on complexity. A simple, direct booking where the traveler knows exactly what they want costs less because it requires fewer turns and fewer tool calls. A complex planning conversation where the traveler explores destinations, compares options across multiple dates, and iterates on preferences costs more because it involves more reasoning steps.

Model selection directly impacts this cost. Larger, more capable models produce better results but cost more per token. Smaller, faster models cost less but may require more conversation turns to reach the same outcome, potentially negating the per-token savings. We continuously evaluate the tradeoff between model capability and cost, running different models for different types of queries.

Travel API costs

Each flight search hits our travel data provider's API. The provider charges per search request, with pricing that varies based on the type of search, the number of results returned, and the volume tier. A single traveler asking for flights might trigger multiple search calls: the initial search, a refinement with different dates, a search for alternative airports, and a final verification before booking.

Booking execution generates additional API costs. The reservation call, the payment confirmation, and the ticket issuance are each separate API interactions with the provider. Post-booking, there are costs for status monitoring, change requests, and cancellation processing.

At our initial volume, we were on the provider's standard pricing tier. The per-search cost was manageable for individual bookings but significant at aggregate. As volume grew, we negotiated better rates, but the travel API remained a meaningful cost component. Unlike LLM costs, which we can optimize through model selection and prompt efficiency, travel API costs are largely determined by the provider's pricing structure.

Payment processing

Payment processing fees follow the standard structure for online transactions: a percentage of the transaction amount plus a fixed fee per transaction. For flight bookings, which can range from a few hundred to several thousand dollars, the percentage component is the dominant cost.

The payment platform takes its percentage regardless of whether the booking succeeds or fails. Refunds incur additional processing. Chargebacks incur fees that exceed the original processing cost. These edge cases are small in percentage but noticeable in aggregate when you are processing bookings at early scale.

Currency conversion adds another cost layer for international bookings. When a traveler pays in a different currency than the flight is priced in, the conversion spread is an additional expense that compounds with the processing fee.

Infrastructure costs

The infrastructure stack that supports AI travel booking includes several components, each with its own cost profile.

The database stores user profiles, conversation history, booking records, and trip data. At early booking volume, the database cost is modest. But each booking generates significant data: the conversation transcript, the search results that were considered, the booking details, and the post-booking status updates. The data volume per booking is orders of magnitude larger than a traditional travel platform because the conversation context is stored alongside the transaction.

The background job system processes asynchronous tasks: sending booking confirmations, dispatching push notifications, polling flight status updates, and running analytics jobs. The job queue runs on an in-memory data store that has its own hosting cost. At early booking volume, the job queue is lightly loaded. At scale, it becomes a significant cost component.

Document storage handles boarding passes, itinerary PDFs, and other booking documents. Cloud storage costs are low per document but add up as booking volume grows, each generating multiple documents.

Push notification delivery has a per-message cost that is negligible for individual travelers but material at aggregate, especially for proactive features that send multiple notifications per trip.

Total cost per booking

Rolling up all layers, the total cost per completed booking is the sum of LLM inference, travel API calls, payment processing, and infrastructure allocation. For the first thousand bookings we model, this total was higher than our target unit economics for two reasons.

First, early conversations were longer than they will be at maturity. Travelers new to AI booking ask more exploratory questions, require more clarification, and take more turns to complete a booking. As travelers become familiar with the agent's capabilities, conversations become more efficient, which directly reduces LLM costs per booking.

Second, our infrastructure was not optimized for cost efficiency at this stage. We prioritized reliability and development speed over cost optimization. Database queries were not fully optimized. Caching was minimal. The job queue retained more data than necessary. These are standard early-stage tradeoffs that improve with focus.

The revenue side of the equation comes from our subscription model and, for some transactions, a small platform fee. At early booking volume, the revenue per booking was lower than the cost per booking for many transactions. We were subsidizing early usage.

The subsidy question

Losing money on early bookings is a deliberate strategy, not an oversight. The subsidy funds two things: product improvement and user acquisition.

Product improvement requires real usage data. Synthetic testing and beta programs provide some signal, but the quality of the agent improves dramatically with real traffic after launch. Every booking teaches us something: which conversations are too long, which tool calls fail, which edge cases we missed. The cost of the first thousand bookings we model includes the cost of the learning that makes the next much larger bookings cheaper and better.

User acquisition through product quality is the most sustainable growth strategy for an AI product. Travelers who have a genuinely good booking experience become advocates. They refer friends. They leave positive reviews. The word-of-mouth value of a subsidized but excellent early experience compounds over time.

The subsidy is not indefinite. We model the cost trajectory and target a specific timeline to unit-economics breakeven. LLM costs decrease through prompt optimization, model selection improvements, and caching of common reasoning patterns. Travel API costs decrease through volume-based pricing tiers. Infrastructure costs decrease through optimization. Revenue per user increases through subscription adoption and reduced churn.

The spreadsheet that made us gulp was a snapshot of day one. The trajectory matters more than the snapshot. And the trajectory, informed by every optimization opportunity we identified in those first thousand modeled bookings, points toward sustainable economics at scale.

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.