🚨 Production bug, currently live (commit 1)

next-steps-oss failed 100% of real requests (7/7) the moment it got live traffic today , confirmed via Understudy's raw capture export. This is systemic to every oss call site that carries tools, not specific to next-steps; strategist-oss, crm-updater-oss, and crm-updater-haiku-oss are on the same flag right now and will fail identically the instant they see real traffic.

Root cause: gpt-5.6-sol's /chat/completions upstream defaults reasoning_effort to a value incompatible with function tools whenever the request carries any:

"Function tools with reasoning_effort are not supported for gpt-5.6-sol in /v1/chat/completions.
To use function tools, use /v1/responses or set reasoning_effort to 'none'."

The oss-workload-segmentation PR (#2829, merged) already found and fixed this once , for automationAgentSol/automationAgentOssByPattern in automations.ts (covers meeting-prep-oss, daily-agenda-oss, pipeline-review-oss, coach-meeting-oss, coach-weekly-oss, inbound-email-notifier-oss, custom-subagent-oss, and strategist's scheduled/cron path , these are all fine). It was never applied to the other oss call sites added in that same PR, all of which also carry tools.

Fixed (commit 1)

• next-steps-oss (updateNextStepsAndTasksTool.ts) , confirmed broken
• strategist-oss (strategist-updates.ts), crm-updater-oss / crm-updater-haiku-oss (conversation-field-updates.ts) , same pattern, live flag, not yet triggered
• drafter-oss, orchestrator-oss, analyzer-oss, chat-oss (5 call sites), both on-event-*-orchestrator-oss variants , same pattern, flags currently 0%
• stage-classification-oss , patched defensively (uses generateObject, not confirmed broken)

Each fix: providerOptions: { openai: { reasoningEffort: 'none' } }, gated on the same useOss/equivalent flag each call site already resolves.

Update (commit 2): crm-updater / strategist / next-steps move to Kimi K3

Per follow-up request: these three named-default tasks now route to Kimi K3 instead of Sol , still via Understudy, still gated by the same cedar-oss-system-subagents flag (already active 100% for <email> and <email> only , no flag change needed). meeting-prep/daily-agenda/pipeline-review/coach-meeting/coach-weekly/inbound-email-notifier/crm-updater-haiku stay on Sol, unaffected.

Tested before wiring in (learning directly from the incident above): two standalone scripts ran real requests against the live Understudy gateway (kimi-k3, real tool schemas matching crm-updater's actual shape):

• Single-turn tool call: real tool_calls in the response, finish_reason: 'tool_calls' , works with the default request shape, no special providerOptions needed.
• Multi-step continuation (tool call → tool result fed back → final text): clean finish_reason: 'stop' with a real text answer , matches the actual agent-loop shape these three call sites run (maxSteps 10,15).
• Critically: explicitly setting reasoning_effort: 'none' (the exact fix commit 1 just shipped for Sol) makes kimi-k3 stop emitting real tool_calls and start echoing a malformed pseudo-XML <tool_call> block in the text content instead , a silent, harder-to-detect failure than Sol's explicit 400. So commit 2 does the opposite of commit 1 for these three call sites: reverts the reasoningEffort:'none' override back to plain THINKING_DISABLED_PROVIDER_OPTIONS.

Added KIMI_MODEL = 'kimi-k3' to models.ts (re-exported from resolve-model.ts alongside SOL_MODEL).

Also surfaced (not fixed here)

Cedar's own llm_request_failed structured logging (Axiom, cedar-prod-logs) has zero record of the Sol failures from commit 1 , the openai/Sol-family fetch path doesn't appear to carry the same error-logging wrapper the Anthropic path has. Only diagnosable via understudy captures export --include-payload against the raw r