Handling the Abort Flag
The operator's cost and time limits on a workflow are enforced through a simple, elegant mechanism: every time your workflow logs a step, the platform tells it how much it has spent so far — and whether it's time to stop. That signal is the abort flag.
The log response
Whenever a Circus node calls the platform's log endpoint — which the Agent and Log nodes do on every step — the response carries the run's running tally:
{
"max_time": 300,
"time_consumed": 47,
"max_cost": 5.00,
"cost_consumed": 0.2156,
"abort": false
}
max_time/time_consumed— the workflow's time limit and how many seconds have elapsed.max_cost/cost_consumed— the cost limit and how much has been spent (the platform computed this from your reported consumption).abort— the whole point:truewhen either limit has been reached.
Note the boundary is inclusive — reaching a limit exactly trips the flag (the check is "at or over," not "strictly over").
What the nodes do with it
You don't have to inspect this yourself. The Agent and Log nodes check abort automatically after each log call. If it's true, the node terminates the run — it tells the platform to mark the execution terminated and stops the workflow — with the reason that a cost or time threshold was exceeded. This is layer one of enforcement: the workflow stopping itself, promptly, the moment it goes over budget.
Why it isn't the only layer
Self-termination is prompt but not guaranteed — a workflow might fail to check the flag, or the terminate call might not land. So the platform doesn't rely on your workflow cooperating: a background reconciler independently watches running executions and remotely stops any that have breached their limits. Enforcement holds even if a node's self-termination misfires.
The practical upshot for you is reassuring: place your Agent and Log nodes, and the limits enforce themselves. You get prompt self-termination for free, with a platform-side backstop behind it — no manual budget-tracking logic in your workflow at all.