Gemini API Deep Research: update the retiring agent while keeping the workflow. October 23 refers to the older agent’s retirement, not the end of Deep Research as a service.
Developers with research features in a Mac or iPhone app’s backend should check which Gemini agent they call before October 23. Google’s October 8 API release notes schedule the shutdown of deep-research-pro-preview-12-2025 for that date.
Check the identifier, not the product name
This notice concerns a specific managed agent in the Gemini API. It does not announce the retirement of Deep Research in the consumer Gemini app.
Google’s deprecation schedule lists the same October 23 date and defines shutdown as an endpoint becoming unavailable. Its general note describes listed dates as the earliest possible retirement dates; the release notes explicitly name October 23. Neither source supplies a cutoff time. Plan the migration before that calendar date rather than assuming an extra grace period.
Choose a replacement deliberately
Google directs developers to change the agent parameter in interactions.create. The replacements are deep-research-preview-04-2026, aimed at speed and efficiency, and deep-research-max-preview-04-2026, aimed at more comprehensive investigations. Both remain previews.
Do not assume the old identifier will redirect automatically. Google explicitly documents automatic routing for older Flash models, but tells Deep Research developers to update their requests.
Test the whole research job
The current implementation guide requires the Interactions API, rather than generate_content, with background execution and polling or streaming. It also states that background=True requires store=True.
Before deploying, check configuration files and scheduled jobs for the retiring identifier. Run representative requests through your existing completion and failure handling, review the resulting reports, and check actual usage costs. These are migration checks, not a claim that the two replacements behave identically.
For an app that exposes research progress to users, keeping the request alive is only part of the job. Make sure the interface also handles a failed run instead of leaving a progress indicator spinning.
