Found while reviewing #2475.
What is true today
Two tool descriptions in the workspace tool set are well over 1024 characters:
| tool |
chars |
source |
update_task |
1629 |
apps/web/src/lib/ai/tools/task-management-tools.ts:50 |
get_activity |
1608 |
apps/web/src/lib/ai/tools/activity-tools.ts:295 |
Both are registered through TOOL_MODULES in apps/web/src/lib/ai/core/ai-tools.ts, so they ride in the same payload as everything else. Nothing in apps/web/src/lib/ai truncates a description before it is sent.
Why that is a question
OpenAI documents a 1024-character cap on tools[n].function.description, and the cloud models here are served through OpenRouter, which forwards tool definitions to the vendor verbatim. If that cap were enforced as documented, every turn that registers these tools against an OpenAI-served model would fail outright — not degrade, fail — with an error that names a string length and nothing an operator would connect to a tool description.
That is evidently not happening, or we would know. So one of these is true and we do not currently know which:
- The cap is not enforced (or not for these routes/providers), and the documented limit is advisory. Then nothing is broken and the limit should stop being cited as a constraint.
- The cap IS enforced on some provider or model we do not exercise often, and those turns are failing for users on that path today.
Why it matters beyond these two
#2475 added a 1024-char budget test over the session/shell/layout tool family. That guard is honest about being a size budget (long descriptions are a per-request token cost) rather than a proven provider rule — precisely because these two tools disprove the strong reading. Whichever answer is right, it should be established once and applied consistently, rather than each PR guessing.
What would settle it
A single request per provider path (OpenRouter → openai/gpt-*, the on-prem azure_openai path, Anthropic, Gemini) with a >1024-char tool description, recording which reject and with what error. Then either raise/remove the budget, or shorten these two and enforce it across the flattened registry.
Found while reviewing #2475.
What is true today
Two tool descriptions in the workspace tool set are well over 1024 characters:
update_taskapps/web/src/lib/ai/tools/task-management-tools.ts:50get_activityapps/web/src/lib/ai/tools/activity-tools.ts:295Both are registered through
TOOL_MODULESinapps/web/src/lib/ai/core/ai-tools.ts, so they ride in the same payload as everything else. Nothing inapps/web/src/lib/aitruncates a description before it is sent.Why that is a question
OpenAI documents a 1024-character cap on
tools[n].function.description, and the cloud models here are served through OpenRouter, which forwards tool definitions to the vendor verbatim. If that cap were enforced as documented, every turn that registers these tools against an OpenAI-served model would fail outright — not degrade, fail — with an error that names a string length and nothing an operator would connect to a tool description.That is evidently not happening, or we would know. So one of these is true and we do not currently know which:
Why it matters beyond these two
#2475added a 1024-char budget test over the session/shell/layout tool family. That guard is honest about being a size budget (long descriptions are a per-request token cost) rather than a proven provider rule — precisely because these two tools disprove the strong reading. Whichever answer is right, it should be established once and applied consistently, rather than each PR guessing.What would settle it
A single request per provider path (OpenRouter →
openai/gpt-*, the on-premazure_openaipath, Anthropic, Gemini) with a >1024-char tool description, recording which reject and with what error. Then either raise/remove the budget, or shorten these two and enforce it across the flattened registry.