> This page is for version dev.
> For other versions, use one of these documentation indexes:
> - Latest (v1.6.1) (default): https://docs.nvidia.com/dynamo/latest/llms.txt
> - dev: https://docs.nvidia.com/dynamo/dev/llms.txt
> - v1.6.1: https://docs.nvidia.com/dynamo/v1.6.1/llms.txt
> - v1.6.0: https://docs.nvidia.com/dynamo/v1.6.0/llms.txt
> - v1.5.1: https://docs.nvidia.com/dynamo/v1.5.1/llms.txt
> - v1.5.0: https://docs.nvidia.com/dynamo/v1.5.0/llms.txt
> - v1.4.2: https://docs.nvidia.com/dynamo/v1.4.2/llms.txt
> - v1.4.1: https://docs.nvidia.com/dynamo/v1.4.1/llms.txt
> - v1.4.0: https://docs.nvidia.com/dynamo/v1.4.0/llms.txt
> - v1.3.0: https://docs.nvidia.com/dynamo/v1.3.0/llms.txt
> - v1.2.1: https://docs.nvidia.com/dynamo/v1.2.1/llms.txt
> - v1.2.0: https://docs.nvidia.com/dynamo/v1.2.0/llms.txt
> - v1.1.1: https://docs.nvidia.com/dynamo/v1.1.1/llms.txt
> - v1.1.0: https://docs.nvidia.com/dynamo/v1.1.0/llms.txt
> - v1.0.2: https://docs.nvidia.com/dynamo/v1.0.2/llms.txt
> - v1.0.1: https://docs.nvidia.com/dynamo/v1.0.1/llms.txt
> - v1.0.0: https://docs.nvidia.com/dynamo/v1.0.0/llms.txt
> - v0.9.1: https://docs.nvidia.com/dynamo/v-0-9-1/llms.txt
> - v0.9.0: https://docs.nvidia.com/dynamo/v-0-9-0/llms.txt
> - v0.8.1: https://docs.nvidia.com/dynamo/v-0-8-1/llms.txt
> - v0.8.0: https://docs.nvidia.com/dynamo/v-0-8-0/llms.txt
> - v0.7.1: https://docs.nvidia.com/dynamo/v-0-7-1/llms.txt
> - v0.7.0: https://docs.nvidia.com/dynamo/v-0-7-0/llms.txt

> For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://docs.nvidia.com/dynamo/llms.txt. For full content including API reference and SDK examples, see https://docs.nvidia.com/dynamo/llms-full.txt.

# Overview

Some models emit tool calls and chain-of-thought reasoning as markup inside their raw text output. Dynamo parses that markup out and surfaces it as OpenAI-compatible `tool_calls` and `reasoning_content` on the response, so clients get structured fields instead of raw `<tool_call>` or `<think>` text.

Setting this up is two steps: one thing that always runs, then two optional features layered on top of it.

#### Pick a chat processor

Every request to `/v1/chat/completions` is handled by a **chat processor**. It renders the chat template, tokenizes the prompt, routes to the worker, and assembles the OpenAI-compatible response. You always have one — it is selected by the `--dyn-chat-processor` frontend flag, which **defaults to `dynamo`**.

The `dynamo` default is Dynamo's own framework-agnostic (Rust) processor. It works across every backend — vLLM, SGLang, and TRT-LLM — and with disaggregated serving, and it ships built-in parsers for a broad set of model formats. **For most models the default is all you need.** You only change the chat processor when Dynamo does not ship a parser for your model's format and you want to fall back to the engine's own parser (vLLM or SGLang).

Because the chat processor decides *who* parses, it also decides which parser flags you use and where they go — so it is the first decision. Keep the `dynamo` default unless Dynamo lacks a parser for your model; see [Chat Processors](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/chat-processors) for the options and engine-fallback configuration.

#### Choose your parsers

With a chat processor in place, configure tool-call extraction, reasoning extraction, or both for the model output format:

* **Tool call parsing** extracts `tool_calls` from a model that emits tool-call markup. See [Tool Call Parsing](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/tool-call-parsing).
* **Reasoning parsing** splits chain-of-thought into `reasoning_content` for a model that emits thinking content. See [Reasoning Parsing](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/reasoning-parsing).

Unified routes use a compatible family grammar. Auto uses the V1 split route for mixed formats supported by V1 and rejects combinations unavailable in both generations. See [Parser Generation Routing](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/troubleshooting-tool-calls#parser-generation-routing) for shared grammars and Beam/Qwen/Nemotron exceptions.

> **Note**
>
> Unified emits reasoning, visible text, and calls in their original order from one parser. The legacy split pipeline extracts reasoning first, then parses tools from the remaining output. Batch responses aggregate those events into response fields; streaming can expose incremental events.

## Why Dynamo parses in the frontend

In `vllm serve`, `sglang serve`, and `trtllm-serve`, tool-call and reasoning parsing happen in each engine's own frontend, with subtle behavioral differences across them. For performance, Dynamo orchestrates routing and tokenization and passes tokens directly to each engine, bypassing the engine's OpenAI server to avoid duplicate work per request. So the `dynamo` chat processor implements parsing in Dynamo's frontend as a framework-agnostic Rust layer — one tested OpenAI-compatible contract across vLLM, SGLang, and TRT-LLM, on a hot path that stays concurrent without a Python GIL bottleneck. The `vllm` / `sglang` chat processors (engine fallback) opt back into the engine's own parser when Dynamo doesn't ship one for your model.

## See Also

* [Chat Processors](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/chat-processors) — the `--dyn-chat-processor` flag, the `dynamo` default, and engine fallback
* [Tool Call Parsing](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/tool-call-parsing) — Dynamo-native tool-call parser names and request examples
* [Reasoning Parsing](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/reasoning-parsing) — Dynamo-native reasoning parser names
* [Structural Tag (Guided Decoding for Tool Calls)](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/structural-tag) — constrain output to a valid tool-call format with xgrammar
* [Troubleshooting Tool Calls](/dynamo/dev/knowledge-base/modular-components/frontend/tool-calling/troubleshooting-tool-calls) — capture `logprobs` so issues can be localized
* [Frontend Configuration Reference](/dynamo/dev/reference/components/frontend-configuration) — full CLI flag reference