Bug (macOS/DMG): GPT-5.x models fail with HTTP 400 — tinyagents sends max_tokens but these models require max_completion_tokens

[Al629176]

Summary

On a fresh macOS DMG install (unmodified), using GPT-5.4-mini or GPT-5.6-Luna as the main model causes every chat turn to fail immediately. The request reaches OpenAI successfully but is rejected with HTTP 400 because tinyagents sends max_tokens — a parameter these GPT-5.x models do not accept. The correct parameter is max_completion_tokens.

Problem

Exact error from OpenHuman logs:

tinyagents harness run failed: model error: model error: openai returned HTTP 400
(unsupported_parameter): Unsupported parameter: 'max_tokens' is not supported with
this model. Use 'max_completion_tokens' instead.

OpenAI's GPT-5.x model family (gpt-5.4-mini, gpt-5.6-luna, and likely the full family) dropped support for the max_tokens request field and require max_completion_tokens in its place. tinyagents is sending max_tokens unconditionally, so every turn with one of these models hard-fails before the model produces any output.

This is a parameter name mismatch in the tinyagents request builder — auth and connectivity are fine, the request reaches OpenAI, and OpenAI rejects it at the protocol level.

Reproduction

1. Fresh macOS DMG install (no source modifications).
2. Set main model to gpt-5.4-mini or gpt-5.6-luna with a valid OpenAI key.
3. Send any chat message.
4. Result: immediate failure, no response, HTTP 400 in logs.

Confirmed on:

• gpt-5.4-mini
• gpt-5.6-luna

Root cause

tinyagents constructs the OpenAI chat completion request with max_tokens. For GPT-5.x models this field must be max_completion_tokens. The fix needs to be applied at the request-building layer — either by detecting the model family and switching the field name, or by migrating to max_completion_tokens across the board (OpenAI accepts it for older models too).

Solution

• Replace max_tokens with max_completion_tokens in the tinyagents OpenAI request builder.
• Audit other OpenAI-compatible parameters that may have similar deprecation gaps in the GPT-5.x family.
• Regression-test with at least gpt-5.4-mini and gpt-5.6-luna to confirm chat turns complete successfully.

Acceptance criteria

• Sending a chat message with gpt-5.4-mini or gpt-5.6-luna returns a response — no HTTP 400 unsupported_parameter errors in logs.
• No regression for older models (gpt-4o, gpt-4-turbo, etc.) that currently work.
• Fix applied at the request-builder layer, not patched per individual model slug.

Related

• openhuman LLM hard-fails every turn (HTTP 400 stream=true missing), /orchestration/v1/steering 404, and .deb PATH broken on non-bash shells #5497 — same tinyagents/OpenAI parameter gap: stream=true missing for gpt-5.6-terra on Linux (different param, same class of bug)

[YellowSnnowmann]

Update (2026-08-12): the bare pin-bump is ruled out — CI-proven.
I tried delivery option (2)'s shortcut — a direct PR bumping release's vendor/tinyagents 3e1dbea → 27a3f39 (#5511, now closed). CI Full Gate failed to compile openhuman (lib): 27a3f39 added struct fields that release's code doesn't set —

error[E0063]: missing field `artifact` in initializer of `ToolMessage`
error[E0063]: missing field `served_from_cache` in initializer of `ModelResponse`
error[E0063]: missing fields `max_retry_after_ms` and `retry_on` in initializer of `tinyagents::harness::retry::RetryPolicy`

So a submodule bump alone cannot ship this; it needs the paired openhuman-side struct updates. Two viable paths remain: a main→release promotion (carries both together, self-heals), or the minimal backport below (3e1dbea + is_gpt5_family only, no struct changes, so it compiles against release) landed in tinyhumansai/tinyagents by a maintainer, then release's pin advanced to it.

---

Production fix plan (release)

The fix is on main but not in shipped release (what the DMG builds from), so this still reproduces on fresh installs:

• main pins vendor/tinyagents @ 27a3f39 — has the gpt-5 → max_completion_tokens routing.
• release (v0.63.7) pins 3e1dbea — pre-fix, is_reasoning_model only matches o1/o3/o4.

A straight pin-bump of release to 27a3f39 is not a safe hotfix. It drags 188 tinyagents commits (the LangChain-parity audit + the session_store → top-level session module move) into production, and release does not carry the openhuman-side adaptation that landed on main in #5446 (agent/session_db still lives in-repo on release). A release hotfix wants minimal blast radius.

Two clean options:

1. Promote main → release (preferred) — brings the tinyagents bump and the matching openhuman-side changes together, no divergence, zero extra code.

2. Minimal backport — if a full promotion isn't wanted yet, put just the gpt-5 detection onto the release-pinned tinyagents line and advance release's submodule pin to it. Prepared + verified:

   • Branch fix/5498-gpt5-max-completion off 3e1dbea (commit e742a25, on my fork YellowSnnowmann/tinyagents).

   • Folds is_gpt5_family into is_reasoning_model (mirrors main verbatim, so a later promotion merges cleanly); derive_profile inherits it via reasoning. ~35 lines, no API changes.

     pub(super) fn is_reasoning_model(model: &str) -> bool {
         let lower = model.to_ascii_lowercase();
         lower.starts_with("o1")
             || lower.starts_with("o3")
             || lower.starts_with("o4")
             || is_gpt5_family(&lower)
     }
     
     pub(super) fn is_gpt5_family(lower: &str) -> bool {
         lower.starts_with("gpt-5") || lower.starts_with("gpt5") || lower.contains("/gpt-5")
     }

   • Tests: new routes_max_tokens_to_max_completion_tokens_for_gpt5 (slug gpt-5.4-mini) + existing o-series + classic all pass; cargo fmt --check and build clean.

   • Delivery step that needs a maintainer (fork contributor here, no push on tinyhumansai/tinyagents): cherry-pick e742a25 onto a tinyagents ref, then a release-targeted openhuman PR bumping vendor/tinyagents to that commit — I can open that openhuman PR once there's a tinyagents commit to pin.

[tinysweeper]

#5498: GPT-5.x chat completions fail with HTTP 400 because tinyagents sends the deprecated max_tokens parameter instead of max_completion_tokens.

The issue is a bug in the OpenAI request-builder layer: GPT-5.x model family requires max_completion_tokens while tinyagents sends max_tokens unconditionally. The fix already exists on main (commit 27a3f39 with is_gpt5_family detection) but has not been promoted to the release branch that DMG builds ship from.

Workaround: use older model slugs (gpt-4o, gpt-4-turbo, etc.) which still accept max_tokens.

Labelled priority: p2.

This may be related to #5510. Left open either way — tinysweeper only closes an issue when the match is unambiguous.