The Operating Boundary: Cost, Reuse, and Deployment Choices
AutoGPT's graph and runtime become consequential when an agent runs repeatedly, touches external providers, or is shared beyond its creator. This chapter focuses on the operating boundary around that workflow: how cost is measured, what kinds of reuse are being shared, and what changes when the same platform is managed in the cloud, self-hosted across services, or placed in an experimental appliance. The goal is not to name one universal best option, but to match control and responsibility to the work the agent must perform.
A run has more than one price
The Platform uses automation credits to meter agent execution. Credits are charged when blocks run, but “a block run” is not one uniform unit of work. Some blocks have a fixed charge. Others vary with tokens, provider dollars, elapsed seconds, data size, or the number of items returned. An agent that looks like one prompt to its user may contain several model calls, a list expansion, a sandbox session, or a provider action whose cost is only known after the external service responds.
The implementation reflects that difference. A fixed per-run or per-byte cost can be charged before the block executes. Dynamic costs can use a pre-flight estimate and then reconcile against post-flight statistics. Token-based LLM work can use captured input, output, and cache counts; provider-cost paths can use the dollar amount reported by the provider; time- or item-based paths can use the block's recorded duration or result count. The final charge can therefore differ from the estimate.
That behavior is economically sensible but operationally important. An estimate is a control signal for deciding whether a task may start, not necessarily the final bill. If the block consumes more real provider work than its estimate assumed, reconciliation can add a charge after the block has already run. If it consumes less, an overcharge can be refunded. The code deliberately records a positive shortfall even when the balance becomes negative after the provider has been paid; otherwise the platform would hide a real cost rather than record it as debt.
The unit of design is consequently the whole execution path. A model choice affects token or provider cost. An orchestrator's iterations affect the number of model and tool calls. A list iterator affects how many downstream actions are invoked. A retry may create another invocation and should be treated as potentially billable. A sandbox's duration matters even when the visible result is a short sentence. A reader who budgets only for the first prompt will miss the work created by the graph around it.
The Platform also distinguishes its managed credit wallet from the external provider's own billing. A user may supply an API key and pay that provider directly while still incurring AutoGPT credits for the block or platform execution. The checked-in model catalog supplies model metadata and cost rules for supported LLM paths, but catalog entries and hosted plan details can change. The right practice is to use the estimate and current billing surface for a real decision, while treating the repository's cost mechanism as the explanation of how metering works rather than as a permanent price sheet.
A direct block execution can have a different accounting path from a graph run. The implementation avoids locking in a historical estimate for dynamic-cost direct calls when no executor reconciliation will follow.