Skip to content

Model Parameters & Tuning

Every model API call comes with a handful of settings beyond the prompt text itself, and getting them wrong produces two very different symptoms: an agent that's maddeningly inconsistent from run to run, or one whose output gets cut off mid-file for no obvious reason. Neither is a prompting problem, both are parameter problems. This is short by design: there are really only three settings worth understanding well, and the rest is default values you rarely need to touch.

Gnome mascot

What you'll learn

  • Temperature: why 0.0 is mandatory for anything an agent needs to parse
  • Top-P and Top-K, and why you almost never need to tune both at once
  • The truncation bug that looks like a JSON parsing bug but isn't

Temperature: how much the model is allowed to gamble

Temperature controls how the model picks its next token from the set of plausible candidates. At temperature = 0.0, it always picks the single most likely token, fully deterministic, same input, same output, every time. Turn it up toward 1.0 and the model starts picking from a wider spread of plausible-but-not-most-likely tokens, which is what gives creative writing its variety and unpredictability.

For an agent that needs to produce code, JSON, or anything else a program downstream will parse, the choice is easy: temperature = 0.0. Anything above that risks a syntactically valid-looking response that's actually got a stray comma or a mismatched bracket, because the model gambled on a slightly-less-likely token at the wrong moment. Save higher temperatures for tasks where variety is the point, brainstorming, roleplay, creative copy, never for anything a parser has to read afterward.

Top-P and Top-K: narrowing the field before temperature even applies

These two settings filter the candidate pool before temperature scaling happens, and you'll rarely need to tune both at once:

  • Top-K caps the candidate pool to a fixed number , top_k = 40 means only the 40 most likely next tokens are even considered, no matter how the probabilities are distributed.
  • Top-P (nucleus sampling) is more adaptive: it keeps adding candidates, most-likely first, until their combined probability crosses a threshold , top_p = 0.95 keeps whatever set of tokens covers 95% of the likely probability mass, which might be 5 tokens or 50 depending on how confident the model is.

In practice: if you've already set temperature = 0.0, top-p and top-k barely matter, since the model is only picking the single top token anyway, leave them at their defaults. If you're deliberately running at a higher temperature for a reasoning or brainstorming task, top_p = 0.95 is a reasonable way to keep some variety while still pruning obviously bad low-probability tokens.

Max output tokens: the limit that silently breaks JSON parsing

This one causes more confusing bugs than it should. max_output_tokens caps how much the model is allowed to generate in a single response, and if you set it too low for the task (say, 256 tokens for something that needs to generate a few hundred lines of code), the response gets cut off mid-token, mid-line, mid-anything. The result looks exactly like a parsing bug: a JSONDecodeError, invalid Python syntax, a truncated file. It isn't a parsing bug. It's a limit set too tight.

What goes wrong

MistakeHow you notice itThe fix
Structured output occasionally fails to parseIntermittent JSONDecodeError, works most of the timeSet temperature = 0.0 for anything parsed downstream
Output cuts off mid-file or mid-sentenceTruncated code, unterminated JSON, missing closing bracketsRaise max_output_tokens , check the actual length of a full expected response first
Creative/brainstorming output feels flat and repetitiveEvery run produces nearly identical phrasingRaise temperature for tasks where variety is actually wanted, don't leave everything at 0.0
Tuning top-p and top-k together with no clear reasonUnpredictable behavior that's hard to reason aboutPick one (usually top-p) and leave the other at its default, tuning both at once rarely adds value

Confirm it worked

To verify that your temperature setting produces stable, deterministic results, run this script to invoke the model multiple times and assert that the response format remains completely consistent:

python
# Run the same structured-output prompt 20 times at temperature 0.0
# and confirm every single response parses cleanly, if even one fails,
# the problem is the prompt's structure, not the temperature setting.
results = [call_model(prompt, temperature=0.0) for _ in range(20)]
assert all(is_valid_json(r) for r in results)

Next: Day 2 , Agent Tools & Interoperability, where your agent starts reaching real APIs and executing real code.