langchain-perplexity 1.3.1: Routing Logic, SSE Correction, Explained

1.3.0 added use_responses_api for Perplexity's Responses endpoint; 1.3.1 removed the SSE shim 0.34.0 required.

langchain-perplexity 1.3.1: Routing Logic, SSE Correction, Explained
Share

On May 27, 2026, the LangChain team shipped two langchain-perplexity releases within the same calendar day — 1.3.0 at 00:22 UTC introducing the Responses API routing, and 1.3.1 at 20:45 UTC removing a temporary streaming shim after Perplexity patched their upstream SDK hours later. If you track AI tooling releases, this one is worth understanding: it opens Perplexity's Agent API to LangChain users and resolves a production-streaming edge case in a single day.

From 1.3.0 to 1.3.1: Feature Launch and Upstream Correction

langchain-perplexity 1.3.0 landed via PR #37359 at 00:22 UTC on May 27, 2026 . The headline change was use_responses_api — a new boolean on ChatPerplexity that routes requests to Perplexity's Agent API rather than Chat Completions. By 20:45 UTC the same day, PR #37710 had merged and 1.3.1 was tagged — bumping the perplexityai floor to >=0.34.1 and removing a temporary SSE shim that 1.3.0 had carried .

Quick Answer: langchain-perplexity 1.3.1 (May 27, 2026) is the stable baseline for using Perplexity's Agent API from LangChain. It adds use_responses_api routing, removes a production-streaming shim patched by perplexityai 0.34.1, and passes all 28 CI checks. Treat 1.3.0 as transitional.

The trigger for the same-day patch was perplexityai 0.34.1, released by the Perplexity team between the two LangChain wheels on May 27 . It fixed a streaming defect in the 0.34.0 SDK that 1.3.0 had worked around with a shim. Once the upstream fix landed, removing the shim was the obvious next step — and the LangChain team did it immediately. All 28 CI checks passed before 1.3.1 was tagged .

For builders: treat 1.3.0 as a transitional wheel that served a valid purpose for roughly 20 hours. 1.3.1 is the baseline you should be on. The feature set is identical — only the shim is gone and the dependency floor is cleaner.

The use_responses_api Flag: Endpoint Routing and Auto-Detection Logic

langchain-perplexity 1.3.1: Routing Logic, SSE Correction, Explained

use_responses_api is a boolean field on ChatPerplexity that controls which API endpoint your requests target. Setting it to True routes calls to /v1/agent (with /v1/responses as an OpenAI-compatibility alias) rather than /v1/chat/completions — the only path the integration exposed since its 0.x era . The Agent API is where Perplexity's extended capabilities live: built-in tools, third-party model routing, and stateful fields are all exclusively available there.

The more interesting behavior is the auto-detection rule. When use_responses_api is not set, the library inspects each call and selects the Agent API path automatically if it finds either of the following in the payload:

  • Non-function-type built-in tools (e.g., Finance Search, People Search, live web search)
  • Any Responses-specific fields: previous_response_id, instructions, or include

If neither condition is met, routing falls through to Chat Completions unchanged. This is the backward-compatibility guarantee: any existing ChatPerplexity instantiation that does not reference Agent API features continues to behave exactly as it did before 1.3.0. No forced code edits, no silent regressions.

The 1.3.0 PR also added debug logging that narrates routing decisions at each call. Rather than letting authentication failures or rate-limit responses surface as raw SDK exceptions, the logger now emits actionable messages explaining what went wrong and why a particular routing branch was selected. Useful during integration testing, and something to enable before chasing a "why is this going to the wrong endpoint" bug.

Condition Routing outcome Explicit flag needed?
use_responses_api=True /v1/agent (Responses / Agent API) Yes — explicit override
Built-in non-function tool in payload /v1/agent — auto-detected No
previous_response_id, instructions, or include in payload /v1/agent — auto-detected No
None of the above (default Chat usage) /v1/chat/completions — unchanged No

The SSE Shim in 1.3.0 and Why perplexityai 0.34.1 Closed It

The SSE shim in 1.3.0 existed to paper over a defect in perplexityai 0.34.0 (released May 13, 2026) . Two things were broken in the upstream SDK on the Responses API path: SSE was not emitting named events for responses.create calls, and the ResponseStreamEvent union type was not being correctly discriminated on the client side. Without named events, a streaming consumer cannot reliably identify which event type it's processing — the kind of defect that produces intermittent failures rather than clean errors, making it harder to diagnose.

"yield named SSE events for responses.create + discriminate ResponseStreamEvent union" — perplexityai 0.34.1 CHANGELOG, Perplexity AI (May 27, 2026)

LangChain 1.3.0 shipped a workaround shim inside ChatPerplexity to handle this. It was functional — non-streaming Responses API use cases were fine — but it was a fragile layer for production streaming: any behavior divergence between the shim's assumptions and what the SDK actually returned could silently produce incorrect output. The shim's only purpose was to compensate for the upstream bug.

When perplexityai 0.34.1 landed on May 27, 2026 with the two-line fix above, the shim's reason to exist was gone. PR #37710 removed it entirely and encoded the >=0.34.1 floor in the dependency spec . If you install langchain-perplexity>=1.3.1, pip enforces the SDK floor and the shim is not present in the installed code — nothing to maintain, nothing to surprise you.

The practical implication: if you were evaluating 1.3.0 for streaming over the Responses endpoint and saw inconsistent stream events, this is why. Install 1.3.1.

Built-in Tools on the Responses Endpoint: Perplexity's Extended Capabilities

langchain-perplexity 1.3.1: Routing Logic, SSE Correction, Explained

The Responses (Agent API) endpoint exposes capabilities that simply do not exist on /v1/chat/completions. According to Perplexity's documentation, the built-in tools available exclusively via this path include Finance Search, People Search, live web search, and URL fetching . These are Perplexity-managed retrieval tools — you get them by naming them in your tool list, and the Agent API routes retrieval accordingly without you managing the web-search infrastructure.

Third-party model routing is the other significant unlock. The Responses endpoint supports routing requests to Google, OpenAI, and Anthropic models through Perplexity's infrastructure . There is no equivalent on the Chat Completions path. For builders who want a single API entry point that dispatches to multiple model providers with Perplexity's retrieval capabilities on top, this is the path that enables it.

The stateful fields deserve specific attention. previous_response_id enables multi-turn continuity across API calls — the server tracks conversation state so you don't have to re-send full message histories. instructions and include allow per-call shaping of response content and format. These are fields that trigger auto-detection: include any of them in a ChatPerplexity call and the library will route to the Agent API automatically, even without setting use_responses_api=True.

Feature Chat Completions (/v1/chat/completions) Responses / Agent API (/v1/agent)
Sonar model inference
Live web search (built-in)
Finance Search / People Search
URL fetching (built-in)
Google / OpenAI / Anthropic model routing
Stateful fields (previous_response_id, etc.)
Standard LangChain AIMessage output ✓ (via response converters added in 1.3.0)

The response converters added in 1.3.0 are worth noting separately. Agent API responses are structurally different from Chat Completions responses — they include citations, image results, search payloads, and tool call structures that don't map cleanly to the standard AIMessage schema. The converters handle that translation, so downstream LangChain chains and agents receive standard message objects with the Agent API metadata preserved as additional fields. You get the rich response without having to parse Perplexity-specific response shapes yourself.

Version Pinning for 1.3.x: What Each Wheel Gives You

langchain-perplexity 1.3.1: Routing Logic, SSE Correction, Explained

Three distinct upgrade positions exist for langchain-perplexity users right now, and the right choice depends on what you're doing with the integration. The short version: pin to 1.3.1 unless you have a specific reason not to .

Below 1.3.0 — Chat Completions only. Sonar models via Chat Completions continue to work and nothing is broken. No forced migration. If you have no interest in Perplexity's built-in tools, third-party model routing, or stateful fields, staying here is fine — but upgrading to 1.3.1 is still the recommended path for a cleaner dependency graph.

Exactly 1.3.0 — feature-complete, shim present. Responses endpoint routing and auto-detection work. For non-streaming Responses use cases this is acceptable. For production streaming over the Responses endpoint, do not run 1.3.0: the SSE shim could produce inconsistent stream event behavior. The case for pinning here is narrow to nonexistent — 1.3.1 has the same feature set without the shim.

1.3.1 (recommended floor) — shim removed, clean floor. The perplexityai>=0.34.1 constraint is encoded in the package spec and pip enforces it on install. This is the minimum safe version for any streaming workload over the Responses endpoint . All 28 CI checks passed before tagging.

One conservative note worth flagging: by the time 1.3.1 was published, perplexityai had already moved to 0.35.0 and 0.35.1 — both released on May 27, 2026 . The 1.3.1 dependency floor is deliberately set at 0.34.1, not 0.35.x. That is intentional conservatism: 0.35.x should resolve cleanly against 1.3.1 but has not yet been validated in a LangChain wheel. If you separately pin perplexityai>=0.35.1 in your requirements file, that constraint will win — just be aware it sits outside what the 1.3.1 CI matrix covered.

Frequently Asked Questions

What does setting use_responses_api=True do in ChatPerplexity?

It routes all requests to Perplexity's /v1/agent endpoint (the Agent API, also accessible as /v1/responses for OpenAI-compatibility). This unlocks capabilities that are only available on that path: built-in tools including Finance Search, People Search, live web search, and URL fetching; third-party model routing to Google, OpenAI, and Anthropic models through Perplexity's infrastructure; and stateful conversation fields (previous_response_id, instructions, include). None of these are available on /v1/chat/completions. Setting the flag to False — or leaving it unset while passing no Agent-API-specific fields — keeps routing on the Chat Completions path unchanged.

Is langchain-perplexity 1.3.1 a breaking change for existing users?

No. Backward compatibility is fully preserved. Any existing ChatPerplexity code that uses Sonar models via Chat Completions and does not reference Agent API tools or stateful fields will continue to route identically after upgrading to 1.3.1. The library's auto-detection only activates the new routing when Responses-specific signals are present in the payload. Developers who are not intentionally targeting Responses endpoint features do not need to change any code.

Why did LangChain ship two 1.3.x wheels on the same day?

perplexityai 0.34.0 (May 13, 2026) had a streaming defect on the Responses API path: SSE was not emitting named events for responses.create and the ResponseStreamEvent union type was not being correctly discriminated. LangChain 1.3.0 shipped a temporary shim to work around this. Later the same day (May 27), Perplexity released perplexityai 0.34.1 with the upstream fix. The LangChain team immediately removed the now-redundant shim and published 1.3.1. The two-release pattern reflects a dependency moving faster than a typical release cycle — both teams resolved a production edge case within a single calendar day.

Which Perplexity features require use_responses_api or the Responses endpoint?

Finance Search, People Search, live web search, and URL fetching are only available on the Responses (Agent API) path. Third-party model routing — sending requests to Google, OpenAI, or Anthropic models through Perplexity's infrastructure — is also Responses-only. Stateful conversation fields (previous_response_id, instructions, include) likewise require the Agent API path. You can enable it explicitly with use_responses_api=True, or let auto-detection handle it: if any of the above tools or fields appear in your payload, langchain-perplexity>=1.3.0 routes to the Agent API automatically without an explicit flag.

Do I need to pin perplexityai >= 0.34.1 in my own requirements file?

Only if you are independently constraining langchain-perplexity to a version below 1.3.1. If your requirements specify langchain-perplexity>=1.3.1, the perplexityai>=0.34.1 floor is already encoded in that package's dependency spec — pip will enforce it automatically during resolution. No separate pin is needed. If you have a legacy pin like langchain-perplexity==1.3.0, you are on the version that carries the SSE shim; the safest fix is to remove the upper bound and let pip pull 1.3.1.

What to Watch Next

The immediate practical takeaway: upgrade to langchain-perplexity==1.3.1 if you are on any 1.3.x wheel, and to langchain-perplexity>=1.3.1 as your requirements floor going forward. The feature set — Agent API routing, auto-detection, response converters, debug logging — is stable and the dependency graph is clean.

Two open questions are worth tracking. First, the official Perplexity LangChain integration docs had not been updated to document use_responses_api or the Agent API routing as of the search date — developers relying solely on official documentation would not know this feature exists. Watch for that doc update. Second, there is no public confirmation that the TypeScript @langchain/community package received a parallel Agent API implementation. If you operate a JS/TS stack alongside Python, that gap is worth investigating before assuming feature parity.

Longer term: perplexityai moved to 0.35.1 on the same day 1.3.1 was published. A follow-on langchain-perplexity release validating that floor — and potentially picking up any 0.35.x additions — is the natural next step. The pace of releases on May 27 suggests active iteration on both sides of the dependency boundary.

Last updated: 2026-05-30. Article reflects langchain-perplexity 1.3.1 and perplexityai 0.34.1 as of May 27, 2026 release artifacts.