P3 [CRF-1] xerrors.Errorf wraps a nil error when the trailing-colon guard fires independently of uuid.Parse.

When hasEffort && rawEffort == "" is true but uuid.Parse succeeded (err == nil), xerrors.Errorf("parse chat model override: %w", nil) produces a non-nil error with message "parse chat model override: %!w(<nil>)". The error path is correct (an error is returned), but the message is nonsensical.

Fix: produce a specific error when the trailing-colon guard fires, e.g. xerrors.New("parse chat model override: trailing colon with empty reasoning effort").

(Netero)

🤖

Coder Agents generated.

Fixed. The parser now returns a specific error for the trailing colon with empty reasoning effort case instead of wrapping a nil error.

Verified fixed in b4d5ac05. The parser now returns a specific error via xerrors.New for the trailing colon case.

🤖

P3 [CRF-2] parsedModelOverride / parseModelOverride duplicates parsedChatModelOverride / parseChatModelOverride from coderd/exp_chats.go:521, and a third copy exists in ParseChatPersonalModelOverride (personal_model_override.go:65-79).

All three implement the same uuid[:effort] parsing: strings.Cut(trimmed, ":") + uuid.Parse(rawID) + hasEffort && rawEffort == "" guard + effort extraction. The only differences are return types (pointer vs value UUID, error vs bool). A shared helper would eliminate the divergence risk.

(Netero, Robin)

🤖

Coder Agents generated.

Not changed intentionally. These parsers have distinct API/storage semantics and return shapes, so sharing a helper here would add indirection without eliminating much code. Keeping them separate also avoids coupling chatd title override parsing to the HTTP storage parser.

Panel closed (5/7 accept). Five reviewers confirmed the return types and error semantics differ enough to justify separate implementations. The coupling cost of merging outweighs the duplication risk for ~8 lines of shared logic.

🤖

P3 [CRF-3] Double DB lookup for the same model config in putUserChatPersonalModelOverride.

validateUserChatModelConfigAvailable (line 5319) internally looks up the model config via userCanUseChatModelConfig. lookupEnabledChatModelConfigByID (line 5324) then looks up the same parsedModelConfigID again to feed validateChatModelOverrideEffort. The model config could be returned from the first validation step. Compare with putChatModelOverride which uses the combined validateChatModelOverride that looks up once.

(Netero, Pariston)

🤖

Coder Agents generated.

Fixed. validateUserChatModelConfigAvailable now returns the validated model config, and putUserChatPersonalModelOverride reuses it for reasoning effort validation instead of doing a second lookup.

Verified fixed in b4d5ac05. validateUserChatModelConfigAvailable now returns the model config, eliminating the second DB lookup.

🤖

P2 [CRF-4] putChatModelOverride accepts reasoning effort embedded in model_config_id, creating an undocumented secondary input channel and GET/PUT asymmetry.

parseChatModelOverride parses the storage format uuid:effort from req.ModelConfigID. When the field contains "uuid:high" and reasoning_effort is null, the embedded effort is silently promoted (lines 5075-5077). But the GET response always separates them (line 5042 passes nil for effort to formatChatModelOverride). This creates two asymmetries:

1. GET/PUT mismatch: GET returns {"model_config_id": "uuid", "reasoning_effort": "high"}, but PUT also accepts {"model_config_id": "uuid:high"} without the explicit field.
2. Endpoint mismatch: putUserChatPersonalModelOverride parses req.ModelConfigID as a plain UUID (line 5305: uuid.Parse(rawModelConfigID)). Sending {"model_config_id": "uuid:high"} to the deployment override PUT succeeds; the same payload to the personal override PUT fails.

Fix: parse req.ModelConfigID as a plain UUID in the PUT handler, taking effort only from req.ReasoningEffort. Remove lines 5075-5077. This keeps the internal storage parser separate from API input parsing.

(Hisoka P2, Knov P2, Kite Nit)

🤖

Coder Agents generated.

Fixed. putChatModelOverride now parses model_config_id as a plain UUID and rejects encoded uuid:effort API input. The stored override parser remains in place for reading the internal persisted format.

Verified fixed in b4d5ac05. PUT now rejects : in model_config_id and accepts reasoning_effort as a separate field. GET/PUT symmetry restored. Test PUTRejectsEncodedModelConfigID confirms.

🤖

P2 [CRF-5] Error message "Invalid reasoning_effort." drops the Detail field and uses inconsistent wording compared to the same check elsewhere in this file.

Three sibling checks in the same file (lines 1312, 3241, 3409) use:

Message: "Invalid reasoning_effort value.",
Detail:  "Must be one of none, minimal, low, medium, high, xhigh, max.",

This new check uses only Message: "Invalid reasoning_effort." with no Detail. An admin hitting this at the override settings endpoint gets no guidance about valid values.

Fix: match the existing pattern.

(Leorio P2, Chopper P3)

🤖

Coder Agents generated.

Fixed. The invalid reasoning effort response now uses the same message as the sibling checks and includes the valid value detail.

Verified fixed in b4d5ac05. Error messages now include valid values in Detail, consistent with sibling checks. Note: CRF-20 flags an edge case in this fix where SelectableReasoningEfforts returns nil for non-reasoning models.

🤖

P3 [CRF-7] withResolvedReasoningEffort silently drops the admin-configured reasoning effort override when modelConfig.Options fails to unmarshal or re-marshal, with no log or error signal.

Both json.Unmarshal (line 427) and json.Marshal (line 442) errors return the original unmodified modelConfig. The function has no logger access and no doc comment explaining the fail-open contract. Its single caller (title_override.go:90) receives a modelConfig that looks valid but carries the model's base reasoning effort instead of the admin override.

The Options field is validated at write time, so corruption is unlikely. But the pattern sets a precedent where config deserialization failures silently degrade behavior. At minimum, the caller has logger access and could log when the returned config doesn't reflect the requested effort. A doc comment explaining the intentional fail-open behavior would prevent the next editor from treating the silent returns as bugs.

Additionally, this function has zero test coverage. Four exit paths (nil effort, unmarshal failure, nil resolved effort, success), none tested.

(Hisoka P3, Mafu-san P3, Meruem P3, Chopper P3, Knov P3)

🤖

Coder Agents generated.

Not changed intentionally. The fail-open behavior is low impact because Options is validated on write, and preserving the original config on unexpected marshal/unmarshal failure avoids breaking title generation for a corrupt row. I did not add the suggested broader logging/test changes in this PR5 fix pass.

Panel closed (4/6 accept). The fail-open design is appropriate for the title generation best-effort path. Options corruption requires bypassing write-side validation. Test coverage is tracked separately as CRF-18.

🤖

P3 [CRF-8] parseChatModelCallConfig duplicates unmarshalChatModelCallConfig at line 7744 of this file.

Both take json.RawMessage, unmarshal into *codersdk.ChatModelCallConfig, and check for empty input. The new function returns (ptr, error) with a zero struct on empty; the existing one returns nil on empty/error and also checks isZeroChatModelCallConfig. A shared core function returning (*ChatModelCallConfig, error) could serve both callers, with unmarshalChatModelCallConfig wrapping it to apply the zero check and swallow errors.

(Robin)

🤖

Coder Agents generated.

Not changed intentionally. The helpers differ semantically: this validation path must surface JSON errors to callers, while the existing unmarshal helper intentionally returns nil for empty, invalid, or zero configs. Sharing the core would add branching without making the call sites clearer.

Panel closed (6/6 accept). The two functions have genuinely different contracts: validation (surfaces errors) vs display (swallows errors). Sharing would require error-handling branching less clear than two short functions.

🤖

P3 [CRF-9] The selectability validation error doesn't include the selectable values despite having the computed slice available on line 595.

The message explains the constraint ("value is not selectable for the model config") but doesn't name the selectable set. The admin knows their value is wrong but has to guess what the model config allows.

Fix:

return http.StatusBadRequest, &codersdk.Response{
    Message: "Invalid reasoning_effort: value is not selectable for the model config.",
    Detail:  fmt.Sprintf("Must be one of %s.", strings.Join(selectableEfforts, ", ")),
}

(Leorio P3, Chopper P3)

🤖

Coder Agents generated.

Fixed. The selectability validation response now includes a Detail listing the selectable reasoning effort values for the model config.

Verified fixed in b4d5ac05. Selectability error now includes the selectable values via strings.Join. Note: CRF-20 flags an edge case where selectableEfforts is nil.

🤖

Note [CRF-12] When postChats uses a personal override's reasoning effort (line 1308), it validates with IsValidReasoningEffort (is this a known value?) but not SelectableReasoningEfforts (is this value within the model's current max?).

Scenario: user stores personal override with effort "high" for a model whose max is "high". Admin later lowers the model's max to "medium". User creates a chat. "high" passes validity, the chat stores LastReasoningEffort = "high", but generation_preparer.go clamps it to "medium" at runtime via ResolveReasoningEffort.

The runtime behavior is correct (clamped), and the same gap exists for the direct req.ReasoningEffort path at this line, so this is consistent with the existing design. The stored metadata diverges from what was applied, but there's no user-facing impact. Worth knowing if metadata correctness becomes important.

(Hisoka)

🤖

Coder Agents generated.

Not changed intentionally. Runtime clamping remains consistent with the direct per-turn reasoning effort path, so stored metadata can be above the current max but execution resolves to the allowed value.

Acknowledged. Runtime clamping is correct and consistent with per-turn effort path.

🤖

Note [CRF-13] When an admin lowers a model's max reasoning effort after a user saved their personal override, the form holds the stale stored value while the UI slider shows the clamped value from pickReasoningEffort. Saving without touching the slider submits the original "high" value, which the backend rejects as not selectable.

The backend validation is correct, so this isn't a data integrity issue. The window is narrow (requires admin config change after user override). The user would see a save failure and can adjust.

(Knov)

🤖

Coder Agents generated.

Not changed intentionally. The stale UI case fails closed: if an admin lowers max effort after a saved override, the backend rejects the stale value on save and the user can adjust it. No data integrity issue is introduced.

Acknowledged. Fails closed in a narrow window. No data integrity issue.

🤖