Summary

Production incident, 2026-09-22T14:44 UTC: the orchestrator workload (Cedar's general-purpose orchestrator subagent, mastra/agents/sub-agents/orchestrator-agent.ts) started 400ing 100% of Understudy-routed requests:

x-understudy-tags key 'userId' must match /^[a-z0-9][a-z0-9-]{0,63}$/

Confirmed via understudy reporting workload-status (workload degraded, 5/5 requests failed) and Axiom's cedar-prod-logs llm_request_failed events , production only, nothing in cedar-staging-logs. Aamir flagged it in Slack and is making a platform-side change on Understudy to tolerate this case; this PR fixes the root cause on Cedar's side too.

Root cause

understudyHeaders() (services/llm/understudy.ts) already sanitizes tag values , its own doc comment explains this was fixed once before for exactly this reason (Better Auth userIds are mixed-case). It never sanitized tag keys. orchestrator-agent.ts builds its tags with object-shorthand:

tags: { userId, ...(agentId ? { agentId } : {}), ...(orgId ? { orgId } : {}) }

The key userId is the literal camelCase JS property name, passed straight through to x-understudy-tags unsanitized , and it independently fails the exact same regex Understudy validates values against.

Fix

• understudy.ts: understudyHeaders() now runs every tag key through the same sanitizer as values (renamed sanitizeUnderstudyTagValue → sanitizeUnderstudyTagToken since it now does both). This protects every current and future call site automatically , there are ~20 across the codebase, and any camelCase tag key anywhere would have hit this same bug.
• orchestrator-agent.ts: renamed the three tags: {...} call sites to kebab-case (user-id/agent-id/org-id) for clarity at the source, even though the central fix makes this redundant.
• Added a regression test asserting the exact incident: a camelCase tag key must never survive understudyHeaders() unsanitized.

Test plan

• pnpm --filter @zero/server run types , clean
• pnpm deps:check , no violations
• resolve-model.test.ts (updated existing assertions for the new sanitized-key contract, added a dedicated regression test) + 3 other affected suites , 58/58 passed
• Staging traffic spot-check once deployed , confirm no x-understudy-tags key ... failures recur

🤖 Generated with Claude Code

https://claude.ai/code/session_012WwyQEcVnYQzkB4Fxsfpx6

Confidence Score: 4/5

The request-rejection fix appears safe to merge, with a non-blocking hardening issue around silent collisions between normalized tag keys.

Findings

1.  Normalized keys can collide ▶

### Issue 1
apps/server/src/services/llm/understudy.ts:45-48
This normalization is many-to-one: for example, `user_id` and `user-id` both become `user-id`, while `ENV` becomes `env`. Because the resulting pairs are passed to `Object.fromEntries`, one tag silently replaces the other and a caller can also replace the built-in environment tag. Since this API accepts arbitrary `Record<string, ...>` keys, please detect collisions after normalization rather than silently losing telemetry dimensions.

---

For ea