GPT-5.6: Tool calling without magical thinking

Tool calling in the GPT-5.6 family is not the hard part. The hard part is you: who authorizes a call, what happens on the retry, what counts as done. GPT-5.6 ships as three tiers, Sol, Terra, and Luna, sharing a 1.05M-token window and split mainly on price and reasoning depth. None of that changes what the model does: propose calls. Someone else owns what happens next, and those specifics can move, so check the docs before you pin anything.

The list of failures a demo hides

Decide what a win looks like before the first prompt. For extraction that's a schema-valid record traceable to source text. For coding, the kind of harness codex-gpt5 runs, it's a patch that passes tests and review, not a diff that compiles. For research it's a claim list with checkable sources. Fluency isn't the bar.

Then test the boring cases: a valid call, a missing argument, an ambiguous request, a tool that errors, a stale result, a mid-flight cancellation, a request outside the caller's authority. Log the whole request each time: instructions, tool schemas, files, sampling settings, output cap. Native tool definitions versus pasted terminal output can make the same model look like two different products.

Context windows lie about the hard part

The expensive mistake is counting a correct tool name as success while the arguments underneath are malformed and a retry quietly resends a side-effecting call. Frontier models look finished even when they're wrong, which hides the problem in a demo. Measure what code can check, have a reviewer flag concrete defects, and keep the failed runs instead of deleting them.

A correct tool name is not a correct tool call.

A 1.05M-token window makes this worse if you let it. Capacity doesn't erase prefill time, and stuffing in the whole history just adds retrieval noise and blurs trusted instructions against untrusted documents. Cache the stable prefix, keep volatile metadata off the cache boundary, and reach for a structured checkpoint over the full transcript. The same restraint applies on the way out: a short decision plus evidence beats an unsolicited tutorial.

None of that changes who answers when a tool fires. The application still validates arguments, checks that the caller may do this, caps the blast radius, catches duplicates, and logs what happened, no matter how good the model gets at picking functions. A web page, an email, a file it just read is data, not authority, however it's phrased.

Keep the tool leash short

Expose the smallest tool set that does the job and keep authorization outside the model, written into configuration, not left to whoever finds this tier fashionable this month. Log model identity, phase timings, token categories, tool outcomes, and evaluation results, and skip the sensitive prompt content by default.

Give routine work a cheap, fast lane and hard cases a clear escalation trigger. Sol should see requests that need frontier reasoning, not everything the gateway can send; Luna is a false economy once its retries and review cost more than the inference it saved. Migration is normal operations: pin dated versions, watch deprecation notices, canary new aliases before real traffic, keep a fallback, because migration reality never quite matches the changelog. Re-run your evaluation set whenever the model, prompt, tool contract, or reasoning default moves.

What I still don't have a clean answer for is tier drift inside one named model: a provider can revise Sol's tool-selection behavior without touching the identifier you pinned, and an eval set only catches it by accident. Pinning the version string protects you from the changes you already know about. It does nothing for the ones you don't.