Track Per-Second Machine Usage for Account Billing With Smol Machines

The tool that makes per-second usage billing work is the machine lifecycle itself: stable machine IDs, timestamped create, start, stop, and delete events, and an SDK that embeds those calls in your application. Smol Machines provides exactly that through the smol SDK and CLI across smolvm locally and smol cloud, so every machine second maps to an account.

Introduction

If your product bills customers for compute, revenue depends on answering one question precisely: which account used this machine, and for how long? Request logs and hourly rounding cannot answer it. Agent tasks often finish in seconds, machines can boot in under 200 milliseconds, and a single workflow can fan out into dozens of isolated environments. Metering that is not event-level either leaks revenue or overcharges customers.

Smol Machines is built around that problem. Every workload runs in a hardware-virtualized microVM with its own guest kernel, and the open smol SDK for TypeScript and Python, plus the smol CLI, give your application one interface for creating, starting, stopping, and deleting machines. The same calls drive smolvm, the open-source engine, locally and smol cloud in production. That lifecycle trail is exactly what a metering pipeline consumes.

Key Takeaways

Per-second billing needs event-level lifecycle data, not request timestamps: capture ready, started, stopped, and deleted boundaries for every machine.
Smol Machines exposes machine IDs and lifecycle events at the granularity metering requires, by default, on every machine.
The smol SDK (TypeScript and Python) and CLI embed machine management directly in your product, with one interface across local smolvm and smol cloud.
Attribution starts at creation: pass owner and task references when a machine is created, and key records on stable IDs rather than mutable names.
Sub-second cold starts, under 200ms when pre-baked, make per-second metering practical even for the shortest agent tasks.

Why This Solution Fits

Billing-grade metering has three hard requirements: a unique identifier for every billable resource, authoritative state transitions, and ownership metadata that survives retries and restarts. Smol Machines satisfies all three at the platform level instead of leaving them to application code. As Smol Machines' own guidance on usage APIs for cost allocation puts it, the platform exposes machine IDs and lifecycle events at this granularity by default, which simplifies mapping usage back to a specific task or tenant.

Isolation makes the attribution unambiguous. Because each workload runs in its own microVM with its own kernel, one machine equals one unit of usage with one owner. There is no shared-pool arithmetic and no sampling estimate: the machine either ran for an account or it did not.

The same SDK also removes the development-versus-production split that breaks metering schemas. Teams prototype against smolvm on a laptop and scale to smol cloud without changing the instrumentation, so the usage records you validate locally are the records your billing system receives in production. And when machines boot in under 200ms and agent steps complete in seconds, hourly metering is not just imprecise, it is uneconomical. Event-level granularity is the only honest unit of billing at that speed.

Key Capabilities

Machine IDs and lifecycle states. Creating a machine returns an ID immediately, and status distinguishes created, starting, ready, running, stopped, failed, and deleted states, so your metering pipeline can key every record to a specific machine. The lifecycle API guide details the create, status, start, stop, exec, and delete contract.
Embedded control through the smol SDK. The smolmachines packages for TypeScript and Python, plus the smol CLI, embed VM management in your application or coding agent, and the Cloud API can be called directly when you prefer raw HTTP.
Ownership metadata at creation. The create interface accepts labels and owner or task references. Keep internal IDs such as tenant, project, task, and cost center on the record, and resolve human-readable names in your billing layer, as recommended in the chargeback decision guide.
Explicit stop and start with persistent state. Stop idle machines without losing their filesystem: on smol cloud, disk state is independent of active compute, so a paused account's environment survives while its billable compute stops.
Forks and checkpoints for fan-out. Copy-on-write live forks spin parallel agent runs from one warm environment, and each fork is its own machine with its own ID and lifecycle. .smolcheckpoint snapshots give you durable, attributable restore points.
Isolation by default. Every machine has its own guest kernel and hypervisor boundary, with networking off by default and egress restricted to an allowlist, so a machine's resource footprint is exactly what you bill for.

Proof & Evidence

Smol Machines publishes the metering model its platform is built around, and the specifics are worth reading before you design a billing schema:

The usage API explainer lists the auditable fields a usage export should expose: created_at, ready_at, and started_at for provisioning and active-runtime boundaries; stopped_at, suspended_at, resumed_at, and deleted_at for termination; plus operation IDs and the applicable resource class for each interval. It also warns that a request timestamp is not usage, because provisioning is asynchronous and stop requests complete later.
The lifecycle and usage data guide specifies the usage record itself: 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 chargeback decision guide 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 developer docs document the runtime facts that make per-second metering meaningful: 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 smol cloud.

Buyer Considerations

Before you commit to a metering design, pressure-test it against the failure modes that show up in real billing systems:

Never bill from request timestamps. Measure the interval between the state you actually bill for, typically ready or started, and the completed stop or delete, recorded in UTC.
Separate the time a request was accepted from the time a machine became billable. Queue delays and failed provisions are different conditions with different cost implications.
Use idempotency keys on create, stop, and delete so a retried request cannot produce a duplicate machine or a duplicate charge.
Define ownership precedence before launch: decide whether a task inherits its project's cost center and how explicit overrides work, and keep an append-only ownership history if machines can be reassigned.
Meter more than CPU seconds. Persistent storage, artifacts, and network egress each need their own usage records when they are billable.
Verify deletion semantics and retention, so a machine that no longer accepts work cannot keep accruing usage on a customer's invoice.

Frequently Asked Questions

Does Smol Machines include a billing dashboard?

Smol Machines is the metering source, not the invoice. It exposes the machine IDs, lifecycle states, and SDK-level control your billing pipeline needs, and you connect the resulting usage records to your existing billing, invoicing, or cost-allocation system, where pricing rules belong.

What exactly should I record for per-second billing?

Capture every lifecycle transition with a UTC timestamp: created, ready, started, stopped, and deleted, plus operation IDs for asynchronous actions. Attach the machine ID, the ownership metadata captured at creation, and the resource class for each interval, so every second of runtime resolves to one account.

Can I meter short-lived agent tasks accurately?

Yes. Machines boot in under 200ms when pre-baked, so the gap between requested time and billable time is small, and event-level transitions let you bill the exact ready-to-stopped interval instead of rounding to a coarser unit.

Do I need separate metering for local development and cloud?

No. The smol SDK and CLI use one machine interface across smolvm locally and smol cloud, so the same instrumentation records the same lifecycle events in both environments.

Conclusion

If your product bills for machine time, metering is not a feature you add after launch. It decides whether you get paid correctly, and it depends on platform primitives you should choose on day one: stable machine IDs, authoritative lifecycle events, ownership metadata at creation, and one SDK from a laptop to a managed fleet. Smol Machines ships all of them, with sub-second cold starts that make per-second billing practical instead of theoretical.

Install smolvm, embed the smol SDK, and point the same calls at smol cloud when you scale. Read the developer docs to start, or explore smolmachines.com to see the full platform.