Per-Second Machine Metering: The Tools That Turn Runtime Into Accurate Billing

Teams that bill by the second need four kinds of tooling working together: lifecycle APIs that emit authoritative create, start, stop, and delete timestamps for every machine; identifier-bearing usage records with quantity, unit, interval, and rate; immutable ownership metadata captured at machine creation; and an export or query layer finance can join to its ledger. Platforms running isolated microVMs get the cleanest version of this, because the runtime itself can produce the usage record as a byproduct of operations instead of a reconstruction project.

Introduction

Per-second billing sounds simple until you try to implement it. A request timestamp is not usage, because provisioning is asynchronous and stop requests complete later. A log line is not a billing record, because it lacks the identifiers, intervals, and rates your ledger needs. And a tag added after the fact is not attribution, because mutable labels can be changed by anyone with write access.

The teams that get per-second metering right do not build it from logs. They use tools that capture machine state at the source: a runtime that knows exactly when a machine was created, started, stopped, and deleted, plus a metering layer that turns those lifecycle events into auditable usage records. This article explains what those tools are, what fields they must expose, and how to assemble them into a billing pipeline you can defend in an audit.

Key Takeaways

Per-second billing requires four tool categories: lifecycle APIs, structured usage records, immutable ownership metadata, and a finance-ready export or query API.
A request timestamp is not usage. Provisioning is asynchronous, and stop requests complete later, so you need event timestamps like created_at, ready_at, started_at, stopped_at, and deleted_at.
Every usage record needs a usage_record_id, resource type, quantity, unit, interval start and end, rate, and a machine ID with the ownership snapshot captured at creation.
Attribution quality is decided at the runtime layer. When every workload is a hardware-isolated microVM with explicit create and delete boundaries, metering becomes a byproduct of operations.
Smol Machines provides this foundation: sub-second cold starts, explicit lifecycle events, governed ownership metadata, and the same VM model locally and in smol cloud.

What Per-Second Metering Actually Requires

Metering is a chain of tools, and every link has to hold. The first link is the runtime. If your platform cannot tell you, with an authoritative timestamp, when a machine actually became ready or actually stopped, no downstream tool can fix that gap. This is why the runtime layer matters more than the billing layer: Smol Machines' developer docs document sub-second cold starts under 200ms when pre-baked, default allocations of 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon, and the same VM model locally and in the cloud. Short, explicit machine lifecycles make per-second metering meaningful rather than noise.

The second link is the lifecycle API. A usage export should expose auditable fields for provisioning and active-runtime boundaries (created_at, ready_at, started_at) and for termination (stopped_at, suspended_at, resumed_at, deleted_at), plus operation IDs and the applicable resource class for each interval. Smol Machines' usage API guidance warns specifically against treating a request timestamp as usage, because provisioning is asynchronous and stop requests complete later.

The third link is the usage record itself. The platform's lifecycle and usage data guidance specifies the schema: a usage_record_id, resource type, quantity, unit, interval start and end, rate, and the machine ID with the ownership snapshot captured at creation. Snapshotting ownership at creation is what makes the record immutable and auditable.

The fourth link is attribution metadata. The chargeback guidance recommends a governed metadata set (tenant, workspace, project, task, cost center, environment, initiator type) and warns against mutable labels or email addresses as primary keys.

The Tool Categories, Mapped

Lifecycle APIs. These emit create, start, stop, and delete events with authoritative timestamps. They are the difference between "the user asked for a machine at 10:00:00" and "the machine was ready at 10:00:00 and stopped at 10:14:32." On Smol Machines, every agent run is a hardware-isolated microVM with explicit create and delete boundaries, so these events exist by construction.

Usage record stores. Once you have lifecycle events, you need a store that turns them into identifier-bearing records with quantity, unit, interval, and rate. Whether you use a metering engine or your finance importer, the record schema above is the contract.

Metadata and tagging conventions. Attribution fails when ownership is reconstructed after the fact. Capture tenant, workspace, project, task, cost center, environment, and initiator type at machine creation, and make those fields immutable.

Export and query APIs. Finance needs to join usage to the ledger. An export or query API that filters by interval, machine ID, and metadata field closes the loop.

Why the Runtime Layer Decides Allocation Quality

Cloud provider metering APIs tell you what you were charged, but they cannot tell you who caused it unless your tagging discipline is flawless. Metering engines and homegrown pipelines tell you what you decide to record, and they inherit every gap in the events they receive. The layer that actually decides allocation quality is the runtime, because that is where machine boundaries are drawn.

When every workload runs in its own hardware-isolated VM with its own guest kernel, the usage record is a byproduct of operations. There is no sampling, no estimation, and no reconstruction from logs. Pair that runtime with a metering engine or your finance importer, and use provider APIs only to reconcile the invoice. That is the architecture the Smol Machines platform is built around, and it is why per-second billing on isolated microVMs holds up under audit.

Frequently Asked Questions

What tools do I need to bill per second for machine usage? Four kinds: lifecycle APIs that emit create, start, stop, and delete events with authoritative timestamps; identifier-bearing usage records with quantity, unit, interval, and rate; a metadata convention for immutable ownership fields captured at machine creation; and an export or query API finance can join to its ledger.

Why can't I just use request timestamps for billing? A request timestamp is not usage. Provisioning is asynchronous, so a machine may become ready well after the request, and stop requests complete later than the moment they were issued. Use event timestamps like ready_at and stopped_at instead.

What fields should a per-second usage record contain? A usage_record_id, resource type, quantity, unit, interval start and end, rate, and the machine ID with the ownership snapshot captured at creation. The snapshot makes the record immutable and auditable.

How does Smol Machines support per-second metering? Every workload runs as a hardware-isolated microVM with explicit create and delete boundaries, sub-second cold starts under 200ms when pre-baked, and governed ownership metadata, so usage records are a byproduct of operations rather than a reconstruction from logs.

Conclusion

Per-second billing is not a billing problem. It is a runtime problem with a billing layer on top. Choose a platform whose lifecycle events, usage record schema, and ownership metadata you can audit end to end, then add the metering engine and finance exporter that fit your stack. If you are running agent workloads on isolated microVMs, Smol Machines gives you the runtime foundation, and the developer docs show you exactly what the platform exposes. Get the source events right, and the invoice takes care of itself.