The Price of a Second

TL;DR.

On October 8, 2026, OpenAI rolled out Ultrafast for GPT-6.1 Sol in the API, Codex and ChatGPT Work. It's the same model, streamed faster, at $12 per million input tokens and $60 per million output. That's six times the Standard rate of $2 and $10. At those prices, Sol Ultrafast costs more per token than GPT-6 Astra at Standard, OpenAI's flagship, at $10 and $50.

The headline compares price to price. The comparison that matters is price to time. Ultrafast doesn't sell tokens, it sells seconds, so the useful question is what each second costs:

• On a 3,000-token code answer, Ultrafast saves about 30 seconds for $0.17. That's about $21 per hour of waiting removed, cheap if an engineer is sitting there.
• On an agent turn with 100K tokens of cached context and 800 tokens out, it's about $64 per hour.
• On a 50K-token extraction with a 200-token answer, it's about $934 per hour, because you pay 6x on every input token to speed up a few output tokens.
• On a subagent that isn't the slowest branch of a fan-out, it's infinite: 6x the price and zero seconds saved on the run.

Same model, same tier, a 90x spread in what the speed costs. This post covers what Ultrafast is, how to price a second for your own traffic, where speed pays and where it's pure markup, and a 30-line Python tier picker that prices the wait in with the tokens.

Prices are OpenAI list prices for GPT-6.1 Sol as of October 11, 2026. Speeds come from a small independent test, not from OpenAI, which publishes no guaranteed rate. The worked examples are illustrative, not Nadir customer data.

What shipped.

Ultrafast was announced at DevDay on September 29 alongside GPT-6.1 Sol, available on GPT-6 Astra first, with Sol "coming soon". Sol got it on October 8. OpenAI describes it as "near-Astra intelligence at up to 8x faster speeds" and quoted "as much as 300 tokens per second" at DevDay, with up to 8x in Codex and 6x in the API.

There's no new model behind it. Ultrafast is a service tier: the same request to the same GPT-6.1 Sol, on faster serving capacity, billed at a 6x multiple. Community reports show Codex selecting it with service_tier = "ultrafast", the same field OpenAI already uses for Flex and Fast.

That makes Sol's price list a four-step ladder with a 12x spread, all on one model:

Two details on the rate card bite harder at 6x. The long-context rule still applies: above 272,000 input tokens, the whole request bills at long-context rates, which for Ultrafast means $24 input and $90 output. We covered that cliff in the 272K pricing cliff. And the cache discount is a ratio, not a floor: cached input on Ultrafast is $0.60, six times Standard's $0.10, so a long cached prefix gets six times more expensive too.

On subscriptions, Ultrafast in Codex and ChatGPT Work is limited to the $500 Pro tier and eligible Enterprise and Edu plans at launch. Kingy AI's write-up reports it draws down included limits at 8x the Standard rate, and bills purchased credits at 6x.

Speed is the product, so price the speed.

Kingy AI ran the first public paired test on launch day: four matched Standard and Ultrafast pairs per task on GPT-6.1 Sol at medium reasoning effort.

Two things stand out. First, the measured end-to-end gain is closer to 4x than 6x or 8x: output did stream at roughly the 300 tokens per second OpenAI advertised, but a request is more than its decode. Second, quality didn't change, which is what you'd expect from the same model. So you're paying for time and nothing else.

That makes the comparison easy to write down. For any request:

implied hourly rate = (Ultrafast cost − Standard cost) ÷ seconds saved × 3,600

That's the price Ultrafast charges you per hour of waiting it removes. Compare it with what an hour of waiting costs you. If a $150-an-hour engineer is blocked on the answer, anything under $150 is a bargain. If nobody is waiting, any rate is too high.

Here's what one 3,000-token response looks like on each tier:

The hourly rate depends on the shape of the request.

Run the formula across request shapes and the spread is enormous:

Illustrative. Seconds saved counts output streaming only, at 75 and 285 tokens per second. If Ultrafast also shortens prefill on long inputs, the rates for input-heavy rows fall; measure your own.

The pattern is the whole point: Ultrafast multiplies the price of every token but only speeds up the ones you wait for. Input tokens cost 6x and arrive no faster from your point of view. Output tokens, including hidden reasoning tokens, are where the seconds come back. So the hourly rate is mostly a function of one ratio, output tokens to input tokens:

• Output-heavy requests are cheap seconds. Code generation, long answers, drafts, and anything with a lot of reasoning. Reasoning tokens bill as output and stream at the Ultrafast rate, so high reasoning effort makes the speedup bigger, not just the bill.
• Input-heavy requests are expensive seconds. Classification, extraction, RAG answers, review over a big diff: a large prompt, a short reply. You pay 6x on the prompt to shave a second or two off the reply.
• Long cached prefixes sit in between. Agent turns re-send 100K+ tokens of context. Even cached, that's $0.06 per turn on Ultrafast against $0.01, which is why the agent-turn rate is three times the code-answer rate.

Fast, the 2x tier, is worth a look before you jump to 6x. If Fast gives Sol roughly 2x faster output, which is our assumption here since OpenAI hasn't published a figure for it, the code answer drops from 40 seconds to 20 for $0.034 extra, about $6 per hour. The step from Fast to Ultrafast then buys the remaining 9.5 seconds at about $52 per hour, and on the agent turn the last 2.5 seconds cost about $159 per hour. The first seconds are cheap and the last ones are expensive, so the right tier is often the middle one.

Who is actually waiting?

The hourly rate is only half the comparison. The other half is the cost of the wait, and that's zero more often than people think.

The subagent row is the one most teams will get wrong, because the setting is usually global. In an agent that fans out, the run's wall clock is set by the slowest branch, not by every branch:

Put all five subagents on Ultrafast and you pay 6x on five branches to shorten one. Four of them were going to finish early and sit idle anyway. The effective hourly rate on those four is infinite. The serial steps, planning and synthesis, are where speed shortens the run. We broke down where multi-agent token spend goes in the 15x multi-agent tax. Ultrafast adds a second multiplier on top.

There's a softer version of the same trap in interactive tools. An engineer who kicks off a long agent run and switches to Slack isn't waiting on the tokens. Speeding up a run nobody is watching saves seconds that weren't worth anything.

Tutorial: price the wait in with the tokens.

The tier decision is a small optimization: for each request, pick the tier with the lowest token cost plus waiting cost. You need three inputs per call: an estimate of input and output tokens, the cost of an hour of waiting for whoever is blocked, and whether the call is on the critical path.

Step 1: the rate card and your speeds.

# GPT-6.1 Sol list prices, $ per 1M tokens, prompts up to 272K input tokens.
PRICES = {
    "flex":      {"in": 1.00,  "cached": 0.05, "out": 5.00},
    "default":   {"in": 2.00,  "cached": 0.10, "out": 10.00},
    "fast":      {"in": 4.00,  "cached": 0.20, "out": 20.00},
    "ultrafast": {"in": 12.00, "cached": 0.60, "out": 60.00},
}
# Output tokens per second. Standard and Ultrafast are from a small public
# test; Fast is an assumption. Replace all three with your own p50s.
SPEED = {"default": 75, "fast": 150, "ultrafast": 285}
LONG_CONTEXT = 272_000  # above this, the whole request bills at long rates


def token_cost(tier, fresh, cached, out):
    p = PRICES[tier]
    in_mult, out_mult = (2.0, 1.5) if fresh + cached > LONG_CONTEXT else (1.0, 1.0)
    return (fresh * p["in"] * in_mult + cached * p["cached"] * in_mult
            + out * p["out"] * out_mult) / 1e6

SPEED is the number that matters most and the one you shouldn't take from a blog post. Log time to first token and output tokens per second per tier for a day of real traffic, and use your own medians.

Step 2: minimize tokens plus waiting.

def pick_tier(fresh, cached, out, wait_per_hour, on_critical_path=True):
    """Cheapest tier once waiting is priced in.

    out counts reasoning tokens too: they bill and stream like output.
    wait_per_hour is what a blocked hour costs whoever is waiting:
    0 for a nightly job, a loaded salary for an engineer at the prompt.
    """
    if wait_per_hour == 0:
        return "flex", token_cost("flex", fresh, cached, out)
    if not on_critical_path:  # a parallel branch that finishes before the slowest one
        return "default", token_cost("default", fresh, cached, out)
    best = None
    for tier in SPEED:
        total = token_cost(tier, fresh, cached, out) + out / SPEED[tier] * wait_per_hour / 3600
        if best is None or total < best[1]:
            best = (tier, total)
    return best

Step 3: run it on real shapes.

cases = [  # name, fresh input, cached input, output, $/hour of waiting, critical path
    ("codegen, engineer waiting",     2_000,   0,       3_000,  150, True),
    ("agent turn, engineer waiting",  5_000,   100_000, 800,    150, True),
    ("extraction, engineer waiting",  50_000,  0,       200,    150, True),
    ("long review, engineer waiting", 300_000, 0,       10_000, 150, True),
    ("agent turn, support customer",  5_000,   100_000, 800,    40,  True),
    ("parallel subagent",             5_000,   100_000, 800,    150, False),
    ("nightly eval",                  5_000,   0,       800,    0,   True),
]
for name, fresh, cached, out, wait, critical in cases:
    tier, total = pick_tier(fresh, cached, out, wait, critical)
    print(f"{name:32s} {tier:10s} ${total:.4f}")

codegen, engineer waiting        ultrafast  $0.6426
agent turn, engineer waiting     fast       $0.2782
extraction, engineer waiting     default    $0.2131
long review, engineer waiting    fast       $5.4778
agent turn, support customer     fast       $0.1153
parallel subagent                default    $0.0280
nightly eval                     flex       $0.0090

Seven requests, four different tiers, and Ultrafast wins once. The totals include the priced wait, which is why they're larger than the token bills. For the code answer, Ultrafast's $0.204 in tokens plus 10.5 seconds of a $150 engineer comes to $0.64, against $1.70 on Standard once the 40-second wait is counted. For the extraction, Standard wins outright: the 6x premium on 50K input tokens costs more than the two seconds are worth.

Step 4: wire it in, with a fallback.

Pass the chosen tier in the request's service_tier field, the same one OpenAI's Fast and Flex tiers use. Then log the tier the response reports, not the one you asked for. Billing follows the tier that actually served the call, and we covered the fallback rules, Flex 429s included, in four prices, one model. Two guardrails are worth adding on day one:

• Cap Ultrafast by budget, not by habit. Give it a daily dollar ceiling per team and fall back to Fast when it's spent. A 6x tier as the silent default is exactly how a team ends up budget bankrupt by the 20th.
• Re-check the estimate after the fact. If a request you sent Ultrafast came back with 150 output tokens, the speed bought almost nothing. Track realized implied rate per route weekly, and move routes that run over your threshold back to Standard.

What doesn't transfer.

• Speeds vary. The test behind our numbers is four to eight pairs per task, on one day, with frozen inputs. OpenAI promises no tokens-per-second rate for Sol, and Ultrafast capacity may behave differently under load or in another region.
• Fast's speed for Sol is our assumption. The 2x figure is a placeholder. If Fast is slower than that on your traffic, Ultrafast wins more often.
• The cost of waiting is a judgment call. A loaded salary is a floor for a blocked engineer. Flow and focus are worth more and are hard to price. A voice agent's cost of silence is closer to a dropped call than to a salary.
• Prices move. Ultrafast is three days old on Sol, and OpenAI has cut Sol prices twice since July, so re-run the numbers when the rate card changes.

Where Nadir fits.

Ultrafast is one more case of the pattern that runs through most of this blog: a price that used to be one number per model is now several numbers per request, and the right one depends on the request. Tier is a per-request decision just like model choice, and it uses the same inputs: how big the prompt is, how much output the task needs, and who is waiting on it.

Nadir makes the model decision today. Send model="auto" and Nadir's trained classifier reads each prompt and picks the model from the ones you've configured, against the quality floor you set on the API key, with the routing decision and cost reported in each response's metadata. That matters for speed too: a prompt simple enough for a smaller, cheaper model doesn't need Sol at all, at any tier. The cheapest fast second is often the one you never spend on a big model.

The tier itself stays your call, which is where the pick_tier rule above fits. If you'd rather keep calling OpenAI directly, POST /v1/bucket returns simple, medium or complex with a probability for each, so your harness can send simple requests to a small model, keep complex ones on Sol, and spend Ultrafast only where a person is waiting on the critical path.

To see what per-request routing would change on your traffic before it changes anything, Observe mode records the decision Nadir would make on every request without altering a single response. Start with a free key.

Conclusion.

Ultrafast is a fair product with a misleading headline. It doesn't make Sol six times more expensive. It sells you back waiting time at a rate that ranges from about $11 an hour, for output-heavy work with an engineer watching, to infinity, for a subagent nobody is waiting on. Price the second, not the token: estimate output against input, know who's waiting, check the critical path, and let the cheaper tiers take everything else. The teams that set service_tier = "ultrafast" globally will be the case study in next quarter's budget post.

Sources: OpenAI Developer Community, ["Ultrafast is rolling out today for GPT-6.1 Sol in the API, Codex and ChatGPT Work"](https://community.openai.com/t/ultrafast-is-rolling-out-today-for-gpt-6-1-sol-in-the-api-codex-and-chatgpt-work/1404475), October 8, 2026; VentureBeat, ["OpenAI's GPT-6.1 Sol offers Astra-like performance at 1/5th price"](https://venturebeat.com/technology/openais-gpt-6-1-sol-offers-astra-like-performance-at-1-5th-price-a-new-ultrafast-tier-clocks-at-300-tokens-per-second), September 29, 2026; Kingy AI, ["GPT-6.1 Sol Ultrafast: Speed, Pricing, Plans & Value"](https://kingy.ai/blog/gpt-6-1-sol-ultrafast-speed-pricing-value/), October 8, 2026, for the paired test, the tier rate card and plan details. Found via [Token Cost Radar](https://jcodemunch.com/radar/2026-10-10), October 10, 2026. Implied hourly rates, request shapes and the Fast speed are our own illustrative calculations, not OpenAI's or Kingy AI's figures.