OpenAI's API can now run inference for GPT-6 Luna inside Japan. Takehiro Ogino of OpenAI Japan announced the change on November 11, 2026, in a post on his own account. Since May 2025, OpenAI has let eligible API customers store data in Japan. With this update, they can also specify Japan as the place where the model processes inputs and generates responses. For companies that have hesitated to adopt the API because of cross-border data transfers or processing locations, this is a new option.
However, using in-country inference in Japan requires Zero Data Retention (ZDR) approved by OpenAI. ZDR mainly limits the storage of customer content in abuse-monitoring logs, but it does not mean that no data is retained by any API feature. With the standard Responses API, responses may be stored depending on settings, and conversation history and uploaded files are subject to separate retention conditions. Companies handling confidential information need to understand not only where inference runs, but also how each feature stores data.
GPT-6 Luna inference now available in Japan, following in-country storage
In its official announcement on May 7, 2025, OpenAI introduced data residency support in Japan, India, Singapore, and South Korea. Eligible API customers can choose a storage region when creating a project and keep the customer content needed for API operation in that region. At that time, however, the feature mainly specified where data was stored. It did not guarantee that the model's inference would also take place in the country.
The difference between the "storage region" and the "inference region" matters for this update. The storage region specifies where customer content is kept when the API needs to retain it. The inference region specifies where the model processes inputs and generates responses. In OpenAI's regional support table, Japan is now listed as supporting both. Not every API feature or model that supports in-country storage also supports in-country inference, however.
As of November 12, 2026, GPT-6 Luna is the only model that supports inference in Japan. Users connect from a Japan-region project to the regional endpoint jp.api.openai.com and call the model with ZDR enabled. The supported APIs are the Responses API and the Chat Completions API, and configurations that take text or images as input and produce text as output are available.
Image input also requires approval for "enhanced ZDR" or "enhanced Modified Abuse Monitoring (MAM)," separate from standard ZDR. Because active ZDR is mandatory for in-country inference in Japan, additional approval for image input alone does not satisfy the requirement. In-country inference is also limited to the Standard pay-as-you-go tier, and hosted tools operated by OpenAI are not covered. Even if regional storage is available for a feature, that does not mean the entire process, including tools such as File Search and Code Interpreter, can run inside Japan.
Pricing differs as well. Under OpenAI's official specifications, a 10% surcharge applies to regional endpoint usage for data-residency-supported models released on or after March 5, 2026. In addition, using regions outside the United States, including Japan, requires approval of abuse-monitoring settings and agreement to contract terms that change data retention conditions. System data that is not customer content, such as account information, usage statistics, and billing information, is not subject to regional designation and may be processed or stored outside Japan.
Even with Zero Data Retention, retention periods vary by API feature
OpenAI states that it does not use data sent to the API for model training or improvement unless the customer explicitly agrees. But not using data for training is different from not storing it. OpenAI's data controls guide divides data stored by the API into two types: abuse-monitoring logs and application state.
Abuse-monitoring logs are records used to detect violations of usage policies and misuse, and may include submitted prompts, model responses, and classifier results. Under standard settings they are kept for up to 30 days, though the period may be extended if required by law or reasonably necessary to prevent harm to the service or third parties. With ZDR or Modified Abuse Monitoring (MAM) approval, customer content can be excluded from these logs, subject to specified exceptions.
Application state, by contrast, is data stored to make API features work. For example, it includes information kept so that a previous response can be retrieved again or a conversation can be continued. With the standard Responses API, omitting the store parameter or setting it to true means response data is stored for at least 30 days. Specifying store=false stops normal response storage, but the retention conditions for abuse-monitoring logs do not change.
Enabling ZDR also changes this behavior in part. For the Responses API and Chat Completions API, even if a request specifies store=true, it is forcibly processed as false. This control does not apply to every API endpoint, however. Features outside ZDR's scope, such as Conversations and Files, store data according to their own retention conditions.
The retention conditions OpenAI had published as of November 12, 2026, are summarized below.
| API / setting | Abuse-monitoring logs | Application state | ZDR support |
|---|---|---|---|
Responses (standard, store omitted or true) |
Up to 30 days by default | Response data stored for at least 30 days | Supported, with limitations |
Responses (standard, store=false) |
Up to 30 days by default | No normal response storage | Supported, with limitations |
| Responses (ZDR enabled) | Customer content generally excluded | Processed as store=false |
Supported, with limitations |
| Chat Completions (ZDR enabled) | Customer content generally excluded | Generally not stored, with some exceptions | Supported, with limitations |
| Conversations | Until deleted | Until deleted | Not covered |
| Files | Up to 30 days by default | Until deleted; expiry can be set with expires_after |
Not covered |
| Vector Stores | Up to 30 days by default | Until deleted | Not covered |
| Batch | Up to 30 days by default | Until deleted | Not covered |
This table shows general conditions based on OpenAI's per-endpoint retention specifications. Even features that support ZDR may involve exceptional storage in some processes. Also, not every API in the table supports in-country inference in Japan.
For example, with the Conversations API, creating a conversation object lets past exchanges carry over across multiple requests. But specifying store=false in the standard Responses API does not delete a separately created conversation object. Information stored in the Conversations API is kept until it is deleted.
Similarly, files uploaded through the Files API and search indexes stored in Vector Stores have their own independent retention conditions. With Files, an expiry can be set using expires_after, but the original file and the search index are separate resources, and their deletion must be managed individually. Enabling ZDR alone does not automatically erase this data.
ZDR and MAM settings can be managed at the organization or project level after OpenAI approval. Choosing default at the project level inherits the organization's setting, and approved retention settings can also be specified individually. Projects that select None do not receive these special retention controls. Projects with only MAM enabled cannot be used for in-country inference in Japan.
Features that still store data temporarily under ZDR
Even after ZDR is applied, some processes require temporary data storage for the API to complete its work. A typical example is background mode in the Responses API. It runs long generation tasks asynchronously so that a client can check status and retrieve results later.
According to OpenAI's background mode guide, in projects with ZDR enabled, background processing also runs as store=false. To allow results to be retrieved later, however, response data is stored on disk for about 10 minutes. In projects using MAM, keeping background responses longer than this temporary storage period requires explicitly setting store=true. These are general API retention specifications and do not indicate that background mode is offered as part of in-country inference in Japan.
Audio features also have their own retention conditions. In the Responses API and Chat Completions API, application state related to audio output is stored for one hour so that multi-turn conversations involving audio output can be processed. In addition, using Hosted Shell or Code Interpreter may cause temporary data to be written to the file system inside the container. These files remain until the container expires or they are explicitly deleted.
Another point to note is prompt caching. OpenAI reduces the computation needed for inference by reusing input portions shared with previous requests. In this mechanism, rather than the original text itself, the Key-Value (KV) tensors computed by the model may be encrypted and stored in GPU-side storage. The official guide sets the upper limit for retaining this data at 24 hours.
For GPT-5.6 and later models, the minimum cache retention time can be specified with prompt_cache_options.ttl in the Responses API. The default is 30 minutes, and 12 hours can also be selected in supported configurations. This value, however, specifies the time the cache is kept at minimum, not a deadline by which it is certain to be deleted. Even after the specified time has passed, data may remain within the maximum retention period.
Image and file inputs also carry an exception tied to safety checks. OpenAI screens images and files sent to the API for child sexual abuse material (CSAM), and if suspicious content is detected, it may retain the image for human review even when ZDR or MAM is enabled. It is therefore not accurate to understand ZDR as a mechanism under which all data disappears immediately under any conditions.
Safety review can store encrypted data on the customer's side
On August 19, 2026, OpenAI announced "Private Safety Processing (PSP)" as a mechanism to reconcile ZDR with safety monitoring. On September 22 of the same year, it also said it was rolling out to API customers in phases. PSP aims to prevent OpenAI staff from directly viewing customers' prompts and responses, even when investigating signs of misuse that span multiple exchanges.
In the approach combining ZDR and PSP, exchanges flagged for review by safety classifiers, or selected through an approved sampling method, are encrypted and stored in cloud storage managed by the customer. The retention period is 30 days, and what remains on OpenAI's side is not a copy of the content but information for referencing the storage location and operational metadata. Being selected for review does not in itself mean a usage policy violation has occurred.
In safety review, encrypted data is decrypted and automatically evaluated in a dedicated execution environment whose authenticity is verified by hardware. This environment is designed with human access disabled, and what can be output in plaintext is limited to predefined, narrow safety signals and operational information. Detailed evaluation results are encrypted again and stored in the customer's storage. Because the same expiration as the original record applies, customers also need to check the storage location and deletion settings on their side for data retained for safety review.
OpenAI may also, after giving prior written notice to specific customers, exclude some models from ZDR or MAM. One retention method applied in that case is "Private Retention with PSP." Under this method, customer content is stored on OpenAI-managed infrastructure as encrypted abuse-monitoring logs, but it is excluded from human review except where required by applicable law.
Another method, "Safety Retention," applies when reasonably necessary to investigate or prevent conduct involving serious risk. For content suspected of violating usage policies or contracts, OpenAI may retain data based on classifier determinations and review it manually. For other content, the conventional retention conditions apply. Because these methods differ from standard ZDR, companies need to review their contracts and notices to understand which retention policy actually applies.
Using in-country inference in apps that handle internal documents
The addition of in-country inference lets companies reconsider how they build applications that handle sensitive information. For example, if an app only summarizes internal inquiries, one possible setup is for the application to select the necessary text and send it to the Responses API in the Japan region. With ZDR enabled and a supported model and endpoint, the model's inference can run in Japan.
The situation is different for apps that search across internal documents and generate answers while referencing related materials. Such systems store original documents and search indexes before any question arrives, and may also maintain past conversation history as needed. In configurations that use hosted tools such as OpenAI's File Search, the in-country inference update alone does not necessarily keep the entire process inside Japan.
If in-country processing is a priority, one option is to store and search documents in your own managed environment and send only the minimum necessary excerpts found by the search to GPT-6 Luna. When referencing past conversations, storing history on your side and including only the necessary portions in each request can maintain context without relying on OpenAI's conversation storage features. Even in this setup, however, the storage region, access permissions, and deletion deadlines for documents, indexes, and access logs kept on your side must be managed separately.
OpenAI's in-country inference support is an important step forward for companies that found processing model inputs abroad to be a barrier to adoption. But being able to run inference in Japan does not mean the application's entire data processing and storage is completed in Japan. What matters in practice is understanding the data flow, from document retrieval and search to sending data to the model, generating answers, and storing history. Making clear what is stored at each stage, in which region it is processed, and who can delete it is the foundation for building secure enterprise AI systems.