Rate Loom

A rate is a relationship

A device does not have one useful speed for every creative task. A render frame and a training batch describe different work, and a measurement only becomes helpful when it remains connected to the conditions that produced it. Rate Loom makes that relationship the starting point of a comparison.

The visual idea of weaving is practical here. Each task contributes a strip of time, while each device supplies a different set of rates. Changing one measured rate changes that task's contribution rather than applying a vague speed multiplier to the whole queue. The resulting pattern can reveal where the wait actually accumulates.

A mixed queue also makes sequencing visible. The desk estimates tasks one after another. It does not quietly borrow concurrency to make the total more attractive. This limited model is useful when its assumptions match the work; when they do not, its boundaries need to remain part of the discussion. Clarity comes from a readable relationship between inputs and results, not from adding more impressive decimal places.

The desk estimates each task using its own remaining units and the selected device’s rate. Memory compatibility is checked before a finish time is offered. Logged attempts retain their cost while completed units reduce remaining work. Plans run sequentially, and the comparison can be exported. The default rates are illustrative inputs, not measured hardware claims.

Change one task-specific rate and watch the finish time move. Notice the consequence before adding another step. This presentation does not connect a hosted service or issue a token; its claim is the small interaction you can actually inspect.