GPT-5.6 JSON 抽取示例：100,000 項任務成本介乎 $667 至 $1,100，token 單價不變

Ask what an LLM call costs and you get the price list. Ask what a task costs and the honest answer is the price list divided by how often the answer is usable. That divisor is set by two knobs most beginners copy from a tutorial and never touch again — temperature and seed.

A few words first. A token is roughly ¾ of a word; APIs bill per million of them, one price for input (what you send) and a higher one for output (what the model writes). Temperature controls how adventurous the model is when picking the next token: 0 means "almost always take the most likely one", 1 and above means "spread the bets". Seed is a number that makes that random choice repeatable — same seed, same input, (usually) same answer. Validation is your code checking the answer before using it: does it parse as JSON, are the required fields there.

The price of a call doesn't move

Neither knob is on the invoice. A request at temperature 0 and the same request at 1.2 are billed identically — tokens in times input price, tokens out times output price.

Here is a concrete job: pull five fields out of a support ticket and return them as JSON. Call it 1,500 input tokens (instructions plus ticket) and 300 output tokens. On GPT-5.6 at the official $2.00 per million input and $12.00 per million output (prices from our catalog snapshot, 15.10.2026):

1,500 × $2 / 1M + 300 × $12 / 1M = $0.0030 + $0.0036 = $0.0066 per call.

Same at every temperature. What changes is how many times you pay it.

What a failed answer costs

The API returned 200 OK, you were billed, and the answer is {"priority": "high", "summary": "Customer says "refund" ... — an unescaped quote, a trailing comment, a friendly "Sure! Here's your JSON:" in front. Your parser throws. Your code retries. You pay again.

Higher temperature makes this more likely for a simple reason: valid JSON is a narrow path, and every token sampled away from the most likely one is a chance to step off it. Let p be the share of answers that pass validation. If you retry until one passes, the expected number of attempts is 1 / p, so the cost of one finished task is price per call ÷ p.

CALL = 1_500 * 2.00 / 1e6 + 300 * 12.00 / 1e6   # $0.0066, GPT-5.6 official
TASKS = 100_000

for p in (0.99, 0.90, 0.75, 0.60):
    attempts = 1 / p
    print(f"p={p:.2f}  attempts={attempts:.2f}  bill=${CALL / p * TASKS:,.0f}")

To be clear about what this is: these p values are illustrative, not measured. I haven't run a temperature sweep for this post, and your p depends on the model, the prompt and the schema. The arithmetic is exact; the inputs are a model. Log every validation failure next to the temperature you used, and you'll have your own p in a day.

Seed can make retries useless

Here's the trap that turns 1/p into infinity. If you pin a seed for reproducibility — a good habit in tests — and retry with the same seed, same temperature and same prompt, you ask the model to repeat itself. It will, broken comma included. Every retry is billed and none gets a fresh chance to pass. (Seed determinism is "best effort", so you might get lucky; don't build on luck.)

So a retry must change something. Drop or bump the seed, lower the temperature on the retry, or append the parser error to the prompt so the model knows what to fix. The last one adds input tokens to each retry — the 300-token broken answer plus the error message — so the retry costs a bit more than the first call, and the table above is a floor, not a ceiling.

Also cap the loop. With at most 3 attempts and p = 0.75, you average 1.31 attempts instead of 1.33, but 1.6% of tasks (0.25³) fail for good — and you'd rather know that than pay for attempt eleven.

What to do on Monday

Set temperature to 0 for anything a parser reads. Then use the API's structured output mode if your provider has one — the request carries a JSON schema and the model is constrained to produce text that matches it, which pushes p close to 1 for the "does it parse" part. And count. A single counter, validation_failures / calls, is your p, and price ÷ p is what you actually pay per task.

What this doesn't solve

Valid JSON isn't correct JSON. A schema guarantees the field priority exists; it can't stop the model from filling it with the wrong priority, and those failures don't trigger a retry at all — they slip into your database. Low temperature isn't right for every task either: for brainstorming it gives flat, repetitive text, and there's nothing to validate anyway. And network errors or timeouts are a separate retry budget with their own math.

For scale on the other lever: we sell GPT-5.6 at $1.70 / $10.20 per million against the official $2.00 / $12.00, 15% off. At p = 0.60 that turns $1,100 into $935. Fixing p to 0.99 at the official price gets you to $667. A discount multiplies the bill by a fixed number; 1/p can multiply it by anything. Do the cheap thing first.

Go find the temperature in your extraction code. If it says 0.7 because a quickstart said so, you already know where part of your bill went.