By the hour, not by the month

A monthly bill for compute measures time that passed. An hourly bill for a job measures time that was used. E31 Network is being designed around the second kind: the meter starts when compute is held for a job and stops when the job is finished and the compute is released. Nothing is billed for the month, because nothing is held for the month.

What a month actually buys

A monthly commitment buys the right to use some amount of compute for the whole month, whether or not there is work for it. That is a reasonable arrangement for a workload that runs around the clock. For a workload that runs in bursts, the month is mostly paying for the hours in between.

The trouble is that the month looks cheap on the day the contract is signed, because it is compared against the peak. The team imagines the busiest week and reasons that the monthly figure is fair for that. The quiet weeks are not in the picture. They arrive later, as hardware that is paid for and doing nothing.

What an hour would buy

On the network, the unit is the job, and the job is what the hour is attached to. A job declares the work it runs, the data it reads, the request it makes of the pool, and the output it expects back. When the request is granted, compute is held for that job, and the hours start counting.

The hours stop when the job finishes. Not at the end of the month, not at the end of a billing cycle, and not when someone remembers to turn something off. Release is the last step in the life of every job, and the meter stopping is part of that step rather than something the team has to arrange separately.

The team is paying for two of the five steps in a job's life: rent and run. Submitting a job costs nothing. Waiting in a queue costs nothing. Getting the output back and releasing the compute costs nothing. The bill is the hours the compute was held, and that is all.

The queue is what makes the hour honest

An hourly rate without a queue would be a worse deal than it sounds, because it would push every team to hold compute in case the next job arrives. That is the monthly commitment reconstructed by hand.

The network is being designed so that a job that can wait goes into a queue until compute is free, and the meter does not run while it is queued. The team does not need to hold anything in advance. It submits the job, the job waits for its turn, and the hours begin only when the compute is actually held for it.

This is why the network is for batch and asynchronous work only. A job that cannot tolerate a queue would need compute held in reserve for it, and compute held in reserve is a month, not an hour. Real-time work stays on the team's own systems, where holding capacity in reserve is the correct design rather than a waste.

What has not been published

The rate per hour has not been published. There is no minimum, no commitment term, no discount schedule, and no credit system described anywhere, because none of those have been designed in public and the program will not describe mechanics it has not settled. When access opens, rates will be published with it.

What has been settled is the unit and the shape. The unit is the job. The shape is hourly, for the hours held, with the meter stopped at release. Everything else about pricing is an open question, and the program would rather say so than fill the gap with a figure that would have to be withdrawn.

For how a job moves through the five steps, see how it works. For why the hours a team does not use are the hours that cost the most under a monthly model, see idle capacity is the cost nobody budgets.