AI Parameter Glossary (Every Setting, Defined)

TL;DR: This glossary defines the AI generation settings that two other references on this site don't already own: a fourth meaning of max_tokens on OpenAI's original Completions endpoint, everything about Google's new Interactions API (which dropped sampling parameters and a numeric thinking budget entirely), the structured-output fields it just deprecated, and a case-convention trap between Gemini's image sizes and Veo's video resolutions.

What Counts as an "AI Parameter," and How Is This Different From a Cheat Sheet?

A parameter, here, is any named setting a request body accepts to shape generation — a cap, a penalty, a format hint, a reasoning dial. That sounds like it should already be a solved reference on this site, and mostly it is: our LLM parameter cheat sheet is a genuinely exhaustive value table for OpenAI, Anthropic and Google's three major chat-completion surfaces, and our prompt engineering glossary already defines the sampling parameters, the penalty trio, and a first set of image and video terms in plain English.

This page exists for what's left over. Two things changed the parameter surface since those were written: Google shipped a genuinely new API, the Interactions API, generally available since June 2026 and now Google's own recommended default for new projects — and it handles settings differently enough to need its own coverage. And OpenAI's original Completions endpoint (the one behind gpt-3.5-turbo-instruct, davinci-002 and babbage-002) reuses a field name from Chat Completions with a third, distinct meaning that neither of those posts mentions. Every fact below is checked against a vendor's own published reference, fetched directly in September 2026.

How Many Names Actually Mean "Maximum Output Length"?

Four, and they belong to three vendors, with one vendor splitting the name across two different endpoints with two different meanings.

That fourth row is the one missing from every cross-vendor table I've seen, including our own cheat sheet, because it belongs to an endpoint most current guidance has stopped mentioning. OpenAI's original Completions API — the /v1/completions endpoint, still live behind the older instruct-style models — defines its own max_tokens field: "The maximum number of tokens that can be generated in the completion. The token count of your prompt plus max_tokens cannot exceed the model's context length." That field carries a documented default of 16 and a minimum of 0. That's a genuinely different field from Chat Completions' deprecated max_tokens, which caps a chat-shaped response and is flagged deprecated: true in OpenAI's own specification. Same string, same vendor, two different schemas, two different meanings.

One rule holds across every row in that table, on every vendor: every one of these fields caps output only. None of them touch how much you can send in. Prompt length is bounded by the model's context window, a completely separate number.

Stop Sequences and Penalties: Same Idea, Different Ceilings

Two settings families that look interchangeable across vendors and aren't.

Stop sequences end generation the moment a matched string appears. OpenAI's own spec is direct about the count: "Up to 4 sequences where the API will stop generating further tokens." It separately notes stop sequences are "Not supported with latest reasoning models o3 and o4-mini." Google's stopSequences field allows "up to 5" character sequences. Anthropic's stop_sequences carries no documented count cap at all. Google's newer Interactions API keeps a stop_sequences field too, and its own reference describes it only as "A list of character sequences that will stop output interaction." No count is stated there either.

Penalties are where vendors genuinely disagree, not just on names but on whether the setting exists at all.

Anthropic's Messages API reference has zero occurrences of either frequency_penalty or presence_penalty — genuinely absent, not merely undocumented in one place. Google exposes both fields, but its own reference never states a numeric range or default for either one, which our cheat sheet already flags and this page confirms independently. Hugging Face's repetition_penalty looks like a third name for the same idea and isn't: it's a separate, multiplicative mechanism, and its own docs state plainly: "1.0 means no penalty." There is no equivalent to OpenAI's negative range that actively encourages repeated tokens. Our prompt engineering glossary has the full worked comparison between the additive and multiplicative mechanisms; this page won't repeat that derivation.

What Changed in Structured-Output Settings This Year?

If you learned Gemini's JSON mode as responseMimeType plus responseSchema, that pairing is now flagged deprecated on the API you probably still use. Google's own generateContent reference marks both fields explicitly: responseSchema (deprecated) and _responseJsonSchema (deprecated), each carrying the line "This item is deprecated!" generateContent itself remains fully supported — only these two specific fields carry the label, not the whole endpoint.

The replacement lives on Google's newer Interactions API, where output-format configuration moves to a top-level response_format array rather than a generationConfig sub-object, with a distinct configuration type per output modality:

• TextResponseFormat: mimeType plus an optional schema, applicable when the MIME type is JSON.
• AudioResponseFormat: mimeType, delivery mode, sampleRate, and bitRate (only applicable for compressed formats).
• ImageResponseFormat: mimeType, delivery, aspectRatio, and imageSize as a formal enum (IMAGE_SIZE_FIVE_TWELVE, IMAGE_SIZE_ONE_K, IMAGE_SIZE_TWO_K, IMAGE_SIZE_FOUR_K, the last described in the reference as "4K image size").

OpenAI and Anthropic didn't stand still either, just less dramatically. OpenAI's Chat Completions keeps response_format; its Responses API moved the same configuration under text.format instead, with no response_format field on that endpoint at all. Anthropic's structured output lives under output_config.format, a JSONOutputFormat object taking type: "json_schema" plus a schema map.

Does Every Vendor Still Expose Sampling Knobs?

Increasingly, no — and Google's newest API is the sharpest version of that trend. Our cheat sheet already covers the state of temperature, top_p and top_k on the three major chat-completion surfaces in full (Anthropic deprecated all three on current models, OpenAI never shipped top_k at all, Google's generateContent still has the classic set). What's new here is the Interactions API specifically.

The formal GenerationConfig reference for the Interactions API lists exactly six fields: max_output_tokens, seed, speech_config, stop_sequences, thinking_level, and thinking_summaries. None of temperature, top_p, top_k, frequency_penalty or presence_penalty appear in that schema.

For how thinking-related settings specifically split between a numeric budget and a level across all three vendors, see our companion piece on thinking budgets and reasoning limits — it covers thinking_level, thinkingBudget, reasoning_effort and output_config.effort in full, and this page won't repeat that ground.

What's the Case-Convention Trap in Media-Generation Settings?

A narrower gotcha, but a real one, verified across two different Gemini surfaces: the exact same vendor documents size and resolution settings with different casing depending on which field you're populating, and there's no rule that transfers between them.

Gemini's image-generation config documents its size field as a plain string: "Specifies the size of generated images. Supported values are 512, 1K, 2K, 4K. If not specified, the model will use default value 1K." Uppercase K, no exceptions listed. Veo's video-generation config documents its resolution field with different values entirely: "720p" (default), "1080p" (only supports 8-second duration), and "4k" (also only supports 8-second duration) — lowercase k this time, and paired with duration constraints that the image field has no equivalent of.

Two settings, same rough concept (how big or how detailed the output is), same vendor, two different literal string conventions. The practical rule: never assume the casing from one field carries to a similarly-named field elsewhere, even inside one vendor's own API. Copy the exact value your source documents for the specific field you're setting.

This is exactly the kind of setting that fails silently rather than loudly. A request body with the wrong case on an enum-shaped string field commonly gets accepted, then quietly ignored or defaulted, rather than rejected outright with an error you'd actually notice. If a size or resolution setting seems to have no effect, check the literal casing against the reference page for that specific field before assuming the parameter itself is broken. A single throwaway request against a cheap model is a faster way to confirm the accepted casing than reading through changelogs looking for it.

Where to Go for the Parts This Glossary Doesn't Own

This page is deliberately narrow. For the rest of the parameter surface:

• Full ranges, defaults and tool-choice values across OpenAI, Anthropic and Google's chat-completion APIs: the LLM parameter cheat sheet.
• What temperature, top-p and top-k actually do, and when to tune them: our sampling-parameters explainer.
• Thinking budgets versus effort levels, across all three vendors: our companion reference on thinking budgets.
• How system, developer and user roles resolve against each other in the API: our provider-by-provider comparison.
• Prompting techniques, training vocabulary and the penalty-mechanism deep dive: our prompt engineering glossary.

A Copy-Paste Comparison of the Structured-Output Shift

The same "return JSON matching a schema" request, on Google's old field names and its new ones, side by side.

// generateContent — the fields marked deprecated in Google's own reference
{
  "contents": [{ "parts": [{ "text": "List three failure modes for this deploy." }] }],
  "generationConfig": {
    "responseMimeType": "application/json",
    "responseSchema": {
      "type": "OBJECT",
      "properties": { "failure_modes": { "type": "ARRAY", "items": { "type": "STRING" } } },
      "required": ["failure_modes"]
    }
  }
}

// Interactions API — the replacement: a top-level response_format array
{
  "model": "gemini-3.8-flash",
  "input": "List three failure modes for this deploy.",
  "response_format": [
    {
      "type": "text",
      "mime_type": "application/json",
      "schema": {
        "type": "object",
        "properties": { "failure_modes": { "type": "array", "items": { "type": "string" } } },
        "required": ["failure_modes"]
      }
    }
  ]
}

generateContent still runs both requests today. Only the first shape carries the deprecated label.

Sources and Access Dates

Every field, range and default above traces to a primary document, fetched directly in early September 2026:

• OpenAI: the published OpenAI OpenAPI specification, openapi.yaml.
• Anthropic: the Messages API reference, fetched as raw markdown.
• Google: the generateContent API reference, the Interactions API's formal reference, its overview and migration guide, and the Veo guide.
• Hugging Face: the Transformers text-generation reference, for repetition_penalty specifically.

Parameter surfaces move on the order of months, and a new API landing mid-year is exactly the kind of change that ages a cheat sheet built even a few weeks earlier. Check the schema reference, not the prose around it, before you trust any single field.