Skip to content

0.8.0: hold cooling trims in the envelope, prompt version 6 - #9

Merged
AddisonTech merged 6 commits into
mainfrom
v0.8.0
Oct 22, 2026
Merged

AddisonTech merged 6 commits into
mainfrom
v0.8.0

Conversation

@AddisonTech

@AddisonTech AddisonTech commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner

Why 0.7.0 ramped more than 0.6.0

  • The hourly series gave 1.0374 where the KPI said 1.0358 because CityLearn's ramping denominator is built inside each run. In hour 399 (an outage) the agent asked for extra cooling, which lowered the reference and added 0.71 kWh of rises to the denominator only.
  • Split exactly by cause (scripts/split_ramping.py), the rise from 0.6.0 is the battery: charging accounts for +1.72 of +1.84 points. 0.7.0 charged and discharged about a third less and rarely cut the daytime peak. The trims are the largest single cause in every run but look much the same in both.

What changed

  • Envelope rule trim_hold: a trim stays at least as deep while the room is occupied and more than 0.5 C below its setpoint, eases off by at most 0.02 per hour within 0.5 C, and ends at once at or above the setpoint, when unoccupied, or with no baseline cooling. Every action is logged with its reason. Older runs replay without it (EnvelopeConfig.v070()).
  • Prompt version 6 (default): the hold stated in the prompt; end_trim with a reason per building is the only early end, shown in the viewer; strategy_battery (the v5 strategy's battery plan) replaces the 0.4.0 reference_action. Requests are 4.8 percent larger than v5.
  • scripts/evaluate_hold.py, scripts/split_ramping.py, tune_strategy.py --version 6.

Estimates (no live calls)

  • 0.7.0 live replies through the 0.8 rules (control reproduces 0.7.0 exactly): ramping 1.0358 to 1.0249, cost 0.9169, emissions 0.9477, discomfort 0.0511, daily peak 0.9284; worse than 0.6.0 live on all-time peak (0.9548) and ramping, and load factor worse than 0.7.0 (0.9787).
  • Scripted v5 strategy through the 0.8 rules: phase 2 ramping 0.9966 to 0.9957, cost 0.9015 to 0.9017 and discomfort 0.0424 to 0.0430 slightly worse. Tuning set: ramping, daily peak and load factor slightly worse, cost and emissions slightly better.
  • The battery change in prompt v6 can only be measured live.
  • Haiku month about $0.66, hard worst case $0.99 under the $2.00 cap.

Live results (claude-haiku-5-5, full month, prompt version 6)

  • Cost 0.9190, emissions 0.9610, discomfort 0.0769, daily peak 0.9264, all-time peak 0.9593, ramping 1.0076, load factor 0.9651, outage unserved energy 0.6850.
  • Beats the 0.4.0 rule-based controller on every KPI except outage unserved energy, by 0.0006. First live run with fewer too-cool and fewer too-warm hours than the baseline.
  • Missed the 0.8 goal of ramping below the baseline, and gave back the all-time peak against 0.6.0 live (0.9593 against 0.9483).
  • 312 of 719 hours clamped, mostly trim_hold on Building_1 and Building_3 cooling. 0 fallbacks, $0.5315 of $2.00, replays 719 of 719 hours.
  • Next for 0.9: cut the clamp rate without losing the gains.

Tests: 208 passed on Python 3.12, check_repo passed.

@AddisonTech
AddisonTech merged commit 8009de9 into main Oct 22, 2026
6 checks passed
@AddisonTech
AddisonTech deleted the v0.8.0 branch October 23, 2026 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant