AI feature costs: count repair and review

For the fictional request req-demo-02, an initial attempt plus a repair costs $0.0038 in assumed provider charges. Add three assumed minutes of review and the request reaches $1.5038. Counting only the first call would miss both the repair and most of the work.

All figures are synthetic, in USD: token counts, outcomes and review times are invented, at hypothetical rates of $1 per million input tokens, $4 per million output tokens and $30 per review hour. This is not a rate card, billed usage or measured labour. Only decimal arithmetic was executed, with no provider/model call, tokenizer, parser, quality evaluation, latency test or invoice reconciliation.

Two attempts still belong to one product request

The proposed feature reads approved document metadata and suggests a document type and expiry date for human review. In fictional req-demo-02, the input says “Renewal date 2027-03-01.” Assume the parser rejects trailing prose outside JSON, then a repair produces schema-valid fields for review. Neither response nor parser result was actually produced.

1. Initial attempt: 1,400 invented input tokens and 300 invented output tokens. At the hypothetical rates above: (1,400 × $1 + 300 × $4) ÷ 1,000,000 = $0.0026.
2. Repair attempt: 600 invented input tokens and 150 invented output tokens. (600 × $1 + 150 × $4) ÷ 1,000,000 = $0.0012.
3. Review: three assumed minutes at $30/hour = $1.50. The word “renewal” still needs interpretation; valid JSON does not establish an expiry date.

Under these invented assumptions, $0.0026 + $0.0012 + $1.50 = $1.5038. Link both attempts to the same product_request_id; a repair adds cost, not a new customer request.

In fictional req-demo-05, a raw identity document falls outside the metadata-only scope and is blocked before the provider adapter. Zero provider attempts cost $0, but one assumed review minute at $30/hour adds $0.50. No input was sent for this or any other example.

The attempt records behind the subtotal

Synthetic attempt records: every token count and outcome below is invented. Provider amounts use hypothetical USD $1/million input and $4/million output rates. “Supported,” “refusal” and “parse failure” are scenario labels, not observations about a model.

Keep req-demo-05 in the product ledger even though it has no attempt row. Five requests happen to have five attempts: one request has two and another has none.

Synthetic request ledger: the provider column sums the hypothetical attempts above. Review minutes are invented and valued at USD $30/hour. Combined amounts include only those two cost categories.

The checked arithmetic is 5,000 assumed input tokens plus 950 assumed output tokens, giving $0.0088 at the invented provider rates; 7.5 assumed review minutes give $3.75; together they give $3.7588. This is not an all-in feature cost. Cached-input, reasoning, media, tool, service-tier and tax charges are not modelled; neither are hosting, engineering, support or other overheads.

For a real run, link provider records to product requests. OpenAI documents usage grouped by model, project and API key, and costs aggregated by time bucket. Reconcile those totals with the product ledger; they do not identify each job’s repair or review work. Usage and costs reference, checked 13 September 2026.

Five jobs, with a route for each

These fictional cases specify handling, not successful model calls, measured quality or customer tolerance.

req-demo-01: clear date

Input: “Expiry date: 2027-01-31.” Assume schema-valid, supported fields. Route: review, then accept if the reviewer confirms the source. Assumed review: 0.5 minutes.

req-demo-02: parse repair

Input: “Renewal date 2027-03-01”; the fictional response adds prose outside JSON. Route: one repair, then review—not automatic acceptance. Assumed review: 3 minutes.

req-demo-03: refusal

This is an invented provider-refusal branch, not a claim that a particular input triggers a policy. Route: manual handling, without blindly retrying the refusal. Assumed review: 1 minute.

req-demo-04: competing dates

Input: “Expiry: 2027-06-01; amended expiry: 2027-07-01,” with no precedence stated. Route: clarification, no reminder. Do not choose the later date merely because it looks plausible. Assumed review: 2 minutes.

req-demo-05: prohibited input scope

Input case: a raw identity document, outside the approved metadata-only scope. Route: block before any provider attempt and resolve manually within that boundary. Assumed review: 1 minute. Nothing is sent to an adapter.

Check the source before using the fields

The proposed output contract contains document_type, expiry_date as an ISO date or null, source_span, and route with the values review, clarify or manual. Use the source span to check whether the input supports the suggested date; a schema checks shape, not factual support.

Handle refusals, incomplete output and parse failures before consuming fields. OpenAI documents refusal and incomplete-response handling and warns that structured outputs can still contain mistakes. Structured Outputs, checked 13 September 2026.

For the competing dates in req-demo-04, the intended result is expiry_date=null and route=clarify, with both dates retained in the source span for review. That is a proposed handling rule, not generated output. None of the routes schedules an automatic reminder from unreviewed fields.

The proposed data path is approved metadata, input check, provider adapter, parser, then review queue. The raw identity document in req-demo-05 stops at the input check. A storage flag is not permission to widen that input scope: store=false is not a general zero-retention guarantee. OpenAI distinguishes application state from abuse-monitoring logs; retention depends on the endpoint and approved account controls. Verify that exact combination before sending authorised data. Data controls, checked 13 September 2026.

Keep metadata extraction; retain review

Keep the proposed feature at metadata extraction for review, with one parse-repair attempt. The routes above do not authorise reminders from unreviewed output.

Test those routes on an authorised, labelled workload, recording each attempt and actual review minute under its product request. OpenAI recommends task-specific evaluations. These five invented cases illustrate accounting; they cannot establish model quality, latency or release readiness. Evaluation best practices.

Evals portability note: OpenAI’s notice checked on 13 September 2026 schedules existing evals to become read-only on 31 October 2026 and the Evals dashboard and API to shut down on 30 November 2026. Both dates are future at that check; the notice does not cover every evaluation method. Evals platform notice. Preserve the cases, routing expectations and request joins independently of that dashboard.