Smart Color in detail

The precise mechanics of the Smart algo: three risk components, how they combine, and the HSB interpolation that maps the score to a legible color.

Threshold mode (static)

The simple, fallback mode. Maps raw utilization percentage to three colors via two sliders.

• util >= critical (default 85%) -> red
• util >= warning (default 60%) -> orange
• otherwise -> green

Used when Smart Color is disabled, or when the API doesn't return a reset date for a given bucket.

Smart mode (the v5.0 rewrite)

Replaces the old "threshold + pacing combined via max" logic which produced false negatives at the worst moments (98% used / 30 min remaining stayed green). Smart v2 is fully continuous - no cliffs, no discrete decision points.

Three risk components

Combined via max() so the worst signal wins, then mapped to a color via smooth HSB interpolation.

• Absolute risk -> how close are you to the limit itself? A smoothstep ramp between a low bound and a high bound that depend on your profile. This is what makes 98% used always trigger red, regardless of time remaining.
• Projection risk -> if you keep this rhythm, will you overshoot? Computes u / e (utilization over elapsed fraction) - a value > 1 means you'll overshoot. Damped by a confidence factor at the start of the window, so a burst at 5% used / 1% elapsed doesn't panic the gauge.
• Pacing risk -> are you burning faster than the linear rhythm, beyond your margin? Looks at the absolute delta vs the ideal pace at this point of the window.

Why projection health matters

The absolute component is damped by a projection health multiplier. When your current rhythm projects a comfortable finish below the limit, the "you burned a lot" signal is calmed.

Concrete example: 72% used at 4h12 on a 5-hour window with relaxed pacing. Without the multiplier, the absolute component alone would trigger orange. With it, projection health is ~0.53, absolute drops to 0.25, and the gauge stays chill - because at this rhythm you'll finish around 86%, which is fine.

At 98% used / 30 min remaining, projection health saturates at 1, absolute triggers at full power, and the gauge goes red. That's exactly the case the v1 algo missed.

HSB interpolation

The continuous risk score is mapped to a color via 4 anchors (chill at 0.0 and 0.30, warning at 0.55, critical at 0.85 and 1.0). Interpolation between adjacent anchors goes through HSB space, not linear sRGB.

Why? Linear sRGB interpolation between green and orange falls on a muddy olive (~#8E9D3A) at the midpoint, which appears in the gauge whenever risk floats around 0.5. HSB hue rotation takes the natural path of the color wheel (green -> yellow -> orange -> red), turning that same midpoint into a vivid yellow-green that reads cleanly.

Your theme's anchor colors stay intact - HSB only governs what happens between them.

Edge cases

• Utilization > 100% -> threshold and smart both return red (hard cap). Pacing also lands hot.
• No reset date -> smart falls back to absolute-only (no projection / pacing). The pacing UI degrades gracefully (a sparkles glyph instead of the zone icon, no track).
• Custom theme without pacing-warning color -> the decoder substitutes the default orange. You can edit it later via the custom theme picker.
• Reduce Motion -> color transitions still apply (color is information, not motion). Spring animations on value changes are reduced.