Give the library kiosk a response-time policy first
A library visitor asking where to find an accessible entrance should not share the same service expectations as an overnight archive tagging task. OpenAI Responses accepts a service_tier parameter, but the first decision belongs to the application owner: which requests are time-sensitive, which can wait, and which must never provide an unreviewed answer? Define a human fallback for the kiosk, such as a verified map or staff desk number, before routing any query through a model. Label the two workloads separately in application logs. This article describes a fictional library deployment, not a measured latency study or a claim that one processing tier always answers faster.
Specify service_tier and inspect the returned tier
A request can specify values such as auto, default, or flex when supported for its chosen model and project. The API reference explains that auto follows project settings and that the service_tier on the returned response describes how the request was actually served. These two values can differ, so an audit should retain both rather than assuming the submitted string is evidence of processing. Capture a response identifier, processing status, elapsed application time, and the tier returned. Keep patron names and raw questions out of routine performance dashboards. If the model or service tier is unavailable, record that state explicitly instead of fabricating a successful response.
Use lower-priority capacity only for work that can wait
Flex processing exchanges speed and availability for lower cost on supported models. That makes it a possible fit for non-urgent catalog enrichment, controlled content checks, or batch review notes. It is not a guarantee that a visitor-facing answer will be returned within the kiosk’s response budget. Classify each task before submission: an accessible-hours question may need a predictable fallback, while an internal metadata review can remain pending for later inspection. The reviewed output should land in a staff queue, not directly change public catalog records. Check current supported-model and pricing documentation instead of copying historical rates into an operations policy.
Handle resource unavailability as an explicit result
OpenAI documents that Flex may occasionally return resource-unavailable errors, including an HTTP 429 condition, and that slow processing can increase timeout exposure. Do not turn such an error into an empty successful review, and do not silently switch to a costly tier for every job. Define a small retry budget and decide which categories may fall back to normal processing. For low-priority work, a queued retry is often more appropriate than a synchronous loop. For urgent service, show the static library guidance and offer staff help. That experience should remain useful even if the model never replies.
Compare requested, served, and uncompleted states
A conceptual audit sheet should distinguish three situations. In the first, an urgent query is routed to a standard path and an actual tier is recorded when it finishes. In the second, an internal document review uses Flex and may be delayed or rejected for capacity. In the third, an approved fallback supplies non-AI guidance because no completed response was returned. These states do not establish measured performance; they describe how the application ought to represent an event. Store both service and workflow outcome, because a completed model response may still have incorrect content or lack the sources needed for a public answer.
Design retries to avoid duplicate effects
Retries that generate descriptive text are different from retries that can initiate tools or write data. If an answer can trigger a hold, notice, or record update, use an application-controlled idempotency identifier and verify the prior operation before repeating anything. A timeout does not prove that the previous operation failed. Restrict the model to read-only tools for kiosk information questions, and make administrative actions require a separate authorized confirmation. Retry policies should cap frequency, respect rate limits, and preserve enough metadata to explain why a second request was submitted. Do not post full private patron prompts to an error-monitoring platform.
Check spending without pretending to know the bill
The tier requested is not an invoice. Price, model support, prompt cache behavior, and failure handling depend on the current plan and API details. Use official pricing records and the usage reported by completed responses, then reconcile aggregates with the project billing view. Separate cost-per-completed-review from cost-per-request-attempt when comparing operational routes. An inexpensive request that repeatedly times out may consume more staff attention than a stable alternative. A dashboard may show attempt counts and processing mode, but avoid publishing invented latency percentiles, token totals, or savings estimates that have not been measured.
Give visitors a safe, visible fallback
Define the kiosk’s maximum acceptable waiting period and what happens next. A useful failure state could say that live assistance is temporarily unavailable and offer a verified hours page, printed accessibility information, or the staffed help desk. Do not claim that an uncompleted tool request verified today’s closure, opening hours, or room assignment. Keep the display consistent for users of assistive technology, and include a clear route to a human. For internal reviews, the fallback is different: retain the item as pending, preserve its source document link, and notify an editor if the review deadline is approaching.
Audit a staged rollout with nonpersonal evidence
A preproduction exercise can submit synthetic kiosk queries and fictional catalog notes across the selected tiers. Check whether the application records requested and returned tier values, reports errors without losing the work item, and avoids duplicate writes on retries. Record the exact model, SDK, API version, and request time for each test. Ask staff to inspect every answer requiring factual verification; a successful API call is not editorial approval. Roll out a service-tier choice only after measuring actual performance against the institution’s own workload and reviewing current model availability, cost, privacy requirements, and escalation procedures.
How We Research
We examined the named primary references for the applicable API semantics and limits: OpenAI Responses create reference, OpenAI Flex processing guide, OpenAI cost optimization guide. We compared documented options with an illustrative, fictional institutional workflow and marked failure states separately from editorial approval. No live cloud account, customer records, paid API measurements, production workload, or real service screenshots were used. Examples and diagrams are conceptual and do not represent observed accuracy, latency, cost, or compliance outcomes. Before deployment, check current regional availability, SDK and API versions, security obligations, billing, and institutional rules, then run authorized tests and obtain human signoff.
Frequently Asked Questions
No. It requests a processing mode, while latency and availability depend on capacity, the model, and the workload. Measure your own completed requests and retain a fallback.
Yes. The Responses reference says the returned service_tier describes the mode actually used, which can differ from the request.
Generally it is better suited to delay-tolerant work because slow responses and temporary resource unavailability are documented possibilities.
First check the status of any external side effect and use application-level idempotency. A timeout does not establish that a write never happened.
No. The diagrams are illustrative; compare current official billing and measured results from your own authorized environment.