We've fixed this problem over and over again. Can you please scan for _all_ u...
We've fixed this problem over and over again. Can you please scan for all uses of max_tokens? This just broke in production. Also, why are we even using this parameter? @repo/api:dev: [15:14:21.639] INFO (canvas-sync/88538): Sync completed @repo/api:dev: semesterId: "spring2026" @repo/api:dev: enrolled: 0 @repo/api:dev: dropped: 0 @repo/api:dev: reactivated: 0 @repo/api:dev: typeChanged: 0 @repo/api:dev: newUsers: 0 @repo/api:dev: totalActive: 11 @repo/api:dev: [15:14:59.280] ERROR (llm-explore/88538): Azure OpenAI API error @repo/api:dev: status: 400 @repo/api:dev: errorText: "{\n "error": {\n "message": "Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.",\n "type": "invalid_request_error",\n "param": "max_tokens",\n "code": "unsupported_parameter"\n }\n}" @repo/api:dev: [15:14:59.280] ERROR (http/88538): Request failed @repo/api:dev: method: "POST" @repo/api:dev: path: "/api/llm-explore" @repo/api:dev: status: 500 @repo/api:dev: duration: 140
Only one raw max_tokens use: apps/api/src/routes/llm-explore.ts:122. Everywhere else in the codebase already uses max_completion_tokens or max_output_tokens through packages/llm/src/chat.ts.
Why the parameter exists: the Probability Explorer only needs 1-3 tokens back per completion (just the next word, with slack for multi-token words like Java+Script). Capping output keeps 15-way sampling cheap. The parameter itself is fine — it's just the name that's wrong for newer Azure deployments (even behind the /gpt-4o/ URL, Azure's rejecting max_tokens now).
Fixing:
Why e2e missed it: every test in testing/e2e/tests/llm-explorer.spec.ts mocks /api/llm-explore via page.route(...).fulfill(...) (lines 48, 77, 110, 135, 156, 176). The route handler that actually calls Azure is never exercised, so a parameter the model rejects is invisible to the suite. All of the chat() helpers in packages/llm/src/chat.ts already use max_completion_tokens, so the bug only lived on the one raw-fetch path that had no real-API coverage.
Options for a real guard (pick one, none of these are free):
- A smoke-level test that hits Azure without mocking — catches parameter drift but costs tokens and needs creds in CI.
- A contract test that POSTs a shape-only request (e.g.
max_completion_tokens: 1) to the real endpoint on deploy, gated to dev. - Lint rule / grep in CI that rejects
max_tokens:in source (cheap, catches exactly this regression, zero runtime cost).
Given this keeps recurring, I'd lean on #3 as the belt, with #2 only on deploy. Want me to wire up the grep check?
Why can't we create an interface here that allows us to use typescript to check the request shape?
Yes.
Your task
First, run git status, git diff, and git log --oneline -10 to understand the current state.
Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.
Clean diff — no debug statements. All three files are one logical change (fix + prevention), so one commit. Committing now.
Committed as 85963c6. Working tree clean, one commit ahead of origin/main.
Your task
First, run git status, git diff, and git log --oneline -10 to understand the current state.
Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.
Just a formatter collapse of the import into a single line — no debug cruft.
Committed as bb43f16. Two commits now ahead of origin/main.
Is the email container working? Also (1) what's the 404 and (2) why does it say 27 recipients? There should just be 11... [Image #2]
[Image source: ~/.claude/image-cache/1a958456-696b-4253-a7ad-b708b87736f7/2.png]
Let's create all@ which goes to applicants, and have students@ just go to students. Also ... 27? Really? Is that list deduplicated? Also it should still include [email], right? And I never received the latest message.
Can you check the relay logs?
Your task
First, run git status, git diff, and git log --oneline -10 to understand the current state.
Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.
No debug statements or suspicious logging. Three files, two logical changes — but they're tightly related (the route fix and list restructure are both mail fixes from the same investigation), so one commit makes sense.
Committed as 173ab50. Three commits ahead of origin/main, working tree clean.