[diegosouzapw]

Closes #3580

Problem

z.ai/GLM coding plans have no monthly quota (only 5-hour windows). The quota API returns the TIME_LIMIT ("Monthly") entry with total=0, and getGlmUsage computed remainingPercentage = total > 0 ? round(remaining/total*100) : 0 → a misleading Monthly 0% remaining, which can skew downstream model-choice.

Fix

Extracted glmMonthlyRemainingPercentage(total, remaining): with an absolute cap it stays remaining/total; with no cap (total=0) it falls back to the percentage-derived remaining (full/100% when 0% used) instead of 0.

⚠️ Inference-based: derived from the code path + the reporter's screenshot, without the raw z.ai coding-plan data.limits payload. The change is logically safe (no monthly cap ≠ 0% remaining) and guarded by a unit test; if the real payload routes differently we can refine with @gdevenyi's raw response.

Regression test (Rule #18 — TDD, RED→GREEN)

tests/unit/glm-coding-plan-monthly-3580.test.ts (4 cases): no-cap → 100%, absolute cap still remaining/total, clamping. Verified RED (3 fail returning 0) on the pre-fix logic, GREEN after. typecheck:core clean.

[gemini-code-assist]

Code Review

This pull request resolves an issue where the z.ai/GLM coding-plan quota card incorrectly displayed "Monthly 0%" when no monthly cap was set (total = 0). It introduces the glmMonthlyRemainingPercentage helper function to handle this fallback scenario and adds corresponding unit tests. The reviewer recommends refactoring the newly added unit tests to use Vitest's native test and expect APIs instead of Node's built-in test runner to maintain consistency with the project's testing framework.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The codebase is configured to use Vitest (as indicated by vitest.config.ts in the root and the repository style guide's reference to Vitest files). Using Node's built-in node:test and node:assert runner can lead to inconsistent test execution, missing coverage reporting, and fragmented assertion styles.

It is highly recommended to use Vitest's native test and expect APIs to ensure full integration with the project's test runner and coverage tools.

import { test, expect } from "vitest";

import { glmMonthlyRemainingPercentage } from "../../open-sse/services/usage.ts";

// #3580 — z.ai/GLM coding plans have no monthly cap (only 5-hour windows), so the
// quota API reports the TIME_LIMIT ("Monthly") entry with total=0. The previous
// `total > 0 ? … : 0` fallback rendered that as a misleading "Monthly 0% remaining",
// which can skew downstream model-choice. With no absolute cap we now fall back to the
// percentage-derived remaining (full/100% when 0% used).

test("#3580 no monthly cap (total=0), 0% used → 100% remaining (was 0%)", () => {
  expect(glmMonthlyRemainingPercentage(0, 100)).toBe(100);
});

test("#3580 no monthly cap (total=0), no usage signal → defaults to full (100)", () => {
  // remaining defaults to max(0, 100 - percentage); 0% used → 100
  expect(glmMonthlyRemainingPercentage(0, 100)).toBe(100);
});

test("#3580 absolute monthly cap still computes remaining/total", () => {
  expect(glmMonthlyRemainingPercentage(1000, 500)).toBe(50);
  expect(glmMonthlyRemainingPercentage(1000, 1000)).toBe(100);
  expect(glmMonthlyRemainingPercentage(1000, 0)).toBe(0);
});

test("#3580 clamps out-of-range values to [0,100]", () => {
  expect(glmMonthlyRemainingPercentage(0, 250)).toBe(100); // no cap, absolute remaining > 100 → clamp full
  expect(glmMonthlyRemainingPercentage(1000, 5000)).toBe(100);
  expect(glmMonthlyRemainingPercentage(0, -5)).toBe(0);
});

References

1. The repository style guide explicitly references Vitest files and configuration, indicating Vitest is the standard test runner for the codebase. ^(link)

[kilo-code-bot]

SUGGESTION: Redundant test case — this assertion is identical to the one on line 16 (glmMonthlyRemainingPercentage(0, 100) === 100). Consider removing one or varying the inputs to cover distinct scenarios.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
SUGGESTION	1

Issue Details (click to expand)

File	Line	Issue
tests/unit/glm-coding-plan-monthly-3580.test.ts	12	Redundant test case — assertion on line 12 is identical to line 16 (glmMonthlyRemainingPercentage(0, 100) === 100). Remove one or vary inputs to cover distinct scenarios.

Other Observations (not in diff)

No issues outside the diff.

Files Reviewed (3 files)

• CHANGELOG.md - No issues
• open-sse/services/usage.ts - No issues
• tests/unit/glm-coding-plan-monthly-3580.test.ts - 1 suggestion

Fix these issues in Kilo Cloud

---

_{Reviewed by step-3.7-flash · 280,862 tokens}