The -x flag defining the exploration level is a way to set a trade-off between computing time and solution quality. But in some situations (think huge instances) this parameter can be hard to tune. Also no matter the size it's sometimes interesting to reach out to a time-constrained solution ("give me the best solution you can get in X seconds").

We could add a -l LIMIT flag to pass in input a number of seconds the optimization run is allowed to span.

A few thoughts:

1. I think it's clearer if the value passed describes the overall computing limit, thus including parsing the input and retrieving the matrix from the routing engine (time after solving used for routing request and solution formatting is negligible here).
2. The point is to be able to stop the local search if it's taking too long based on the LIMIT value, but I don't think it makes sense at all to stop the heuristic process of getting initial routes. This means that actual computing time may be higher than LIMIT if the heuristic process has not completed before. My guess is that in most situations this would really only happen if the LIMIT is set to an unrealistically low value.
3. We can probably use seconds as unit for this parameter as I don't really see the point in using a higher precision.