Direct answer
Fixed fee, variable tool costs. Give the job its own budget, enforced where the calls run.
A fixed fee feels safe until your agent starts spending inside it. The fee was agreed once, in a quiet moment, as a single number. The tool costs arrive later, call by call, while the job runs: research calls, retries, a loop that looked productive at midnight. Each one is small. Together they come straight out of your margin, because the client is never going to ask what the job cost you to run. A general daily spending cap does not solve this, because a day is not a job: three jobs share the day, one job spans nine days, and the cap that protects your account says nothing about whether this job stayed inside its own economics. The fix is to budget the job itself. Put a tool budget line inside the fee before you start, set that budget as a cap on the connection the job runs through, let the cap stop the job with a receipt when it is hit, and treat that stop as a decision point you handle in writing, not a leak you absorb. Here is the whole method.
Updated November 7, 2026. First published November 7, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on November 7, 2026.
Step 1. See the fixed fee job for what it is: a budget with one line missing
Every fixed fee silently contains your time, your judgement, and now a third thing it did not used to contain: machine spend that varies with how the work goes. A job that runs clean might cost a little in tool calls. The same job with a stubborn source, a big document set, or an agent that retries generously can cost several times that, and the fee does not move. If you never wrote the tool budget down, the job has no defence: spend expands to whatever the work seems to need, discovered afterwards in a usage screen, when the only remaining move is to earn less. Writing the line down is the whole discipline. Before the job starts, estimate the call volume the stages imply, price it at the rates you actually pay, add a stated allowance for retries and dead ends, and hold that total as the job budget. It lives in your quote workings whether or not the client ever sees it, and it is the number the rest of this page enforces.
Step 2. Set the cap per job, on the connection the job runs through
A budget in a spreadsheet stops nothing. The cap has to sit where the calls run, so the job stops itself at the line instead of reporting past it. On Zambo, the spend tools do exactly this at connection level: you set a spending cap, you read the current spend state at any time, and both tools are free with no quota, so checking the budget never spends it. Run one job through its own capped setup, or reset the cap at each job boundary and note the starting state on the job record, so the spend figure belongs to this job and no other. Size the cap to the job budget from step 1, not to the fee: the fee includes your time and your profit, and a cap set at the fee would let the machine eat both before it stopped anything. Set the cap before the first real call, the way you would set a limit before handing over a card, because a cap set mid-job only governs the spend you have not already lost.
Step 3. Know what happens at the line: the job stops, and the stop itself is recorded
When spend reaches the cap, the next metered call is refused rather than run, and the refusal is itself a recorded event with its own verifiable receipt, so the moment the budget bit is a fact on the record and not a gap in it. The overnight runaway page in this hub carries a recorded refusal of exactly this kind, receipt 2f8bd3d1-8485-441d-8e4e-bad587b984d3, from a sequence where a zero cap was set deliberately to prove the stop works. Two properties matter for a fixed fee job. First, the stop is total and immediate: no slow bleed past the line while you are asleep, in a meeting, or on another client. Second, nothing is silently lost: the work up to the cap sits on the job record as completed steps, the refusal marks where it stopped, and the spend status reads back the job total so far. A stopped job is an annoyance. An unstopped job on a fixed fee is a loss, and it is the only one of the two you cannot renegotiate.
Step 4. Read the decision states the finished spend sits inside
Spend is only half the job record; the other half is whether the client accepted what the spend produced. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the decision states a delivery can sit in when the money conversation happens:
Accepted: the decision is on the record
- Status: accepted, decided_by client, decided_at 2026-10-16T14:31:51.146Z, release_hint ok_to_release.
- Steps: 4 steps total, 4 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Pending: checked, and still waiting on a decision
- Status: pending, release_hint hold.
- Steps: 5 steps total, 5 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
The accepted record, 4 steps, 4 checked, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release, is the clean fixed fee ending: the work is checked, the client has accepted it on the record, and the job spend, whatever it was, sits inside a fee that is now payable in full. The pending record, 5 steps, 5 checked, release_hint hold, is where budget discipline pays for itself a second time: while a decision waits, you can read the job exactly as it stands, steps checked, spend known, nothing still running up cost in the background. Compare the uncapped version of that wait, where the agent keeps polishing, rechecking, and spending against a fee that has not even been approved for release. The cap does not just protect the margin on the job. It freezes the economics of the job at the moment the work stops, which is the moment every later conversation is priced from.
Step 5. When the cap fires mid-job, treat it as a decision, never a dial
The cap will fire on some job, and that moment is a fork with three honest exits. Absorb it: the overrun is small, the cause was your own estimate, and you raise the cap by a named amount, note it on the job record, and fix the estimating miss on the next quote. Rescope: the work genuinely grew beyond the brief, so the remaining stages are repriced as a change before any more spend runs, with the refusal receipt and the spend status as the evidence that the original budget is spent. Or stop: the job cannot be finished inside any budget the fee supports, and you deliver what is done, on its record, and close the job in writing. The one move that is never on the list is raising the cap silently and carrying on. A silently raised cap converts a budgeting tool into a reporting tool, and you find out the job lost money at the end, again, with better charts. Every raise gets a number, a reason, and a line on the record, or it does not happen.
Step 6. Close the job with its spend on the record, and feed the number forward
At delivery, the job record should let you answer three questions in one reading: what was delivered, what state its acceptance is in, and what it cost in tool spend against the budget you set. Put the final spend figure in your own close-out note beside the budget line from step 1, whether or not the client ever sees it. Then feed the pair of numbers into the next fixed fee quote for similar work. Two or three closed jobs give you something most freelancers never have: an evidence-based tool budget per job type, instead of a hopeful allowance. Quotes get calmer, caps get set from data, and the fixed fee goes back to being the safe option it was supposed to be, because the one variable cost inside it is now the most tightly measured number in the job.
What a record does not settle
A spending cap controls calls that run through the capped connection. Work an agent runs through another account, another tool, or a client's own setup is outside the cap and outside the spend record, so the job budget only governs the work you actually route through it. A verifiable receipt proves the saved result was not changed since it was saved; the refusal receipt proves the stop was recorded, not that the budget you chose was the right size. Sizing the budget, pricing the fee, and deciding whether an overrun is yours or a rescope remain your commercial judgement. This page is general information, not financial or legal advice.
Frequently asked questions
My client's job has a fixed fee and my AI agent's tool costs come out of it. How do I stop the agent spending past the job's budget?
Give the job a budget of its own and enforce it where the calls run. First, write the tool budget line before the job starts: estimate the call volume the stages imply, price it at the rates you pay, add a stated allowance for retries, and hold that total as the job budget, separate from your time and profit inside the fee. Second, set that figure as a spending cap on the connection this job runs through, before the first real call, and read the spend status as the job proceeds. When spend reaches the cap, further metered calls are refused and the refusal is recorded with its own receipt, so the job stops at its line instead of bleeding past it. Third, treat every cap firing as a decision in writing: absorb a named amount for your own estimating miss, rescope if the brief grew, or stop and deliver what is done. Never raise the cap silently.
Is a per job cap different from a daily spending limit?
Yes, in the unit it protects. A daily limit protects your account across everything that runs that day, which mixes several jobs together and resets while a long job is still mid-flight. A per job cap protects the economics of one engagement: it is sized from that job's own budget line, it runs from the job's first call to its last, and the spend status at any moment reads as this job's cost against this job's budget. On a fixed fee that is the only figure that decides whether the job made money. The two work together without conflict: the daily limit is the outer fence for your whole practice, and the job cap is the inner fence that keeps one engagement from eating its own fee. Set both, and let the job cap be the smaller, more specific number.
What happens when the agent hits the cap in the middle of a task?
The call that would cross the cap is refused, and the refusal is recorded with its own verifiable receipt rather than failing silently. Work already completed stays on the job record as checked steps, and the spend status reads back exactly what the job has spent so far, so the state at the stop is fully known: what is done, what it cost, and where it stopped. Nothing keeps running in the background, which is the point on a fixed fee. What happens next is your decision, made with the record in front of you: absorb a named top-up if the miss was your estimate, rescope the remaining work as a priced change if the brief grew, or stop and deliver what exists. The agent does not get a vote, and the cap does not negotiate.
Should the client see what the job cost me in tool spend?
Usually the figure stays on your side of the record, and the client sees the delivery, its step record, and its acceptance state. Your tool spend is a cost of your production, like your software subscriptions, and a fixed fee means the client bought an outcome at a price, not a cost-plus breakdown. Two exceptions are worth handling openly. If an overrun was caused by the brief growing, the spend status and the refusal receipt are clean evidence for the rescope conversation, and showing them turns an argument about effort into a reading of a record. And if you quoted the job with a stated tool budget as part of the agreement, then the spend against it is a term of the deal and belongs in the close-out. Decide which kind of job it is before the work starts, and write that choice into your quote workings.
How do I set this up before the next fixed fee job?
Put the job on a capped connection from its first call, and let its delivery run on a record the client accepts stage by stage. When the work runs through Zambo, you set the job budget with the spend limit tools, both free with no quota, every call the agent makes lands as a step with a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and a call that would cross the cap is refused with that refusal receipted too. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, run the job's delivery day that way and watch the spend sit inside its line while the proof assembles itself: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.
Related
- I took over a client project from another freelancer and all I got was a pile of chat exports. How do I establish what is actually done?
- My client asked which parts of the delivery were done by AI and which parts I did myself. How do I answer with a record instead of a guess?
- How do I stop my AI agent from overspending?
- How do I split a big project into milestone payments so I do not get burned?
- Start with your problem: every problem in this directory, routed to its page