GPT-5.5 Spud isn’t verified—what OpenAI API economics actually show

Verdict: Spud economics are not public in this evidence set

One third-party page that discusses Spud explicitly labels release-timing and pricing expectations as speculation and says no official GPT-5.5 release date, model card, or API pricing has been announced ^[4]. That does not prove a model cannot exist internally; it does mean public claims about Spud pricing, latency, throughput, or token efficiency should not be treated as verified until official documentation exists.

What OpenAI actually documents

GPT-5.4 is the documented frontier model here

The strongest official model-specific claim in the reviewed materials is about GPT-5.4. OpenAI’s model index points readers to

Latest: GPT-5.4

[19]

[13]

GPT-5.4 also has a documented long-context pricing threshold. For models with a 1.05M context window, including GPT-5.4 and GPT-5.4 pro, prompts with more than 272K input tokens are priced at 2x input and 1.5x output for the full session across standard, batch, and flex usage ^[13]. For production teams, that makes context length a direct budget variable, not just a quality or convenience feature.

The visible pricing rows support GPT-5.4 and GPT-5.4-mini—not Spud

The provided OpenAI pricing excerpt shows visible rows for gpt-5.4 and gpt-5.4-mini. In one shown row group, gpt-5.4 appears alongside values such as

$2.50 / $0.25 / $15.00

$0.75 / $0.075 / $4.50

[1]

Because the excerpt does not include the table headers, those numbers should not be mapped with certainty to specific billing categories from this evidence alone. The safe conclusion is limited: the shown pricing rows include GPT-5.4 and GPT-5.4-mini, the mini values are lower in the visible comparisons, and no Spud pricing row is visible ^[1].

The useful inference-economics framework

1. Choose models by quality first, then cost and latency

OpenAI’s model-selection guidance frames model choice as a balance among accuracy, latency, and cost. It recommends establishing the required accuracy target first, then maintaining that target with the cheapest and fastest model that still works ^[25].

That is the core production rule. A newer or more powerful model name is not automatically the right model for a product path. The right model is the least expensive and lowest-latency option that clears the product’s evaluated quality bar ^[25].

2. Treat prompt caching as the verified token-efficiency lever

Prompt Caching is one of the clearest documented ways to improve effective input-token economics. OpenAI says it works automatically on API requests, requires no code changes, has no additional fees, and is enabled for recent models from gpt-4o onward ^[15].

OpenAI’s developer cookbook says Prompt Caching can reduce time-to-first-token latency by up to 80% and input token costs by up to 90% in eligible workloads. The same page says prompt_cache_key can improve routing stickiness for requests with the same prefix, and reports one coding customer improving cache hit rate from 60% to 87% after using it ^[24].

The practical takeaway is to keep stable prompt prefixes stable when product design allows it: shared system instructions, reusable policy text, common schemas, and repeated context blocks are the kinds of structures that can make caching more effective. That is a documented strategy for current OpenAI models; it is not evidence that Spud has a specific tokenizer advantage, cache discount, or tokens-per-second profile.

3. Measure latency instead of guessing from model rumors

Priority processing is a documented latency-oriented control. OpenAI says requests to the Responses or Completions endpoints can opt in with service_tier=priority, or Priority processing can be enabled at the Project level ^[35]. The provided excerpt does not quantify latency improvement, throughput impact, or price premium, so it should not be used to claim a specific service-level result for Spud or any other model ^[35].

OpenAI’s latency guidance also cautions that reducing input tokens can lower latency but is not usually a significant factor ^[22]. Separately, OpenAI’s model-selection cookbook says higher reasoning settings may use more tokens for deeper reasoning, increasing per-request cost and latency ^[32]. For production systems, that means latency should be measured end to end across the chosen model, reasoning settings, prompt shape, caching behavior, and service tier.

The supplied third-party benchmark sources do not solve the Spud question. They report provider metrics for GPT-5 mini and GPT-5, not GPT-5.5 Spud, so their latency and pricing numbers should not be transposed onto an unverified model ^[3][8].

4. Use Batch for asynchronous workloads, not interactive speed

OpenAI’s Batch API is documented as a separate asynchronous processing path. The provided Batch documentation shows a request with a completion_window of 24h and says completed batch output can be retrieved through the Files API using the batch object’s output_file_id ^[33]. The API reference also places Batch in a cost-optimization context ^[20].

That supports a practical architecture split: interactive requests should be optimized with model choice, prompt design, caching, and service tier; offline or asynchronous jobs can be candidates for Batch. It does not verify any Spud-specific batch discount, throughput guarantee, or turnaround advantage ^[20][33].

Production checklist for OpenAI API economics

1. Start with evals, not leaked model names. Define the minimum acceptable quality level, then test cheaper and faster models against that bar ^[25].
2. Budget against documented models. In this source set, GPT-5.4 is the documented latest model, and the visible pricing rows cover GPT-5.4 and GPT-5.4-mini—not Spud ^[19][1].
3. Watch long-context thresholds. For GPT-5.4 and GPT-5.4 pro on 1.05M-context models, prompts above 272K input tokens trigger higher pricing for the full session ^[13].
4. Design for prompt-cache hits. Prompt Caching is automatic and free on supported recent models, and OpenAI reports large possible reductions for eligible repeated-prefix workloads ^[15][24].
5. Reserve Priority processing for paths worth testing. The mechanism is documented for Responses and Completions, but the provided evidence does not quantify the performance gain ^[35].
6. Send suitable offline work to Batch. Batch is documented with a 24-hour completion-window example and output retrieval through the Files API, making it a better fit for asynchronous jobs than user-facing latency paths ^[33].
7. Do not transpose GPT-5 or GPT-5-mini benchmarks onto Spud. The benchmark sources reviewed here measure other named models, not GPT-5.5 Spud ^[3][8].

Bottom line

The reviewed evidence does not verify GPT-5.5 Spud as a public OpenAI API model, and it does not verify Spud-specific API pricing, token efficiency, latency, throughput, or benchmark performance. What it does verify is an OpenAI inference-economics playbook built around documented model selection, GPT-5.4 long-context pricing behavior, automatic Prompt Caching, Priority processing, and the Batch API ^{[25][13][15][35][33]}.

Until OpenAI publishes an official model page, pricing row, model card, and performance guidance for GPT-5.5 Spud, production teams should budget against documented models and treat Spud-specific economics claims as speculation.