OpenAI Prompt Caching: Separate Exhibit Kiosk Costs by Workspace Without Mixing Visitor Data

Shared Prompts Create a Real Accounting Question

A community museum operates two AI-supported information kiosks, one for an exhibition hall and another for school workshops. Both applications send public exhibit terminology and accessibility instructions to the Responses API, but their budgets belong to different internal teams. Staff want to know whether caching shared context reduces repeated-input costs and how to attribute those costs to each workspace. It is tempting to treat a cache hit as a dollar figure or to assume that using different keys creates private data boundaries. Neither shortcut is reliable. OpenAI prompt caching concerns repeated input prefixes and their accounting; it does not provide application authorization, verify a source or promise that every request will reuse cache. This guide describes hypothetical workspaces and an accounting method, not actual API or billing results.

Read the Current OpenAI Cache Model Carefully

OpenAI’s prompt caching documentation distinguishes behavior by model family. For GPT-5.6-and-later models, the Responses API guide describes configurable cache lifetimes, optional explicit breakpoints, and separate measurements for cached reads and cache writes. Other supported models use earlier controls such as `prompt_cache_retention`, and the semantics of `prompt_cache_key` differ. Do not apply one model family’s accounting instructions to another. An eligible stable prefix can be reused, but a hit depends on factors such as prefix length, model, routing and cache state. An exact copy of the previous question is not automatically a cache hit. If a prefix changes early, its reusable region may shrink. Write down which model and API configuration generated each usage record.

Decide What a Workspace Actually Means

Define a workspace as an administrative reporting unit, such as ‘public exhibit kiosk’ or ‘education lab assistant’, rather than an individual visitor’s identity. Keep stable non-sensitive identifiers for these units in application configuration. Do not put names, email addresses, ticket numbers or secret values into a cache key or log label. For newer models, OpenAI describes using `prompt_cache_key` to separate cache accounting between customers, users or workspaces within an application. It explicitly does not replace the application’s own privacy or authorization boundaries. For earlier models, the same parameter also matters for cache-routing optimization, so key choices should follow the specific model guidance. A workspace may operate more than one kiosk, but its accounting definition should not change from request to request without a documented migration.

Design the Prefix Before Interpreting the Bill

Place public, reusable content first: approved visitor accessibility instructions, a stable list of exhibition names, and a canonical plain-language vocabulary. Put changing questions, restricted collection data and visitor-specific context after that shared prefix, and only send private material where the organization permits it. A cache-aware prompt is not permission to send confidential data to a service. If an exhibition’s approved descriptive terms change, update the source and the prompt prefix; do not keep an obsolete rule solely to improve the cache ratio. For models with explicit breakpoint support, verify the configured boundary is after truly reusable material. For earlier models, follow the documented implicit caching rules. Capture a content-version identifier outside the prompt to explain why cache behavior changed after an editorial update.

Count Cached Reads and Writes Separately

The meaningful unit in a cost report is not ‘the kiosk used the cache once.’ It is the measured token usage reported for actual requests under a known model and pricing schedule. OpenAI documents fields including `usage.input_tokens_details.cached_tokens`; newer Responses caching also exposes cache-write token counts and the breakdown of lifetimes when supported. Reads and writes can have different rates. A longer-lifetime write may cost more than a short-lifetime write, even though future reads may be inexpensive. Calculate the amount for each workspace from the usage fields and the model’s applicable rates, not a promised fixed discount. Never count write tokens again as ordinary input if the pricing guidance already allocates them to their write categories. Missing usage data should be marked unresolved rather than filled with zeros.

Compare an Unhelpful Report With a Useful One

The comparison illustration shows three conceptual reporting states. A single mixed row labeled ‘cached’ cannot tell the education department what it spent. A better record separates workspace, model, ordinary input, cache-write tokens, cached-read tokens and request period. An approved finance view then attaches the applicable published rate and flags any unknown values. The drawings contain no real service usage, totals or computed savings. A strong cache-hit percentage does not always imply a lower total bill if input volume increased or cache writes were expensive. Likewise, a low hit percentage does not necessarily mean a misconfiguration when requests legitimately contain new material. Evaluate whole-workflow costs and the accuracy of the underlying records.

Preserve Visitor Privacy in Cost Telemetry

Operational logs should contain only what a billing analyst needs: workspace identifier, approved context version, model, token usage, timestamp and a non-sensitive correlation ID. Keep request bodies and visitor conversations out of finance dashboards. Limit access to telemetry so one team cannot see another team’s private input or infer their activity from unnecessarily granular per-person reports. OpenAI describes cache-key choices partly in terms of isolating accounting and reducing cache-hit probing; that is not the same as a guarantee that all submitted content is isolated by a human-readable key. Check the API’s data-retention, storage and regional processing documentation for the specific account and model. A budget dashboard should not become a new shadow archive of visitor questions.

Test the Report Before Using It for Budget Decisions

Prepare synthetic requests with a stable shared prefix, a deliberately modified prefix, and distinct workspace identifiers. Check that the accounting software can handle missing usage, cache writes of different lifetimes, multiple model prices and retried requests without double counting. If one response is retried after an uncertain network result, reconcile request IDs and actual charged usage before adding it to the ledger. Hold any cost comparison until enough real runs have been measured with consistent configuration. The article makes no benchmark claim: its objective is to show what data must be collected, how costs should be attributed and which privacy controls remain independent. The final decision should balance useful cost information against the operational burden and sensitivity of the data collected.

Related guides

• OpenAI Prompt Caching: Reuse a Policy Prefix Without Answering From Old Rules
• OpenAI Moderation API: Review Community Comments Without Silencing Legitimate Complaints
• OpenAI Webhooks: Process Archive Tagging Events Without Approving Duplicates

How We Research

We reviewed the following named primary-source documentation on November 8, 2026: OpenAI: Prompt caching, OpenAI: Responses API reference. We compared the specific API behavior, availability caveats, and failure boundaries with the editorial workflow described above. We also checked the proposed topic against the WordPress title inventory supplied by LabFin. We did not authenticate to a cloud account, run an API call, measure performance, evaluate model accuracy or verify any real client outcome. The case study and diagrams are explicitly hypothetical. Check present model and region support, billing, licensing, permissions, and privacy rules before deployment.

Frequently Asked Questions