Azure OpenAI Service Launches GPT-4 Turbo and GPT-3.5-Turbo-1106 Models

At Microsoft Ignite 2023, Satya Nadella previewed the next generation of OpenAI models coming to Azure. That preview turned into a real release soon after: GPT-4 Turbo and GPT-3.5 Turbo 1106 became available on Azure OpenAI Service for all existing customers, no waitlist involved. If you are already running production workloads on GPT-4 or GPT-3.5 Turbo, this release is worth a proper look, because the pricing and context window changes affect cost and architecture decisions, not just model quality.

What actually changed in GPT-4 Turbo

GPT-4 Turbo ships as gpt-4-1106-preview and its biggest change is the context window: 128K tokens, against 8K or 32K on the original GPT-4 deployments most teams were using. That is roughly 15 times more room for input text. For teams building retrieval augmented generation (RAG) applications, this matters more than it sounds. You can now pass much larger chunks of retrieved documents, longer conversation history, or bigger few-shot examples in a single call, without hitting context limit errors that used to force aggressive chunking and summarization.

Pricing dropped alongside the context increase. GPT-4 Turbo costs $0.01 per 1,000 input tokens and $0.03 per 1,000 output tokens, which Microsoft states as roughly 3x cheaper on input and 2x cheaper on output compared to standard GPT-4. Combined with the larger context window, this is a genuine shift in the cost equation for RAG, not a minor discount. Teams that avoided long-context RAG because of token cost now have a much stronger case to revisit that decision.

One detail worth knowing before you deploy: GPT-4 Turbo’s training data knowledge cutoff is April 2023. It does not automatically know about anything after that date unless you feed it through retrieval or tool calls. This is easy to forget when a model feels more capable overall, so do not assume improved reasoning also means fresher world knowledge.

Regional availability and deployment

GPT-4 Turbo (1106-preview) is available in nine Azure regions at launch: Australia East, Canada East, East US 2, France Central, Norway East, South India, Sweden Central, UK South, and West US. GPT-3.5 Turbo 1106 is available in seven of those, missing East US 2 and Norway East. Three of these regions, Norway East, South India, and West US, are entirely new to Azure OpenAI Service, bringing the total region count to 14. If your data residency requirements are tied to a specific region, check this list before you plan a migration, because not every existing GPT-4 region has the Turbo variant on day one.

Deployment itself is straightforward from Azure AI Studio. For GPT-4 Turbo, select the “gpt-4” model and choose version “1106-preview” from the version dropdown. For GPT-3.5, select “gpt-35-turbo” and pick version “1106”. A practical point that is easy to miss: these preview versions get their own separate quota from your existing GPT-4 or GPT-3.5 deployments. That means you can deploy and test 1106 models without eating into the quota your production deployments already depend on, which removes a common blocker to trying out new model versions in a live environment.

Improved and parallel function calling

Function calling has been available since June 2023, letting a model decide when to call an external tool or API based on a natural language prompt. GPT-4 Turbo improves the accuracy of generating these calls, but the more useful change for real applications is parallel tool calls: the model can now return multiple function calls in a single response instead of one at a time.

In practice, this cuts down round trips. If a user asks a question that needs both a weather lookup and a calendar check, older models would call one function, wait for your code to return a result, then decide whether to call the next one. With parallel calling, the model can request both in one response, and your application executes them together before sending results back. For chat assistants or agents that lean on multiple tools per turn, this reduces latency meaningfully. The trade-off is that your function-calling handler code needs updating to loop over an array of tool calls rather than assuming a single call, so treat this as a breaking change to your calling logic, not a drop-in upgrade.

JSON mode for structured output

JSON mode is a new response_format option that constrains the model to emit syntactically valid JSON. Before this, getting reliable JSON out of a chat model meant careful prompt engineering and defensive parsing, and it would still occasionally break on edge cases like trailing commas or unescaped quotes. JSON mode removes most of that fragility at the API level.

from openai import AzureOpenAI
 
client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-key>",
    api_version="2023-12-01-preview"
)
 
response = client.chat.completions.create(
    model="gpt-4-1106-preview",  # your deployment name
    response_format={"type": "json_object"},
    messages=[
        {"role": "system", "content": "You extract order details and reply only in json."},
        {"role": "user", "content": "Order #4471, 3 units of SKU-8821, ship to Pune."}
    ]
)
 
print(response.choices[0].message.content)

This call returns a JSON string you can parse directly with json.loads, something like {“order_id”: “4471”, “quantity”: 3, “sku”: “SKU-8821”, “destination”: “Pune”}. Two pitfalls are worth watching for here.

First, the API requires the word “json” to appear somewhere in your messages, in the system prompt or the user message, otherwise the call fails with an error. Second, JSON mode guarantees syntactically valid JSON, not a specific schema. The model can still choose different key names or nesting across calls unless you constrain the schema explicitly in your prompt. If you need a strict, predictable schema, describe the exact keys and types you expect directly in the system message.

Reproducible output with the seed parameter

Chat completions are probabilistic by design, which is exactly what you want for creative writing or brainstorming, but it becomes a problem when you are debugging a pipeline or writing tests against model output. GPT-4 Turbo introduces a seed parameter that lets you request more consistent output across repeated calls with the same input.

response = client.chat.completions.create(
    model="gpt-4-1106-preview",
    seed=42,
    messages=[
        {"role": "user", "content": "Summarize the key risks in this contract clause: ..."}
    ]
)
 
print(response.system_fingerprint)
print(response.choices[0].message.content)

Every response now includes a system_fingerprint value alongside the seed. If the fingerprint changes between two calls with the same seed, it usually means Microsoft updated the underlying model version, and you should expect output to shift slightly even with an identical seed. It is worth logging the fingerprint alongside your responses in any pipeline where output consistency matters, so you can tell whether a change in behaviour came from your prompt or from a backend model update. Also keep in mind Microsoft describes this as best effort determinism, not a hard guarantee, so do not build safety-critical logic that assumes byte-identical output every time.

GPT-3.5 Turbo 1106

GPT-3.5 Turbo 1106 (gpt-35-turbo-1106) carries the same function calling and JSON mode improvements down to the cheaper model tier, with a 16K context window. Pricing is $0.001 per 1,000 input tokens and $0.002 per 1,000 output tokens, again roughly 3x and 2x cheaper than the previous GPT-3.5 Turbo 16k pricing. Microsoft has stated this version becomes the new default GPT-3.5 Turbo deployment in the following weeks, so if you have automation or infrastructure that deploys “gpt-35-turbo” without pinning a version, expect it to shift under you eventually. Pinning the version explicitly in your deployment configuration is the safer choice if you need predictable behaviour.

Should you migrate now

For RAG applications specifically, the combination of a much larger context window and lower per-token cost makes GPT-4 Turbo worth testing against your existing GPT-4 deployment, especially if you were previously trimming or aggressively summarizing retrieved context to fit an 8K or 32K window. That said, this is a preview model (gpt-4-1106-preview), and Microsoft has been clear it will be replaced by a stable GA version, with existing preview deployments auto-upgraded when that happens. For teams that need strict version stability in production, it may be worth waiting for the GA release before switching your primary workload, while using the separate quota to run the preview in a staging environment in parallel.

The realistic cost saving is also worth verifying with your own numbers before assuming it applies uniformly. A 3x reduction on input tokens matters a lot for RAG-heavy applications where most of your token spend is retrieved context, but matters less for short-prompt, long-generation workloads like content drafting, where output tokens dominate the bill. Run the pricing math against your actual token distribution rather than the headline multiplier.