Why there is no fixed runtime estimate

tCode deliberately does not print a runtime estimate before starting a turn, because it genuinely does not know in advance how many tool calls a given task will need until it has actually started working through it.

As a rough sense of scale rather than a promise: a single-file fix with one edit and no test run is typically the quickest kind of turn you will see. A multi-file refactor that searches broadly, edits several files, and then runs a test suite at the end is meaningfully longer.

That longer case is usually dominated less by the model's own reasoning time and more by however long your own commands, particularly the test run at the end, actually take to finish executing on your machine.

Not printing an estimate is a deliberate choice over printing an unreliable one; a rough guess that turns out wrong half the time would be worse than no guess at all, since it would train you to distrust a number that was never meant to be load-bearing in the first place.

If a rough sense of scale genuinely matters before starting, the fastest way to get one honestly is describing the request and asking directly, "roughly how much does this touch", which draws on the same understanding of your codebase the turn itself would use, rather than a generic estimate.