The name misleads. PTC is not an acceleration switch; it is a way of presenting tools. The official type is ToolPresentationMode with three values: native, ptc, both.
| Value | What the model receives |
|---|---|
| native (default) | The full schema of every visible tool; the model calls them one by one |
| ptc | Only run_code plus a generated SDK prompt; the model writes one program that calls the tools |
| both | Both forms |
The key sentence in the official description: a sequence that would be five round trips becomes one. What is saved is not tokens per se but the structure where every extra tool call costs a full model round trip.
The cost: a hard dependency on a code runtime
The docs are explicit: PTC mode requires a ctx.codeRuntime whose language has a registered SDK renderer (TypeScript or Python). Missing, or an unregistered language, means prompt assembly fails. Not a silent fallback to native — a failure.
toolOrder are invalid, because the model never sees those names — only run_code and the SDK. Tool-ordering config written for native stops applying.When it actually saves
- Saves: multi-step work expressible as one program with clear dependencies (read A, then read B based on A, then summarise).
- Does not save: one or two steps, or each step needing a human decision. PTC just adds abstraction.
- May cost more: the generated SDK prompt occupies context; with few tools and few calls it is pure overhead.
Measure it yourself
The community holds opposite views on whether PTC saves — unsurprising, since it depends on task shape. The only way to judge your task is three runs per mode, comparing two numbers: tool calls and model round trips.
# Record template (do not just log total time) mode | run | tool calls | round trips | tokens | identical output? native | 1/2/3 | | | | ptc | 1/2/3 | | | |