The meter starts when the compute is held, not before

Paying by the hour only means something if you know which hours count. On E31 Network, the hours that count are the hours compute is held for your job. Not the hours since you submitted it. Not the hours it waited in a queue. Not the hours after the output came back. The meter is designed to start when compute is held and stop when it is released, and this article is about why that line is drawn where it is.

One thing to say first: no rates are published. The preview describes the mechanism, by the hour, meter stops when the job finishes, and nothing more. The numbers come when access opens.

Three states, one of them paid

A job on the network can be in one of three broad states before it finishes. It can be submitted, meaning the description has been received but no compute has been matched to it. It can be queued, meaning it is waiting for compute of the shape it requested to become free. Or it can be renting, meaning compute has been held for it and the work is either about to start or under way.

Only the third state is designed to be metered. The first two cost the submitter nothing, because in neither state is anything set aside for the job. This is the design's way of keeping the bill tied to the thing being rented rather than to the submitter's patience.

From rent through run

The meter starts at the rent step, when compute is held, and continues through the run step, while the work proceeds. In the five-step picture of a job's life, rent and run are the two paid steps. Submit comes before the meter; output and release come as it stops.

Holding compute and running on it are metered together because, from the pool's point of view, they are the same thing. Compute that is held for one job is unavailable to every other job, whether the held compute is reading staged data, mid-training, or writing results. The submitter pays for exclusive use of the compute for the hours it is held, and the work is what fills those hours.

Why not meter from submission

A meter that ran from submission would make the queue a cost. A long queue would punish the submitter for the pool being busy, which is the one thing the submitter cannot control. It would also push teams toward submitting late and hoping compute is free, which defeats the purpose of a queue that can absorb work overnight.

Starting the meter at rent removes that pressure. A team can submit a job in the afternoon, let it wait until compute frees up in the evening, and pay for only the hours the job actually held compute. The article on the queue explains why this is what makes a shared pool viable in the first place.

What stops the meter

The meter stops at release. A job releases its compute when its output has been returned to the submitter, or when it reaches the limit stated in its request. The design intent is that a job declares how long it needs, or asks to run until done with a limit, so the hours held are bounded by something the submitter chose.

After release, nothing is owned and nothing is left running, so there is nothing to meter. What was held is accounted for, and the record of what was rented and for how long is the basis of the bill. The piece on release covers that accounting.

What the preview does not say

The preview describes a mechanism and nothing else. There are no published rates. There is no minimum, no discount for volume, no commitment term, no credit, and no tier. None of those exist in the design as published, and none should be assumed. When rates are published, they will be published alongside access, and until then the honest answer to "what does it cost" is that the mechanism is by the hour and the figure is not yet known.

For the full shape of the design, how it works covers the sequence in brief, and the examples show four illustrative requests and how the meter would behave for each.