fix(pricing): add the azure gpt-realtime-2 family and price realtime image input per token

[marty-sullivan]

TLDR

Problem this solves:

• Three azure realtime models have no cost map entry
• Realtime image input bills at the text rate, not its own
• The openai-direct gpt-realtime-2 entry is stale

How it solves it:

• Add azure/gpt-realtime-2, -2.1 and -2.1-mini
• Move the image rate onto the field the calculator reads
• Reconcile gpt-realtime-2 to its published limits and rate

User Flow

Before: a developer sending a photo into a realtime session is charged the text rate for it, so their spend understates what the vendor charges

1. They open a WebSocket to wss://litellm-domain/v1/realtime?model=gpt-realtime-2.1-mini
2. They send a conversation.item.create carrying an input_image content part and ask about it
3. The model describes the image, and the session reports back input_token_details with image_tokens: 194
4. They open https://litellm-domain/ui/?page=logs and the request's input cost is $0.00020940, which is those 194 tokens charged at the $0.60/1M text rate
5. Anyone on azure/gpt-realtime-2, -2.1 or -2.1-mini gets no spend row at all, because the model resolves to no entry

After: image tokens are charged at the image rate, and the three new models are priced

1. They open a WebSocket to wss://litellm-domain/v1/realtime?model=gpt-realtime-2.1-mini
2. They send a conversation.item.create carrying an input_image content part and ask about it
3. The model describes the image, and the session reports back input_token_details with image_tokens: 194
4. The same request now shows an input cost of $0.00024820, the 194 tokens at the $0.80/1M image rate
5. azure/gpt-realtime-2, -2.1 and -2.1-mini resolve and bill

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

The image rate was on a field nothing reads. These entries carry image input cost as input_cost_per_image, which is the per-image field used by generation models. The token calculator reads input_cost_per_image_token, so image tokens fell through to input_cost_per_token and were charged the text rate. Same usage, same entry, only the field name changed:

input_cost_per_image        = 8e-07   ->  input cost $0.00020940   (image at the text rate)
input_cost_per_image_token  = 8e-07   ->  input cost $0.00024820   (image at its own rate)

Confirmed on a real realtime session against a live gateway. Azure does accept image input on this API, and the session reported the split itself:

input_token_details: {"text_tokens": 145, "audio_tokens": 0, "image_tokens": 194,
                      "cached_tokens": 128, "cached_tokens_details": {"text_tokens": 128}}

Reading the resulting spend row back, the input cost reconciles to the reported split exactly, at the rate each modality should pay:

mode    reported split                                 billed input   expected
text    128 cached                                     $0.00000768    $0.00000768   EXACT
image   17 text + 128 cached + 194 image               $0.00024220    $0.00024220   EXACT
audio   62 text + 64 cached + 39 audio                 $0.00046560    $0.00046560   EXACT

The image row is the one that moves: before this change it billed $0.00020940 for the same tokens. Text and audio are unchanged, so nothing that was already correct shifted.

This adds up faster than a single photo suggests. A realtime session has no video content type, so a camera feed is sent as a sequence of image parts: four consecutive frames reported 776 image tokens, 194 apiece. At the text rate that stream is billed at roughly three quarters of what it should be, and it scales with frame rate.

Rates come from Azure's meters, not OpenAI's price card. Azure prices its OpenAI models independently, so the values were checked against the retail prices API for the Global tier, per 1M tokens:

gpt-realtime-2         Text inp 4.00   Text opt 24.00   Image inp 5.00   Text cd inp 0.40
gpt-realtime-2.1       Text inp 4.00   Text opt 24.00   Image inp 5.00   Audio inp 32.00 / opt 64.00
gpt-realtime-2.1-mini  Text inp 0.60   Text opt  2.40   Image inp 0.80   Audio inp 10.00 / opt 20.00

The Data Zone meters are exactly 1.1x Global on every dimension, which is the expected relationship and a signal the rows are live rather than stale. These agree with OpenAI's published realtime rates, but the meters are what an azure/ key should follow.

Resolution check on the updated map:

azure/gpt-realtime-2                 image 5e-06   out 2.4e-05   in 32000 / out 4096
azure/gpt-realtime-2.1               image 5e-06   out 2.4e-05   in 32000 / out 4096
azure/gpt-realtime-2.1-mini          image 8e-07   out 2.4e-06   in 32000 / out 4096
azure/gpt-realtime-2025-08-28        image 5e-06   out 1.6e-05
azure/gpt-realtime-1.5-2026-02-23    image 5e-06   out 1.6e-05
azure/gpt-realtime-mini-2025-10-06   image 8e-07   out 2.4e-06
gpt-realtime-2                       out 2.4e-05   in 128000 / out 32000

Type

🐛 Bug Fix

Changes

Adds azure/gpt-realtime-2, azure/gpt-realtime-2.1 and azure/gpt-realtime-2.1-mini to both cost map files.

Renames input_cost_per_image to input_cost_per_image_token on the six azure/gpt-realtime entries, so image tokens are priced at the image rate instead of falling back to text. The values were already correct.

Carries forward the gpt-realtime-2 reconciliation from review: 32k context / 4096 output / $16 output to 128k / 32000 / $24, agreeing with the azure entry and both vendors' published rate.

The azure entries use Azure's 32000 input / 4096 output request limits while the openai-direct entries keep 128000 / 32000. Azure's Realtime API caps a single response at 4096 even though the context window is 128k, so the two providers legitimately differ; this is the correction made earlier in this PR's review and it supersedes the 128k/32000 figures an earlier revision of this description quoted for the azure entries.

Rebuilt on litellm_internal_staging. This branch previously targeted litellm_oss_daily_2026_07_10 and no daily branch has been cut since 2026_07_20. Rebuilding also picks up mode: realtime, which staging had since corrected on the sibling entries.

No new test, per the cost-map convention; the existing cost suite is the verification.

Caveats (if any)

• openai/gpt-realtime-2.1-mini still carries max_output_tokens 4096
• The bare gpt-realtime* entries keep the inert per-image field
• Both left out to keep this PR to the azure family

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[marty-sullivan]

@greptileai

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing cu-aaii:add-azure-gpt-realtime-2-pricing (06348cc) with litellm_internal_staging (973329e)}

[greptile-apps]

Greptile Summary

This PR fixes image-token pricing for Azure realtime models and adds three missing azure/gpt-realtime-2 family entries to the cost map. It also reconciles the gpt-realtime-2 (openai-direct) entry with its published context window, output limit, and output rate.

• Renames input_cost_per_image → input_cost_per_image_token on three existing azure realtime entries (azure/gpt-realtime-2025-08-28, azure/gpt-realtime-1.5-2026-02-23, azure/gpt-realtime-mini-2025-10-06), so image tokens are billed at the image rate instead of falling through to the text rate.
• Adds azure/gpt-realtime-2, azure/gpt-realtime-2.1, and azure/gpt-realtime-2.1-mini with rates sourced from Azure's retail pricing API (Global tier); the new entries use input_cost_per_image_token from the start.
• Updates gpt-realtime-2 (openai) from 32k/4096 context/output to 128k/32000, and corrects the output text rate from $16/M to $24/M to match the published rate.

Confidence Score: 5/5

• Safe to merge — all changes are confined to the two cost-map JSON files, the field renames and new entries are consistent with the established azure realtime pattern, and the rates are verified against Azure's retail pricing API.
• The diff is data-only: a field rename on three existing azure entries, three new azure model entries, and a limit/rate correction on one openai entry. The renames use the field name the cost calculator already reads, so no code path changes. The new entries follow the exact structure of the sibling azure realtime entries. Both files are kept in sync. No logic, auth, or request-path code is touched.
• No files require special attention.

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Renames input_cost_per_image → input_cost_per_image_token on three existing azure realtime entries, adds three new azure/gpt-realtime-2 family entries, and corrects gpt-realtime-2 (openai) context/output limits and output rate. All values verified against Azure's retail pricing API.
litellm/model_prices_and_context_window_backup.json	Mirror of the root JSON with identical changes — field renames, new azure entries, and gpt-realtime-2 limit corrections are kept in sync between both files.

_{Reviews (7): Last reviewed commit: "fix(pricing): add the azure gpt-realtime..." | Re-trigger Greptile}

[greptile-apps]

Greptile Summary

This PR updates the model cost maps for gpt-realtime-2. The main changes are:

• Adds azure/gpt-realtime-2 pricing and capability metadata
• Updates OpenAI gpt-realtime-2 context, output-token, and text-output pricing values
• Mirrors the same pricing-map changes in the packaged backup JSON

Confidence Score: 4/5

The pricing-map change is isolated, but the Azure output-token limit needs correction before merge.

The modified JSON entries are straightforward and duplicated consistently, while the Azure metadata appears to advertise a larger output limit than the provider catalog allows.

model_prices_and_context_window.json and litellm/model_prices_and_context_window_backup.json

T-Rex Logs

What T-Rex did

• T-Rex created and ran trex-artifacts/repro_azure_gpt_realtime_2_limits.py to reproduce Azure gpt-realtime-2.
• The initial repro attempts were blocked by missing Python dependencies and by LiteLLM not resolving gpt-realtime-2 with custom_llm_provider='azure'.
• A public Microsoft search found the gpt-realtime-2 Foundry catalog entry indicating a 128k context window and 4096 token output limits.
• The step budget limit prevented saving a structured catalog trace artifact before the run completed.
• Before and after map checks show azure/gpt-realtime-2 was ABSENT before and PRESENT after.
• HTTP-style status remained 200 OK and token cost fields were updated in the after-state.
• Head run shows both azure/gpt-realtime-2 and gpt-realtime-2 present in the JSON maps with matching fields; summary failures remain 0.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(pricing): add azure/gpt-realtime-2 a..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[marty-sullivan]

Fixed in 08e05df. The P1 was right: realtime output is capped at 4096, not 32000. Microsoft Foundry's catalog and the Azure OpenAI Realtime API docs both cap realtime output at 4096 tokens, matching every other realtime sibling in the map (gpt-realtime, gpt-realtime-1.5, gpt-realtime-mini), so max_output_tokens and max_tokens are now 4096 for both azure/gpt-realtime-2 and the openai gpt-realtime-2 correction. The 128k context window and the $24/1M text output price are unchanged

@greptileai

[greptile-apps]

The fix looks correct. Both files are updated consistently:

• max_output_tokens and max_tokens are 4096 for azure/gpt-realtime-2 — matching every other realtime sibling in the map
• openai/gpt-realtime-2 corrections: max_input_tokens bumped from 32000 → 128000, output_cost_per_token from 1.6e-05 → 2.4e-05
• Both JSON files (model_prices_and_context_window.json and the backup) are updated identically

The azure/gpt-realtime-2 entry is also correctly structured with cache_read_input_token_cost: 4e-07 ($0.40/1M), matching the Azure published rate for cached text input. Everything aligns with the sibling entries. LGTM.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[marty-sullivan]

@greptileai can you also revisit your original review and update confidence score if everything is now in order?

[yuneng-berri]

Hey, thanks for the contribution. A few things to confirm before I can sign off on this:

• max_output_tokens is 4096 on all three, but OpenAI documents 32000 for gpt-realtime-2, 2.1, and 2.1-mini. Can you please confirm: https://developers.openai.com/api/docs/models/gpt-realtime-2.1-mini
• your azure/gpt-realtime-2 ($24 output / 128k context) is correct, but it now disagrees with the existing openai/gpt-realtime-2

[marty-sullivan]

@yuneng-berri thanks for the review, both confirmed and fixed in a34bce1

On the output limit: you're right. OpenAI documents gpt-realtime-2, gpt-realtime-2.1, and gpt-realtime-2.1-mini at a 128k context window and 32000 max output tokens (the mini included), so max_output_tokens and max_tokens on all three azure entries now move from 4096 to 32000, matching the openai gpt-realtime-2.1 entry already in the map. My earlier 4096 came from an automated review suggestion citing the Foundry catalog's token-limits line, which turned out to be wrong for this generation

On the disagreement: I corrected the existing openai/gpt-realtime-2 entry to 128k context, 32000 output, and $24/1M text output so it agrees with azure/gpt-realtime-2 and OpenAI's published rate; it had been stale at 32k context / 4096 output / $16 output

Resolved values after the fix (get_model_info against the updated map):

azure/gpt-realtime-2         in=128000 out=32000 out $/1M=24.00
azure/gpt-realtime-2.1       in=128000 out=32000 out $/1M=24.00
azure/gpt-realtime-2.1-mini  in=128000 out=32000 out $/1M= 2.40
gpt-realtime-2               in=128000 out=32000 out $/1M=24.00
gpt-realtime-2.1             in=128000 out=32000 out $/1M=24.00

A live realtime call to confirm isn't practical to include here, so the above is the resolver reading the corrected entries

One thing to flag while we're here: openai/gpt-realtime-2.1-mini (added separately, not in this PR) still carries max_output_tokens 4096, so by the same reasoning it now disagrees with azure/gpt-realtime-2.1-mini at 32000. I left it out to keep this PR scoped to the azure additions plus the gpt-realtime-2 reconciliation you asked for, but I'm happy to correct it here too if you'd prefer them consistent in one go

[yuneng-berri]

https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure?pivots=azure-openai#gpt-4o-audio-models

azure realtime model's max_input_tokens looks wrong. The docs are at 32000

[marty-sullivan]

@yuneng-berri good catch, fixed in a0aeadc

You're right. Azure's Foundry model table lists gpt-realtime-2, -2.1, and -2.1-mini with a 128k context window but max request limits of 32000 input and 4096 output, and every azure realtime sibling already in the map (azure/gpt-realtime-2025-08-28, azure/gpt-realtime-mini-2025-10-06, azure/gpt-realtime-1.5-*) uses 32000 / 4096. So the three azure entries now use max_input_tokens 32000 and max_output_tokens / max_tokens 4096

That also means my earlier bump of the azure output to 32000 was off: I applied OpenAI's 32000 output figure to the azure entries, but Azure's Realtime API caps a single response at 4096. The openai entries keep 128k context / 32000 output per OpenAI's own docs, so azure and openai legitimately differ on these limits. Pricing is unchanged

Resolved values after the fix (get_model_info against the updated map):

azure/gpt-realtime-2         in=32000  out=4096
azure/gpt-realtime-2.1       in=32000  out=4096
azure/gpt-realtime-2.1-mini  in=32000  out=4096
gpt-realtime-2               in=128000 out=32000
gpt-realtime-2.1             in=128000 out=32000

[CLAassistant]

All committers have signed the CLA.

[marty-sullivan]

@greptileai

[devin-ai-integration]

Superseded by rolling registry audit #37902, which reverified and absorbed the provider-documented metadata changes at field level

[marty-sullivan]

@mateo-berri Could a maintainer reopen this? #37902 closed unmerged, so nothing was absorbed, and utils.py:672 still falls back to the text rate

[mateo-berri]

Reopened

Sorry about closing this. Since staging already has the gpt-realtime-2 limits, please rebase onto litellm_internal_staging and happy to merge this once it's green. Thank you for the contribution

[devin-ai-integration]

Superseded by the rolling registry PR #39388, which already carries these Azure realtime entries and the image token pricing fields

[mateo-berri]

Closing as superseded: every field this PR adds or changes landed with the same values in #39388, plus sources and retirement dates.