Quota-aware effort pacing

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

/effort auto-selects the effort level based on task complexity. It doesn't consider how much quota remains in the current session or weekly window.

This means users either:

• Run at high/max early in the week and hit limits by Wednesday
• Manually track usage and adjust effort themselves
• Get silently downgraded when limits hit, mid-task

There's no way to pace effort across a usage window the way you'd pace a budget across a billing period.

Proposed Solution

A new effort mode — something like /effort pace — that factors remaining quota into effort selection alongside task complexity.

The core signal is a pace ratio:

pace = (fraction of quota remaining) / (fraction of time window remaining)

• pace > 1 → under-spending, room for xhigh/max
• pace ≈ 1 → hold at default (high)
• pace < 1 → ahead of burn, step down
• pace << 1 → near exhaustion, drop to low or suggest model switch

Since the 5-hour session cap and weekly cap run concurrently, take min(pace_session, pace_weekly). On Max plans the Opus-only weekly cap needs its own term — the right response to a depleted Opus budget is a model switch, not an effort drop.

Design considerations

1. Hysteresis over per-turn re-evaluation. Changing effort between requests invalidates cached prefixes. Re-evaluate only at boundaries (session start, post-/compact, post-reset), with a deadband (~0.15 on either side of the thresholds) to prevent flapping. Bias asymmetrically: fast to step up in the first third of a window, slow to step down.

1. Visibility over silent degradation. The failure mode is a hard debugging session quietly running at low priority because Tuesday was busy. Better to hold at high and surface a warning ("pacing suggests medium — holding high for this task") than to silently degrade output quality. The status line or a one-line context note would work.

1. Explicit override wins. A manual /effort max should disable pacing for the remainder of the session. The user's intent takes precedence.

1. Burn rate estimation. A simple quota/time average is dominated by history you can't change. An EWMA with a short half-life (~30-45 min for a session, ~half a day for weekly) tracks current activity. time_to_exhaustion = remaining_quota / burn_rate is more intuitive than the raw ratio and easier to surface to the user ("at this pace you'll run dry 6h before reset").

1. The effort ladder isn't linear. Reported comparisons suggest a high-effort path uses roughly 7x the tokens of a lower level on identical prompts. The pace→level mapping needs calibrated per-step weights, not even spacing.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_