mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
efrazer-oai
c8e5db16c9
## Summary
Enterprise users can have an effective monthly credit limit, but Codex
`/status` currently drops that metadata from the account-usage response.
This change adds the optional `spend_control.individual_limit`
projection to the existing rate-limit snapshot flow. The backend client
reads the monthly limit, app-server exposes it as `individualLimit`, and
the TUI renders a `Monthly credit limit` row through the existing
progress-bar renderer.
When the backend does not return an effective monthly limit, existing
rate-limit behavior is unchanged.
## Existing backend state
The account-usage backend already returns the effective monthly limit
and current usage together:
```json
{
"spend_control": {
"reached": false,
"individual_limit": {
"limit": "25000",
"used": "8000",
"remaining": "17000",
"used_percent": 32,
"remaining_percent": 68,
"reset_after_seconds": 86400,
"reset_at": 1778137680
}
}
}
```
Before this change, Codex projected rolling `primary` and `secondary`
windows plus `credits`. It ignored `spend_control.individual_limit`, so
app-server clients and `/status` could not render the monthly cap.
The updated flow is:
```text
account usage backend
-> backend-client reads spend_control.individual_limit
-> existing rate-limit snapshot carries optional individual_limit
-> app-server exposes optional individualLimit
-> TUI renders Monthly credit limit
```
## App-server contract
`account/rateLimits/read` and sparse `account/rateLimits/updated`
notifications now include an additive nullable
`rateLimits.individualLimit` field:
```json
{
"individualLimit": {
"limit": "25000",
"used": "8000",
"remainingPercent": 68,
"resetsAt": 1778137680
}
}
```
In an `account/rateLimits/read` response, `null` means no monthly limit
is available. `account/rateLimits/updated` remains a sparse rolling
notification: clients merge available values into their most recent
`account/rateLimits/read` snapshot or refetch. Nullable account metadata
in a rolling notification does not clear a previously observed value.
## Design decisions
- Extend the existing rate-limit snapshot instead of introducing a
separate request or wire-level update protocol.
- Keep the Codex projection narrow: `/status` needs the effective limit,
current usage, remaining percentage, and reset timestamp.
- Render the monthly row through the existing progress-bar renderer,
with one optional detail line for `8,000 of 25,000 credits used`.
- Keep the backend response optional so existing accounts and older
usage states preserve their current behavior.
- Preserve cached monthly metadata when sparse rolling notifications
omit it. Live account-usage reads remain authoritative and can clear a
removed limit.
## Visual evidence
```text
Monthly credit limit: [██████████████░░░░░░] 68% left (resets 07:08 on 7 May)
8,000 of 25,000 credits used
```
Snapshot:
`codex-rs/tui/src/status/snapshots/codex_tui__status__tests__status_snapshot_includes_enterprise_monthly_credit_limit.snap`
## Testing
Tests: generated app-server schema verification, protocol tests,
backend-client tests, app-server integration coverage, TUI snapshot
coverage, formatting, and workspace lint cleanup.
80 lines
2.1 KiB
Rust
80 lines
2.1 KiB
Rust
use super::*;
|
|
use codex_protocol::protocol::RateLimitReachedType;
|
|
|
|
fn snapshot(
|
|
primary_used_percent: Option<f64>,
|
|
secondary_used_percent: Option<f64>,
|
|
) -> RateLimitSnapshot {
|
|
RateLimitSnapshot {
|
|
limit_id: Some(crate::guard_limits::CODEX_LIMIT_ID.to_string()),
|
|
limit_name: None,
|
|
primary: primary_used_percent.map(window),
|
|
secondary: secondary_used_percent.map(window),
|
|
credits: None,
|
|
individual_limit: None,
|
|
plan_type: None,
|
|
rate_limit_reached_type: None,
|
|
}
|
|
}
|
|
|
|
fn window(used_percent: f64) -> RateLimitWindow {
|
|
RateLimitWindow {
|
|
used_percent,
|
|
window_minutes: None,
|
|
resets_at: None,
|
|
}
|
|
}
|
|
|
|
#[test]
|
|
fn startup_check_uses_configured_remaining_threshold() {
|
|
let snapshot = snapshot(
|
|
/*primary_used_percent*/ Some(89.9),
|
|
/*secondary_used_percent*/ Some(50.0),
|
|
);
|
|
|
|
assert!(snapshot_allows_startup(
|
|
&snapshot, /*min_remaining_percent*/ 10
|
|
));
|
|
assert!(!snapshot_allows_startup(
|
|
&snapshot, /*min_remaining_percent*/ 11
|
|
));
|
|
}
|
|
|
|
#[test]
|
|
fn startup_check_skips_when_primary_or_secondary_is_too_low() {
|
|
assert!(!snapshot_allows_startup(
|
|
&snapshot(
|
|
/*primary_used_percent*/ Some(75.1),
|
|
/*secondary_used_percent*/ Some(10.0),
|
|
),
|
|
/*min_remaining_percent*/ 25,
|
|
));
|
|
assert!(!snapshot_allows_startup(
|
|
&snapshot(
|
|
/*primary_used_percent*/ Some(10.0),
|
|
/*secondary_used_percent*/ Some(75.1),
|
|
),
|
|
/*min_remaining_percent*/ 25,
|
|
));
|
|
assert!(snapshot_allows_startup(
|
|
&snapshot(
|
|
/*primary_used_percent*/ Some(74.9),
|
|
/*secondary_used_percent*/ Some(74.9),
|
|
),
|
|
/*min_remaining_percent*/ 25,
|
|
));
|
|
}
|
|
|
|
#[test]
|
|
fn startup_check_skips_when_limit_is_reached() {
|
|
let mut snapshot = snapshot(
|
|
/*primary_used_percent*/ Some(10.0),
|
|
/*secondary_used_percent*/ Some(10.0),
|
|
);
|
|
snapshot.rate_limit_reached_type = Some(RateLimitReachedType::RateLimitReached);
|
|
|
|
assert!(!snapshot_allows_startup(
|
|
&snapshot, /*min_remaining_percent*/ 25,
|
|
));
|
|
}
|