Trim over-cap prompts to fit, and say so — instead of dead-ending

[mikkel]

The report

An LLM node writing the prompt for a qwen-image-3 Image node produced 831 characters and the run died:

400 {"error":"Your prompt is too long for Qwen Image 3. Please shorten it to 800 characters
     or less (current: 831 characters).","code":"prompt_too_long"}

The prompt was wired. "Please shorten it" pointed at a field with no keyboard behind it.

How common (live probe, 183 of 214 image models, 2026-07-26)

45 models enforce a character cap at NanoGPT's route:

cap	models
512	step-image-edit-2
800	qwen-image-3 — the reported one, and a Featured model
1200	z-image-turbo family
3000	40 more (flux-schnell, qwen-image, hidream, riverflow-2-*, most Runware/CivitAI ids)
none at 6000	39 (nano-banana, flux-kontext, seedream-v4.5, …)

Video caps too (minimax-hailuo-02 = 2000, lightricks-ltx-2-fast = 3000, in a third error shape with no code field). The edit path caps identically. The catalogs advertise none of it — supported_parameters has resolutions, image constraints and LoRA slots, and nothing about text. Raw results: proof/prompt-caps/.

What ships

Trim to fit at a sentence boundary — and state it three times. The disclosure is the whole basis for doing it, so it's pinned as hard as the trim is:

• before the run — the node shows prompt limit 800 characters — a longer wired prompt is trimmed to fit, so the limit is visible while there's still time to pick a different model. Typed prompts get a live 690 / 800 counter, red once over.
• at the run — a toast: prompt trimmed to 800 characters for Qwen Image 3 (was 2785).
• after it — a note that stays on the node: ✂ trimmed 2785 → 794 characters to fit.

The cut never lands mid-word and never below 70% of the cap; it prefers a sentence end and falls back to a word boundary.

What deliberately does not ship: any rewriting of the graph's own prompts. An LLM node's system prompt reaches the model exactly as written — no injected "keep it under N characters" directive, wired or not. Shortening a prompt to dodge a cap is the user's call to make in their own words. The guard asserts this on both engines (no upstream prompt-budget injection, the cap code never writes a system field at all).

Learning. An unknown model's cap is parsed out of the live 400 and remembered, so the same model states its limit up front next run. Three error shapes are handled; the current: N figure is deliberately not readable as a cap (learning it would grow the limit with every failure).

Also closes the same hole on audio: TTS max_chars is catalog metadata, but it was only a textarea maxlength — a wired input walked straight past it.

What the trim actually costs — measured

proof/prompt-caps/verify-trim.mjs, five chat models on the reported graph, with the shipped fitPromptText:

model	written	sent	kept	cut at
celeris-1	1244	698	56%	word
openai/gpt-5-nano	1205	748	62%	sentence end
deepseek-chat	1866	719	39%	sentence end
claude-haiku-4-5-20251001	1292	641	50%	sentence end
meta-llama/llama-4-scout	2785	794	29%	sentence end

Plainly: an LLM writing an image prompt overshoots an 800-char cap every time (5/5, by 1.5–3.5×), so on a tight model the trim is the normal path and a third to two thirds of the generated text is dropped. That's the trade — a run that finishes and tells you what it cut, instead of one that fails. Four of five cuts landed on a sentence end; celeris-1 had no boundary above the 70% floor and fell back to a word, which is the fallback working.

End to end: the trimmed 794-character prompt (from 2785) generated on qwen-image-3 — the model that 400s at 831. Chrome verified in a real browser via CDP, no key, no spend.

Both engines

The editor and exported apps, which hit this harder because their users can't edit the prompt at all. scripts/check-prompt-caps.mjs pins it offline (wired into pre-commit as guard 40); all 40 existing guards pass.

Tooling & upstream

• scripts/probe-prompt-caps.mjs regenerates the table. Hand-run and spend-capable: route validation runs images → route resolution → prompt length → model size, so an over-long prompt plus an unsupported size is rejected free when the model caps — models that ignore size (~40%) generate and charge. --dry-run, --budget, --models, --max-price bound it; the 2026-07-26 sweep cost $1.60.
• docs/NANOGPT-prompt-length-metadata.md — the upstream ask. supported_parameters.max_prompt_chars on image/video (the audio catalog already does exactly this) would let the model picker show the cap, so someone picks a different model instead of losing two thirds of their prompt.

Companion PR for headless/agent runs: nanoodlecom/nanoodle-js#26.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	nanoodle	df8f832	Commit Preview URL Branch Preview URL	Jul 27 2026, 04:41 AM