A Neander program is guaranteed to stop, as we saw last time. But "stops eventually" is not good enough in a real-world scenario, where the program runs inside the host application and consumes its resources while it does.
So on top of a sub-Turing language, Neander features a budget system which places hard upper bounds on a program in six different dimensions. Three of them are budgets in the literal sense: they bound what a running program is allowed to consume. The other three are static caps on the shape of the program itself, checked before it is allowed to run at all. All six are set and enforced by the runtime, never declared, requested or negotiated by an agent or a program. The agent can obtain the current budget limits from the runtime by submitting the empty program (what it would do anyway during a cold start). The meta block of the Reference Response contains the runtime's budget configuration.
It is worth stressing that the budget system is an integral part of the language definition, not merely a bolted-on feature of one particular runtime implementation.
What is runtime-specific are the details of how and in what amount these upper bounds are assigned to a submitted program. The Grotto reference implementation, for example, currently requires a static budget configuration at startup time and applies it to every program submission.
