Redundant condition in model name check

name === "MiniMax-M*" is already covered by name.toLowerCase().startsWith("minimax-m") since "MiniMax-M*".toLowerCase() is "minimax-m*", which starts with "minimax-m". The || branch is dead code and could be confusing to future readers.

This is a comment left during a code review.
Path: src/infra/provider-usage.fetch.minimax.ts
Line: 338

Comment:
**Redundant condition in model name check**

`name === "MiniMax-M*"` is already covered by `name.toLowerCase().startsWith("minimax-m")` since `"MiniMax-M*".toLowerCase()` is `"minimax-m*"`, which starts with `"minimax-m"`. The `||` branch is dead code and could be confusing to future readers.

```suggestion
      (name.toLowerCase().startsWith("minimax-m")) &&
```

How can I resolve this? If you propose a fix, please make it concise.

Thanks for the catch! This has been fixed in the follow-up commit (f1935c2) — removed the redundant name === "MiniMax-M*" branch, now only using name.toLowerCase().startsWith("minimax-m").

Falsy guard rejects epoch 0

if (startTime && endTime && ...) treats startTime === 0 (Unix epoch) as a missing value. While a real MiniMax window starting at January 1 1970 is practically impossible, using an explicit !== undefined guard is a bit safer and clearer:

This is a comment left during a code review.
Path: src/infra/provider-usage.fetch.minimax.ts
Line: 264

Comment:
**Falsy guard rejects epoch 0**

`if (startTime && endTime && ...)` treats `startTime === 0` (Unix epoch) as a missing value. While a real MiniMax window starting at January 1 1970 is practically impossible, using an explicit `!== undefined` guard is a bit safer and clearer:

```suggestion
  if (startTime !== undefined && endTime !== undefined && endTime > startTime) {
```

How can I resolve this? If you propose a fix, please make it concise.

Good point — fixed in f1935c2. Now using startTime !== undefined && endTime !== undefined instead of the falsy guard.

Append model name even when MiniMax returns plan_name

For coding_plan/remains payloads that include both model_remains and the usual top-level plan_name/plan fields, this nullish-coalescing chain stops at the existing plan label and never adds modelName. The repo’s own MiniMax fixtures already cover that shape in src/infra/provider-usage.test.ts:180-192, so the output stays as the ambiguous Coding Plan instead of the intended Coding Plan · MiniMax-M* for a common response format.

Useful? React with 👍 / 👎.

Valid observation. In the current real-world MiniMax coding-plan API response, the plan_name/plan field is not present at the top level — the plan info is only derivable from model_remains[].model_name. However, if MiniMax adds an explicit plan_name in the future, this would indeed shadow the model-specific label. I'll keep this in mind for a follow-up if the API shape evolves. For now, the current behavior correctly handles the known response format.

Preserve payload-level fallback for hybrid MiniMax responses

When model_remains is present, this narrows candidate discovery to chatRemains and stops scanning the rest of the payload. If MiniMax returns a hybrid shape where the selected chat entry only carries model metadata/timestamps but the actual quota fields still live in a sibling object (for example a top-level usage block), usedPercent now stays null and we return Unsupported response shape, whereas the previous collectUsageCandidates(payload) path would still parse it.

Useful? React with 👍 / 👎.

Acknowledged. The current MiniMax coding-plan API puts all quota fields (current_interval_usage_count, current_interval_total_count, start_time, end_time) directly inside each model_remains[] entry, so chatRemains is self-contained. If MiniMax introduces a hybrid shape with quota fields split between model_remains and a sibling object, a broader fallback would be needed. The legacy collectUsageCandidates(payload) path is still reachable when model_remains is absent, so backward compatibility is preserved.

Derive the window label from the chosen usage record

collectUsageCandidates(usageSource) can still pick a nested child inside the selected model_remains entry as usageRecord, but this branch always derives the label from the outer chatRemains object whenever model_remains exists. For responses where the nested child carries window_hours/window_minutes and the parent only carries model metadata, the UI regresses to the default 5h label instead of the actual window even though the correct usage record was found.

Useful? React with 👍 / 👎.

This is a fair trade-off. In the follow-up commit (f1935c2), I changed the logic to use `chatRemains` directly for `deriveWindowLabel` when it's available, since the timestamps (`start_time`/`end_time`) live at the `model_remains[]` entry level. If a future API revision moves `window_hours`/`window_minutes` into a nested child, the fallback chain in `deriveWindowLabel` (explicit hours → explicit minutes → timestamps → default "5h") would still produce the correct result as long as the timestamps remain on `chatRemains`.

Handle epoch-string timestamps when deriving the window label

deriveWindowLabelFromTimestamps() now reads start_time/end_time straight through parseEpoch(), but parseEpoch() only understands numeric values or ISO-like date strings. A MiniMax payload that serializes those epochs as strings (for example "1736217600") will therefore skip the new timestamp logic and fall back to the hard-coded "5h", even though the actual window is present. The surrounding reset parsing already goes through pickNumber(...) to accept numeric strings, so this new path is inconsistent with the rest of fetchMinimaxUsage() for that common JSON shape.

Useful? React with 👍 / 👎.

Keep scanning model_remains when fallback row lacks usage

The fallback here picks the first model_remains record with current_interval_total_count > 0, even if that row has no usable usage fields. In fetchMinimaxUsage, that chosen row becomes usageSource, so later model_remains rows are never evaluated; if a later row contains the actual quota counters, the function now returns Unsupported response shape instead of producing usage data. This is a regression from the previous payload-wide scan for responses that omit minimax-m* rows or place incomplete rows first.

Useful? React with 👍 / 👎.