A migration checklist written before a deadline can become unsafe after it. Verify which routes remain usable before relying on an old fallback plan.
The Sonar deadline is now historical
Perplexity’s Agent API announcement directed developers away from Sonar tiers, with a September 27, 2026 retirement date. The announcement gave existing contract customers access through their current contract term.
That date has passed. Check the account’s actual entitlement before treating Sonar as a rollback target. An exception for a contract customer does not establish access for every API account.
The migration still needs an adapter for requests, tools, and responses. Preserve the application’s answer, citation, usage, and error formats while changing the provider-specific implementation.
The October 24 model cutoff has also passed
The Perplexity changelog scheduled several OpenAI model IDs for retirement at 00:00 UTC on October 24. The list includes openai/gpt-5.4, its mini and nano variants, and openai/gpt-5.2, openai/gpt-5.1, openai/gpt-5 and openai/gpt-5-mini.
According to the schedule, requests using those IDs are rejected after the cutoff. The model-list endpoints also stop listing them. We have not made authenticated calls to confirm individual account responses.
Inspect direct model selections and fallback chains. A fallback to another retired ID can leave an application with no working recovery path. Choose from the current model reference and verify access through the account you use.
The effort rename preserves the existing behavior
An October changelog entry renames preset to effort. Perplexity says the underlying models, tools, limits, and pricing are unchanged. Requests can still use the deprecated preset name. Responses include the new and old field names.
Treat this as an interface naming change. Check SDK support and response parsing, but do not infer a new reasoning budget or a price reduction from the new name.
The October entries are dated by month. Do not assign an invented release day.
Tool approvals must be configured
Another October entry adds require_approval for MCP and connector tools. Calls run without approval by default.
When approval is required, the API returns an mcp_approval_request instead of running that call. The application responds with an mcp_approval_response and previous_response_id. The documented controls include approval for every call or filtered cases.
Choose the policy before exposing a write-capable tool. The user interface also needs to show the intended action and accurately preserve the approval result.
Recheck citations and recovery on the current route
I would use saved, sanitized requests that represent the application’s actual work. Include a missing source, conflicting sources, and a failed tool call.
- Verify that each selected model is currently available to the account.
- Check source URLs against the nearby factual claims.
- Exercise denied and approved tool calls in a harmless environment.
- Record partial failures, retrievals,s and complete workflow cost.
- Verify a recovery route whose model and account access still work.
Keep the old response format as a regression reference even when the old endpoint is unavailable. Compare the new result with the product’s acceptance criteria, then inspect the actual user-visible output.
Our MCP migration guide covers state and retries. The agent cost-control guide helps account for tool calls and failed attempts.
Sources
- Model retirement schedule, effort rename and approval controls
- Original Agent API announcement and migration context
Does every fallback in your application still point to a model and route that your account can use?
Checked October 25, 2026. Prepared with AI-assisted research and drafting, with claims checked against the linked sources. MustHave.ai has not performed the proposed product tests.
