In LangChain, when should you use with_structured_output() instead of PydanticOutputParser?

## Two ways to get JSON out of a model Getting a typed object out of an LLM is a daily production problem, and LangChain offers two mechanisms that look interchangeable and are not. **Prompt-and-parse.** `PydanticOutputParser(pydantic_object=Ticket)` derives a JSON schema from your Pydantic model and renders it as prompt text via `get_format_instructions()`. You insert that text into the prompt, the model produces free-form output, and the parser extracts the JSON and validates it. If the model wraps the JSON in prose, emits a trailing comma, or invents a field, the parser raises `OutputParserException`. **Provider-native structured output.** `model.with_structured_output(Ticket)` returns a runnable that sends the schema *to the API* — as a tool/function definition, or as a JSON-schema response format — and returns a validated `Ticket` instance directly. The constraint is applied by the provider during decoding, not by hope. ## What with_structured_output actually does The `method` parameter selects the mechanism: - `"function_calling"` — the schema becomes a tool definition and the model is asked to call it. Broadest support, and the historical default for most providers. - `"json_mode"` — the provider guarantees syntactically valid JSON but not that it matches your schema; your prompt must still describe the fields. - `"json_schema"` — strict schema-constrained decoding where the provider supports it. Strongest guarantee, but the supported subset of JSON Schema is narrower: deeply nested unions, some `anyOf` shapes and certain constraints may be rejected. The schema argument can be a Pydantic model (you get an instance back), a `TypedDict` or a raw JSON-schema dict (you get a dict back). `include_raw=False` is the default and returns just the parsed object. That is convenient and quietly costly: the `AIMessage` is discarded, and with it `usage_metadata`, `response_metadata` and the raw text. Passing `include_raw=True` returns a dict with `raw`, `parsed` and `parsing_error` keys — and it also changes failure behaviour: instead of raising, a parse failure comes back with `parsed=None` and the exception in `parsing_error`, which you can inspect and route. For any service that meters tokens or logs model output, `include_raw=True` is usually the right default. ## Costs of the native path It is not free. The schema is serialized into the request, so a large nested model adds input tokens on every call — sometimes hundreds. Structured output usually occupies the same channel as tool calling, so a model asked to both call tools and emit a schema in one turn can behave awkwardly; the common design is to separate those steps. Strict `json_schema` mode may force you to simplify a schema you would rather keep rich. And support varies by provider and by model within a provider, which is a real portability constraint if you swap models by config. ## When the parser is still right - A local or older model with no tool-calling or JSON mode at all. - Output that is not JSON: a delimited list, an enum token, XML. - Cases where you want the model's reasoning text *and* a structure in the same free-form response and you are willing to parse both. A sensible middle ground is `JsonOutputParser`, which returns dicts and tolerates partial output while streaming, at the price of no validation. ## Failure handling either way Neither approach removes the need for a failure path. With the parser, catch `OutputParserException` and decide: retry with the error fed back, fall back to a stricter model, or degrade. With the wrapper, use `include_raw=True` and branch on `parsing_error`. Validation errors from Pydantic — a wrong type, a missing required field, an out-of-range value — can still occur under `"function_calling"` because the provider is not enforcing your validators, only the shape it was given. Field descriptions matter more than people expect: `Field(description=...)` text is carried into the schema the provider sees and is often the cheapest accuracy fix available. ## Deciding in an interview State the rule first — native structured output when the provider supports it, parser as the fallback — then show you know the edges: token cost of the schema, `include_raw=True` to keep usage metadata and turn exceptions into inspectable errors, and the narrower schema subset under strict mode. Candidates who only know `PydanticOutputParser` are usually reciting pre-1.0 tutorials.