Ask an optimization team how fast their solver is and they will quote a benchmark: a gap to optimal after so many minutes on a reference instance. Ask a planner the same question and they will describe their day. Only the second answer decides whether the solver gets used.
Solve time is not an engineering metric to be minimized after the model is built. It is a product constraint that determines what kind of tool the model is, and it should be chosen before the first line is written.
What a planner does with 3 seconds
A planner who gets an answer in 3 seconds does something specific with it: asks another question. Move the cutoff an hour, add the late order, take 1 truck out, split the wave in 2. In an 8 hour day, a 3 second solver supports hundreds of these exchanges. The plan that ships is the end of a conversation, and the planner owns it because they built it.
A planner who gets an answer in 3 hours does something equally specific: schedules the run. Inputs are frozen in the evening. The result arrives overnight. By the time anyone reads it, 2 orders have changed, a vehicle is off the road, and a customer has moved a delivery window. The planner edits the plan by hand, and every edit is made without the solver, because there is no time to run it again. The model is reduced to a suggestion. Within a few months it is a suggestion nobody reads.
Both solvers may be the same code. The first is a decision tool. The second is a report.
Optimality is bought with staleness
Every planning system makes a trade, and most make it without noticing. Pushing the optimality gap from 2 percent to 0.5 percent might cost 10 times the solve time. The 1.5 percent of cost that buys is real. But it is 1.5 percent of a plan computed against inputs that are 3 hours older, and in the operations we have seen, 3 hours of changes to orders, vehicles, and arrival times costs more than 1.5 percent of the plan's value. The precise answer to the wrong problem is worth less than the approximate answer to the current one.
That trade has a shape. The value of a plan decays with the age of its inputs, quickly in a dense last mile network and slowly in a monthly capacity plan. The value of a tighter gap grows with the size of the cost being optimized. The time budget should be set where those 2 curves cross, and the crossing point is a property of the operation, not of the algorithm.
Set the clock first
Once the time budget is fixed, the engineering follows from it, and it is different engineering. A 3 second budget rules out solving the whole problem from scratch on every call. It calls for decomposition into pieces that can be solved independently, warm starts from the previous plan so that a small change in inputs produces a small change in the answer, and incremental re-optimization that touches only the part of the plan the new information affects. It calls for honest heuristics where exact methods cannot meet the clock, with the gap measured and reported rather than hidden.
A 3 hour budget allows a monolithic exact model and makes all of that unnecessary. It also commits the product to being a batch report, with everything that follows.
Neither choice is wrong. Making it by accident is, and that is what happens when the model is built first and the solve time is discovered later. The question to ask at the start is not how good the answer must be. It is how long the person waiting for it is willing to wait, and what they will do with it when it arrives.