OpenAI announced on November 10, 2026, that GPT-6 Luna inference residency is generally available in India, Japan and Australia. For supported API requests, the company says request processing and model inference happen in the selected country. The announcement covers the Responses and Chat Completions APIs, accepting text and image inputs and returning text. OpenAI’s release notes identify both the launch date and the supported request types.
The practical change is the location of computation. Storing customer content locally and running a model locally are separate requirements. This option can clear a deployment barrier for organizations whose policies require supported AI processing to happen in-country, provided their accounts and workloads qualify.
Access is conditional: OpenAI instructs organizations with approved, active Zero Data Retention, or ZDR, to create a regional API project and choose Storage & Processing.
What the Residency Announcement Covers
OpenAI’s release notes say that, for supported requests:
“both request processing and model inference take place in the country you select.”
The documented scope is specific:
| Component | Announced support |
|---|---|
| Model | GPT-6 Luna |
| Countries | India, Japan and Australia |
| APIs | Responses and Chat Completions |
| Inputs | Text and images |
| Output | Text |
| Required project configuration | Regional project with Storage & Processing |
OpenAI’s API data-controls documentation also lists the three countries for GPT-6 Luna regional processing. The dated release notes establish the November 10 announcement; the documentation is the place to check the current support matrix before deployment.
An image-input request that returns a written description fits the announced input/output combination. Image generation, audio output and other model families are outside the scope described in this announcement.
My view is that the request path is the useful unit of review. An application described internally as a “text assistant” may still use image inputs, hosted search or other services. Its label tells a compliance team much less than an inventory of the calls it actually makes.
How to Create a Regional Project
OpenAI’s setup instruction begins with eligibility, not an endpoint change. An organization must already have approved, active ZDR before following the regional-project path in the release notes.
For an eligible organization, the configuration sequence is:
- Confirm that ZDR is active for the organization. Approval status is account-specific.
- Create a new regional API project in India, Japan or Australia.
- Select Storage & Processing for the chosen country.
- Configure the application to use that regional project and its matching endpoint.
- Check every request against the supported model, API, input and output combinations.
ByteForward’s November 12 walkthrough lists these regional hostnames:
| Selected country | Regional API hostname |
|---|---|
| India | in.api.openai.com |
| Japan | jp.api.openai.com |
| Australia | au.api.openai.com |
Those are API hostnames, not additional project settings. Confirm the matching configuration against OpenAI’s current data-controls documentation and your account’s available options before changing production traffic.
ByteForward’s reading of the documentation adds several important restrictions: Modified Abuse Monitoring alone is insufficient; non-U.S. residency also requires approval for abuse-monitoring controls and a Modified Retention amendment. It reports that only Standard pay-as-you-go is supported, hosted tools are unavailable, and image support requires enhanced retention-control approval. These details deserve explicit verification during account setup, especially if an existing integration already uses images or tools.
I’d make eligibility confirmation the first migration task. Reworking an integration before checking its service tier, retention approvals and tool dependencies risks producing a technically valid application that cannot use the intended regional configuration.
Budget for the 10% Regional Processing Uplift
OpenAI’s API pricing documentation specifies a 10% uplift for regional processing endpoints on models released on or after March 5, 2026. The published rule applies to GPT-6 Luna regional processing.
ByteForward reports Standard GPT-6 Luna list rates of $0.10 per million input tokens and $0.50 per million output tokens. Applying the regional uplift produces the following calculation:
| Token category | Reported standard rate per 1 million tokens | Rate after 10% uplift |
|---|---|---|
| Uncached input | $0.10 | $0.11 |
| Output | $0.50 | $0.55 |
The base rates come from ByteForward’s published pricing analysis; the uplift rule comes from OpenAI. These are public-price calculations, not a customer quote.
For a hypothetical workload using one million uncached input tokens and one million output tokens, those token charges rise from $0.60 to $0.66, before taxes or other applicable charges.
That six-cent example illustrates the arithmetic, not a typical monthly bill. Forecast input and output volumes separately: the quoted output rate is five times the uncached input rate, so long generated answers can affect costs substantially. Any caching assumptions, negotiated terms or separately billed services should be checked against the actual workload.
The simplest budgeting formula is to multiply applicable token charges by 1.10, while keeping charges outside that calculation separate.
Regional Inference Has a Defined Boundary
Frequently Asked Questions
3 questions
1Can Any API Organization Enable Regional Inference?
No. OpenAI’s announcement requires approved, active Zero Data Retention. Additional approvals and workload restrictions should be confirmed for the account before creating the regional deployment.
