Conversation
…eat it Production logs after #141: the MILP consumes its full 4 s slice on essentially every split (tb p50 4.06 s, p95 4.28 s) and improves the schedule on only half of them. Measured over 16 captured splits, everything it finds arrives within 2.5 s - capping there returned the identical preference value on 15 of 16, the 16th lost 1.7e-6, and cuts-off lost quality on 6 so it stays on. The rest of the slice bought proof, not schedule, and every deep tail request now gets it back as response time (median elapsed 10.05 s to 8.66 s on the sample). PREFERENCE_TIME_SHARE keeps reserving 0.4: that is what the cost stage may not eat, and shrinking it is a separate decision about the cost stage's own budget. Requests without a time limit stay uncapped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
andig
force-pushed
the
perf/cap-the-milp-tie-break-spend
branch
from
August 23, 2026 09:20
791b2bf to
2621dd7
Compare
andig
force-pushed
the
fix/relax-the-cost-bound-when-cbc-cannot-hold-it
branch
from
August 23, 2026 09:20
08bd0f9 to
8b250b3
Compare
The reserve held back 0.4 of the limit so the tie break would not find the clock gone. The MILP tie break has since been capped at 2.5 s, so on the production 10 s limit the reserve idled 1.5 s the cost stage could have used. Production showed the price: the revision that introduced the reserve alone took p95 from 0.99 s to 1.41 s with the share of solves at the limit unchanged. 0.25 of 10 s is the cap exactly, with the LP floors in the margin. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
andig
added a commit
that referenced
this pull request
Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What production showed (via #141's logs)
The tie-break MILP consumes its full 4 s reserved slice on essentially every split request (tb p50 = 4.06 s, p95 = 4.28 s) and improves on the LP floor for only ~49% of them. The other half burn the slice and keep the floor.
Measurement
16 captured production splits, four variants, preference value vs the deployed 4 s slice:
Everything the MILP finds arrives within ~2.5 s (first incumbent ~1.3 s via DiveCoefficient; the 245-step model seats in 1.6 s). The remainder of the slice buys proof, not schedule.
cuts offdegrades quality — rejected.Change
MILP_PREFERENCE_TIME_LIMIT = 2.5caps the MILP solve; the 0.4PREFERENCE_TIME_SHAREreserve is untouched — it bounds what the cost stage may eat, and shrinking it is a separate decision about the cost stage's budget. No-time-limit requests stay uncapped, so golden solves are unchanged.Expected in production: split-path elapsed p50 drops ~1.4 s (6.9 → ~5.5 s), p99 and replica-driven cost follow. The #141 log line will show the effect directly.
Stacked on #142.
🤖 Generated with Claude Code