Qoder's Fast tier is a model choice, but how long a task takes also depends on the harness around it. In a 2 November post the team listed the engineering it uses. Some work moves to build time: bytecode is generated when the release artifact is built instead of being parsed at startup, and identity, device and user-state initialisation run in the background so the interface opens before the configuration service is ready. Some preparation happens while the user is still typing, warming the Bash environment and collecting Git context, with Git warmup restricted to trusted directories and its cache tied to the working directory. Inside a round, the harness skips a summary call when a fetched page is already usable, routes auxiliary work such as page summaries and titles to cheaper models, keeps request prefixes stable so the backend can reuse cached prefixes, loads MCP tool definitions on demand instead of sending hundreds of schemas every round, writes oversized tool output to disk with a preview, compresses request bodies at the transport layer, and runs independent tool calls concurrently behind a barrier for writes. Interrupted sessions resume from what was already completed.
Our takeRead as a list of where latency actually lives, this is more useful than a tokens-per-second figure: startup compilation, context assembly, tool scheduling and recovery all sit between the user and the first useful action. But the post offers mechanisms without measurements. There is no per-stage timing before and after, and some changes trade one cost for another, since fetching tool schemas on demand adds a round trip and history compaction costs a model call while possibly dropping detail. So this is a checklist to reproduce, not evidence of a speedup. The missing piece is instrumentation t