Perplexity DeepSeek V4 Flash: Verify Routing and Fallbacks

Separate the three routing claims

“Perplexity routed the request” can describe at least three events: your application chose an API surface, Agent API selected a model from an ordered fallback chain, or Router API moved the requested model between healthy deployments. Those events are not interchangeable.

The strongest report names the layer before describing the result. “The Agent response named the second model in our declared chain” is testable. “Perplexity secretly switched providers” is not supported by an echoed model ID.

Identify the API surface before the model

The Agent API documentation uses POST https://api.perplexity.ai/v1/agent; Perplexity’s compatibility guide also accepts /v1/responses as an OpenAI-compatible alias. It can call third-party models, apply presets and use declared tools such as web search. Its response format includes a model field and usage details.

The Router API quickstart uses the https://api.perplexity.ai/router/v1 base URL and supports OpenAI Chat Completions, OpenAI Responses and Anthropic Messages schemas. Perplexity describes it as direct access to open-weight models hosted across healthy deployments. The product is currently labeled private preview, so record access state and documentation date rather than assuming general availability.

Do not use the legacy word “gateway” as the only route label in a dataset. Save agent or router, the exact endpoint, and the request schema. A base-URL change can leave otherwise similar client code talking to a materially different service.

Freeze the model catalog at run time

A model name in an old article is not proof that the identifier is accepted today. Before every collection window, save the relevant model-list response and its UTC retrieval time. The Agent model-list reference exposes GET /v1/models. The Router catalog documents GET /router/v1/models for accounts with preview access.

The catalog is an allowlist, not a benchmark. A listed identifier establishes that the surface currently accepts that model ID. It does not independently establish the model’s context handling, quality, speed, training data, provider parity or behavior on another service.

Keep the catalog JSON or a cryptographic hash beside the run manifest. If a model appears, disappears or changes price during collection, close the old window and start a new catalog version. Do not silently combine rows collected under different available-model sets.

Prove Agent fallback with the request and response

Perplexity’s Agent fallback documentation accepts an ordered models array of up to five identifiers. The service tries them in order until one succeeds, and the array takes precedence when both model and models are supplied. The returned model field identifies the model that produced the successful response.

That creates a bounded verification rule: a completed Agent row with a fallback chain should return a model contained in that frozen chain. If it returns the first identifier, you know which model succeeded; you do not know whether an invisible transient attempt preceded it unless the service exposes that evidence. If it returns a later identifier, you can report that the successful model was later in the chain, but not invent the reason an earlier one did not serve the response.

Save the chain in order, not as an alphabetized tag list. Order is part of the execution contract and may affect availability, cost and output behavior. Billing and usage should be interpreted against the successful returned model documented by the response.

Treat Router deployment failover as opaque

Router API uses one requested model ID while Perplexity distributes traffic among available deployments for that model. Its routing-and-reliability documentation says routing weights respond to observed health, including capacity, latency and error rates. When one deployment fails before output begins, the platform can retry another deployment automatically.

The response still echoes the requested model identifier, and billing uses that model’s published rate. Therefore, matching requested and returned IDs is expected and cannot reveal the underlying deployment. A test log should call this model-ID continuity, not provider or deployment identity.

Record errors before retrying

A polished successful response can hide an operationally important first failure if the client overwrites the previous attempt. Give every application-level attempt its own row and connect attempts with a stable run ID.

Perplexity distinguishes deterministic client errors from capacity failures. The same Router reliability reference says an invalid request or an input beyond the model context limit returns a 400 instead of being retried across deployments. When all deployments are unavailable, the service can return 429 with Retry-After. Preserve that header, wait interval and the final outcome.

Do not turn every timeout into “model failure.” Separate client timeout, DNS or TLS error, authentication, quota, invalid parameter, context overflow, provider error, service overload and incomplete stream. The failure category determines whether the next action is to fix the request, wait, change the chain or investigate infrastructure.

Audit streams as a separate state machine

A streaming request can fail before the first token or after output begins. Router documentation says a pre-output failure may be handled invisibly, while a post-output failure ends with an in-band error. Treat a stream without its expected terminal event as incomplete even if it contains readable prose.

Record whether streaming was requested, whether the terminal marker arrived, the first-token time, total duration, tokens delivered and error object. Never pass partial output downstream as a normal success merely because it ends with punctuation.

Compare streaming and non-streaming latency only when the metric is named. Time to first token, time to completed response and time to a validated artifact answer different operational questions.

Separate routing, retrieval and answer quality

Agent API web search is a declared tool. The model decides whether to call it based on the request and instructions. Save the tool configuration, tool-call result, citation count and search-result count separately from the returned model.

A response from DeepSeek V4 Flash with zero citations may be correct for a closed-context task and incomplete for a task that required current web evidence. Conversely, a cited response can still misread a source. Routing evidence identifies the execution path; retrieval evidence describes what information was gathered; answer review evaluates whether the final claims are supported.

Build a repeatable test fixture

1. Choose one route family and one schema for the primary comparison.
2. Save the model catalog, documentation date and account access state.
3. Freeze the prompt, instructions, attachments, tool declarations and output limit.
4. Hash the prompt fixture and assign a stable fixture ID.
5. Run direct single-model calls before testing an Agent fallback chain.
6. Preserve successful, failed, incomplete and retried attempts.
7. Repeat at declared times and report the full distribution, not only the fastest response.
8. Blind answer-quality review to the route when comparing outputs.

Use tasks with known answer keys for route verification. Add separate current-information tasks only when retrieval is explicitly enabled and the source-support rubric is defined. A single fluent anecdote is not a reliability test.

Use the browser-local evidence auditor

1. Copy the verification ledger and delete every EXAMPLE-REMOVE row.
2. Export one row per application-level attempt. Keep secrets, full prompts, user content and private response bodies outside the public file.
3. Open the route evidence auditor, paste or load the CSV, and run the checks.
4. Resolve chain mismatches, missing model IDs, incomplete streams, unclassified errors and unsupported deployment claims.
5. Export the findings and archive them beside the catalog snapshot, raw responses and review notes.

The auditor runs entirely in the browser. It makes no network requests and writes nothing to local or session storage. It checks evidence consistency; it does not call Perplexity, validate credentials, reveal hidden deployments, judge factual quality or certify production reliability.

Publish a claim-evidence matrix

For every conclusion, name the rows and fields that support it. A release table should include route family, catalog version, requested model or chain, returned model, run count, success definition, error counts, incomplete streams, latency summaries, retry policy, retrieval state and answer-review method.

Report null and contradictory outcomes. If every direct request succeeds but a fallback chain never reaches its second member, the run does not measure fallback behavior; it only verifies that the configured chain did not need to fall back in that window. If Router requests all echo the requested model, that matches the documented contract but reveals nothing about deployment switching.

Use the related Perplexity API surface guide to compare direct-model and agent workflows, and the evidence-led research protocol when the task depends on source retrieval rather than routing alone.

Sources, method and limits

Sources: Perplexity’s current Agent API quickstart, model catalog, model-fallback documentation, API reference and OpenAI-compatibility guide; plus its Router API quickstart, model catalog, routing-and-reliability documentation and changelog. Each source is linked beside the claim it supports and was retrieved on September 1, 2026.

Method: SearchEngineAnswer compared the two documented request contracts, response disclosures, error behavior and retrieval boundaries; converted them into a field-level verification rubric; and implemented those gates in a removable-example ledger and browser-local auditor.

Limits: SearchEngineAnswer did not run authenticated Perplexity requests for this article and reports no latency, reliability, quality or fallback rate. Router API is documented as private preview. Product access, catalogs, pricing, schemas and behavior can change. The DeepSeek context-window description remains a provider statement, not an independently verified result. The audit method can detect contradictions in preserved evidence; it cannot expose infrastructure that the API does not disclose.