Agent costs follow the execution path, not the length of the request

The point made is that agent billing attaches not to the length of the request sentence but to the length of the actual execution path. Even a one-sentence request to add a single calendar event turns, behind the scenes, into checking existing appointments, reading the screen, entering data, confirming the save and retrying on failure; and because a whole new batch of information is fed in every time the screen changes, computer-use costs grow in proportion not to the number of clicks but to the amount of on-screen information and the number of decisions. The key to saving is not shortening prompts but tiered allocation, and the example given is a 3-tier setup that leaves routine execution and formatting to a low-cost model on a medium setting and moves only ambiguous items up to a high-performance model on high before bringing them back down. Calling sub-agents for a small task makes each of them read the same material, so the tokens spent splitting and merging are pure loss, and if you don't build a completion condition into the request, a 45-minute demo can balloon to 8 hours and burn through half of the weekly usage. Also cited is an evaluation record in which swapping only the harness, under the same settings, raised the score and cut the cost to less than half.

This is a note: my own write-up after reading several sources. It has no source link; events checked against a source are kept as records.