What it costs and what you see

What the service runs on

Costs: what can be capped

The real risk of an autonomously working system is not the single expensive run, but continuous operation that goes unnoticed. That is why a set cap measures the month rather than the single run — and the check happens before the next one starts.

Three levels, configurable

One cap for the organisation, one per project, one per run: each can be set, and of the three levels the tightest one stops the run. Without a set amount none applies — the default is unlimited.

Before the start: the month’s bill

Before a run begins, the service adds up what the organisation and the project have already cost in the current month; if that lies above the set cap, no further run starts. The run that breaches the cap itself is halted along the way: the work packages not yet begun are blocked, the running ones may finish.

Volume limits, also configurable

Independently of the money amount, quotas can be set per plan tier: how many runs an organisation may start per month and how many of them may run at the same time. Unset here, too, means unlimited.

Local models can be priced

For locally operated models a price per unit of compute time can be configured; their runtime then flows into the bill. Without that setting they run at cost zero — the saving would otherwise just be a gap in the bill.

Visibility: metrics and tracing

In the hosted service, Anvil Coder exposes its metrics in the usual format; Prometheus and Grafana are the intended chain. Self-hosters enable the metrics endpoint for it. If tracing is switched on, it reaches across the queue — a job remains one coherent operation from the coordinator into the worker, even though a message sits in between.

The export of the tracing is (optional) and off by default; in the hosted service it is switched on. Self-hosters who only need metrics pay nothing for it.

Self-monitoring: optional

Two components are (optional): they only come along if someone rolls them out — in the hosted service both are rolled out. A monitor observes the running operation and compiles findings. And a recurring check run, likewise (optional), establishes whether the chain as a whole still holds, instead of relying on the absence of alarms: a hermetic test run in the same namespace, on its own channels and without a model. It needs no project of its own, because it works without a model.

With the monitor, it pays to look closely at which hand is armed how sharply. Once it is rolled out, the restart intervention is armed without any further setting; the further-going automatic repair is separately (optional) and off by default as delivered — in the hosted service it, too, is switched on. The cockpit view of it is reserved for the operations role: self-hosters have the switches in their hands; those who rent the service get the result, not the switch.

Both are meant as a complement, not as a replacement for an operations team. A system that monitors itself still needs someone who reads the findings.

Idle: the fleet scales to zero

In the hosted service, the worker fleet scales down to zero when there is nothing to do. The trigger is the backlog in the queue: when work is waiting, the workers come back.

The base load remains untouched by this — coordinator, databases, message bus, login and monitoring keep running. Idle is therefore cheaper than operation, but not free.