Shipping a Lisbon Trip Planner Before Friday

The Lisbon itinerary that keeps changing

Imagine you are building a travel-planning app for a Friday demo. Your test traveller wants three days in Lisbon, vegetarian meals, relaxed mornings and a fixed daily budget. You supply a detailed destination brief, accessibility preferences and instructions for formatting each day.

The first itinerary looks promising. Then come the revisions: move the museum visit, add an indoor afternoon, leave more time for lunch. Each request needs much of the same background, even though the latest instruction is different.

Prompt caching addresses that repeated work. A model provider can retain reusable processing for an eligible part of your input, then reuse it on a later matching request instead of processing that part from scratch. Think of a travel adviser keeping the trip folder open while you discuss changes. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching))

The trip folder is not the finished itinerary

The important distinction is between reusing input processing and reusing an answer. Prompt caching does the former. Your app is not simply retrieving yesterday’s itinerary; the model still generates a response to the current request. Cached input can reduce input-processing costs and waiting time, but it does not make newly generated output free. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching))

In our example, the traveller’s preferences and destination brief belong in the reusable folder. “Replace Tuesday afternoon with indoor activities” is the new task. The model needs both, but only the second part has changed.

A stable beginning makes the folder reusable

For prefix-based caching, the prefix is simply the beginning of the prompt. Reuse depends on an exact matching beginning and compatible request settings, not merely two prompts having similar meanings. A matching paragraph later in an otherwise different request is not enough. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching/diagnostics))

For this app, assemble requests in a predictable order:

• First: the planner’s standing instructions and required itinerary format.
• Next: the destination reference material.
• Next: the traveller’s unchanged dates, budget and preferences.
• Last: the latest revision request and any newly supplied information.

Keep that shared opening identical between revisions. Avoid inserting a changing timestamp or request identifier at the top. If the traveller changes their budget, update it honestly; preserving an obsolete preference just to chase a cache hit would defeat the purpose.

Three requests make the mechanism visible

Start with the shared trip folder followed by “Draft the three-day itinerary.” Send a second request with the same folder followed by “Make day two suitable for rain.” For a third request, keep the folder and ask for “A shorter walking route on day three.”

These are separate requests with a deliberately repeated beginning. A cache hit can cover that beginning while the new instruction still requires processing. A hit therefore does not mean the entire request was cached. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching/diagnostics))

Cache savings need more than repetition

Eligibility matters. Providers can impose minimum input lengths and cache lifetimes. Some configurations also charge more to write a cache than to process ordinary input, then charge less for subsequent reads. A short, one-off itinerary request may therefore offer little benefit. Check the selected model’s rules rather than assuming every repeated sentence qualifies. ([platform.claude.com](https://platform.claude.com/docs/en/build-with-claude/prompt-caching?cc61befa_page=2&f80ce999_page=6&fcdaa149_page=10&utm_source=openai))

Configuration differs too. Implicit caching lets the service handle reuse automatically; explicit caching gives the application more control where supported. Support can vary by API and model, so an OpenAI-compatible request format is not proof that every caching feature works identically. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/caching))

A small test before the Friday demo

Use the three-request sequence as a controlled test:

• Keep the model, shared content and request settings unchanged.
• Run the revisions close together, within the documented cache lifetime.
• Inspect the response’s cache-related usage fields where available.
• Compare total billed cost and response timing, not just cached-token counts.

Use reported usage to verify reuse; a response that merely feels faster is not sufficient evidence. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching/diagnostics))

Testing the planner through RelayVano

For a pay-as-you-go way to build and test this workflow, I recommend RelayVano, which works with OpenAI-compatible SDKs. Confirm caching support, usage reporting and billing for your selected route rather than assuming provider-direct behaviour carries over unchanged. Sign up for RelayVano and try the three-request itinerary test with your own destination brief.

The useful habit is straightforward: keep genuinely stable context stable, put revisions afterward, and measure what actually gets reused.