Alpha Batcher

Picture a bug fix that changes 12 lines. The agent reads the project, writes a plan, starts a helper, runs tests, reads the failures, and tries again before producing that patch.
The bill includes every request that got it there.
That makes a short task surprisingly easy to overpay for. A long conversation can carry old files into later requests. A tool can return pages of data when the next decision needs one record. Several agents can repeat the same investigation.
You can find these costs in the execution history. Start with one job, track everything it spends, and check whether the result actually passes. Then change the part doing unnecessary work.
1. Put a price on a finished task
Choose a task you repeat: fixing a reported bug, preparing a research brief, or checking a batch of customer records. Define what counts as finished before running it.
For a bug fix, acceptance might require a test that reproduces the original failure, a passing result after the change, and no failure in the affected integration tests. A message saying the bug is fixed doesn't meet those conditions.
Give the task an ID. Keep that ID across retries, helper agents, verification, and the final result. Record a separate request ID for each model call so you can catch duplicates in your logs.
The core calculation is:
Cost per accepted task = total recorded spend / number of accepted tasks
Include the attempts that failed. If 10 tasks cost $8 in total and only 4 pass, the cost is $2 per accepted task. Keep the 40% acceptance rate beside that number. If nothing passes, report the spend and zero accepted tasks; the ratio is undefined.
Track human repair time separately. A workflow that saves $1 in API charges and requires 20 minutes of cleanup has a tradeoff worth seeing.
For API work, save the provider's usage response, model ID, pricing date, tool charges, task outcome, and timestamps. If usage is missing after a timeout, mark the cost unknown and reconcile it with provider records. A missing response doesn't establish that the request was free. If any request remains unpriced, label the batch total incomplete.
Claude Code users can start with /usage and /context. The first helps inspect usage; the second shows what occupies the conversation. On a subscription, a local dollar estimate isn't a separate invoice, and the context window is a different limit from your plan allowance.
2. Find the context that keeps coming back
Your latest message is only part of a model request. In Claude Code, requests can also contain project instructions, tool descriptions, conversation history, file contents, and earlier tool results.
Suppose an unchanged 12,000-token document appears in 8 requests. Across those calls, the document contributes 96,000 input tokens. Eligible cache reads may be charged at a lower rate. The document may still be irrelevant to some of those decisions.
Look at a single task's sequence. Which files were read? Which outputs stayed in the conversation? Which request caused the largest increase? Was the agent still using those details at the end?
For a bug in an invoice total, start with the failing input, the calculation, its callers, and the tests covering it. Let the agent follow references when it needs more. Loading an entire repository in advance can make every later turn carry material that never contributed to the fix.
Keep the full evidence available on disk. Return a concise result with the file path and enough detail to inspect the original. For a test run, that means the command, exit code, failing test names, relevant error, and log location.
A summary that drops the only clue creates more work. Preserve the exact error, affected identifier, and evidence needed for the next action.
3. Check whether the cache is doing useful work
Prompt caching reuses an eligible, matching beginning of a request. Put stable instructions first and changing task data afterward.
In a custom Claude API workflow, a timestamp before the cache boundary can create a different entry on every call. Place the boundary after content that repeats. Check the current caching documentation for your model and request structure.
Compare cache reads and writes across requests. Repeated writes with few reads suggest checking prefix changes, minimum eligible length, lifetime, and timing.
Cache reads still cost money. High read counts can mean caching works; also check whether that context helps finish the task.
In Claude Code, ordinary subagents have their own context and caching behavior. A fork behaves differently. Compaction also uses a model request and rebuilds conversation context. Avoid scheduling manual compaction every few minutes without measuring the result.
4. Shrink what tools return
A tool response can become input to subsequent model calls. A large response may therefore affect more than the request that originally fetched it.
Take a daily order report. A tool fetches all orders, the model reads every row, and another request asks it to calculate totals. A script can filter the records, calculate the totals, and return the exceptions requiring judgment.
That changes what reaches the model. It also creates a calculation you can test independently.
Use the same approach for logs, spreadsheets, and search results. Filter by the relevant customer, date, error, or record type before returning data. Include the filter used, the count processed, any truncation, and a path or identifier for the original evidence.
Check pagination. Processing the first page and presenting it as the whole dataset gives you a cheaper wrong answer.
Intermediate results can stay in the execution environment while selected data reaches the model. You can apply that principle in a small local script without building a complicated agent system.
Tool definitions also occupy context when loaded. Some clients already defer full definitions until needed. Inspect your actual setup before removing integrations: connection count alone doesn't tell you their token overhead.
5. Save the procedure after you've figured it out
Watch for tasks where the agent repeatedly discovers the same commands, rewrites the same plan, or decides which tests to run from scratch.
Once the procedure is understood, save it. Put project-specific instructions in a short reusable guide. Put fixed calculations, file transformations, and command sequences in a tested script.
For the invoice bug, a script can prepare a fixture, execute the calculation, compare the expected value, and report the result. The agent still needs to diagnose an unexpected mismatch and choose a correct fix. It doesn't need to invent the test command every time.
Keep the procedure tied to its assumptions. Record the required dependencies, expected inputs, and conditions under which it must stop. When the environment changes, a visible failure is easier to diagnose than a plausible success message.
Repeated status checks deserve the same treatment. If a service provides a job ID, use its completion event or a bounded polling function. Return to the model when the job finishes, fails, or exceeds its deadline.
For actions that create or send something, a retry needs extra care. Check whether the first attempt succeeded before repeating it. Reusing an idempotency key, where supported, can prevent one uncertain response from becoming two orders or two messages.
6. Give each agent a distinct job
Parallel agents can reduce elapsed time. Their calls, context, and coordination also contribute to the total spend.
Split work when the assignments are independent and the outputs are easy to combine. One agent can reproduce a reported bug while another checks the affected interface contract. Give each a clear question and a defined result.
Avoid sending several helpers the same broad instruction to inspect everything. That can produce several copies of the same investigation, followed by another pass to reconcile their summaries.
A useful handoff names the task, relevant files, allowed changes, expected output, and stopping condition. Ask for evidence paths and the findings needed by the next step. Keep verbose intermediate work available in the helper's files.
Assign verification deliberately. Run focused checks during implementation, then run the required broader checks against the combined result. Repeat a check when code changed, an earlier run failed, or new evidence creates a reason. Record why each run happened.
Measure model changes separately from workflow changes. Keep the same task set and acceptance tests when trying a different model or reasoning setting. Include retries and repair time in the comparison. A lower price per call only helps if the entire job remains worthwhile.
7. Read the usage fields correctly
Different providers report cached input differently. Copying one provider's formula into another provider's logs can produce a convincing but incorrect bill.
In a standard Claude Messages response, input_tokens, cache_creation_input_tokens, and cache_read_input_tokens are separate input categories. Cache creation can also be split by lifetime. Match each category to its rate.
In the current OpenAI Responses schema, cached input and applicable cache-write counts sit inside total input. They need the documented subtraction before pricing ordinary input. Use the provider's calculation for the actual model and API you're calling.
Keep the original usage response beside your normalized record. That lets you correct the calculation when your provider, model, or pricing changes.
Some features also create extra billed work. With Claude API compaction, top-level input and output counts exclude the compaction iteration. Price the entries in usage.iterations once, using each entry's usage fields. Don't add the top-level counts again.
Tool execution, search, hosting, and storage can have separate charges. Label a number as model cost if those charges are excluded. For streamed requests, use the completed usage totals when available and avoid counting cumulative updates repeatedly.
8. Work through one batch
Here is an illustrative calculation you can reproduce. The request counts, token volumes, tool fees, and outcomes below are invented. No agent was run to produce them.
The example job extracts three values and their supporting passages from each of four documents. A result passes only when its JSON, values, and source evidence are correct.
Both scenarios stipulate three accepted results, one rejected attempt that needs a retry, and one task that ultimately fails. That's five attempts across four tasks. Every attempt contributes to the bill.
The first scenario contains 15 model requests: 375,000 uncached input tokens and 15,000 output tokens. At the standard Claude Haiku 4.5 prices checked on September 7, 2026, input costs $1 per million tokens and output costs $5 per million. The model charge is $0.45. Add $0.06 in invented external tool fees, and the total is $0.51.
Divide $0.51 by the three accepted results: $0.17 per accepted result.
The second scenario stipulates 10 requests with less fresh input and some cached input. Its model charges break down as follows:
• 55,000 uncached input tokens at $1 per million: $0.055.
• 25,000 five-minute cache-write tokens at $1.25 per million: $0.03125.
• 25,000 one-hour cache-write tokens at $2 per million: $0.05.
• 50,000 cache-read tokens at $0.10 per million: $0.005.
• 7,500 output tokens at $5 per million: $0.0375.
That totals $0.17875 in model charges. Add $0.05 in invented external tool fees: $0.22875 for all attempts, or $0.07625 per accepted result. The mixed cache lifetimes demonstrate the accounting categories; they aren't a recommended setup.
These numbers show what the stated usage costs. They don't establish that filtering context or changing a cache boundary will produce those counts or preserve quality. A real comparison needs recorded requests and independently checked results. Its failed tasks still belong in the total.
9. Run this on your own workflow
Choose a small set of representative tasks and keep their inputs unchanged. Include an ordinary success, a difficult case, and a task that has failed before. Write the acceptance checks before making changes.
Run the existing workflow and save its request records. Mark the point where unnecessary material entered the conversation, a procedure was rebuilt, a duplicate check ran, or an unchanged error triggered another attempt.
Change one mechanism. Filter a large tool result. Save a repeated command sequence. Fix a cache boundary. Narrow one helper's assignment. Keep the model and acceptance criteria unchanged for that comparison.
Rerun the same inputs in a clean test environment. Distinguish initial runs from cache-warmed runs. Repeat enough times to see whether the outcome is consistent, and preserve failed attempts in the totals.
Use this prompt with a coding agent that can access your implementation and logs:
Inspect this workflow and its available execution logs.
Define the task boundary and acceptance checks. Trace the parent calls, helper calls, retries, verification, and final outcome.
Create a local report showing recorded model cost, separate tool charges, missing usage, accepted tasks, failed tasks, elapsed time, and human interventions. Use current provider-specific usage fields and a dated rate card. Preserve raw usage responses. Deduplicate request IDs.
Identify the largest avoidable cost supported by the logs. Point to the specific calls and explain why the work was unnecessary. Keep estimates separate from recorded amounts.
Propose one change and a comparison using the same inputs, model, and acceptance checks. Separate initial and cache-warmed runs. Stop if the required evidence is missing and name exactly what's needed.
Do not make paid API calls or change the live workflow during this inspection. Save the report and proposed patch for review.
The acceptance checks are what keep the comparison honest. If filtering a log hides the failure, or a smaller model needs repeated repairs, record that result and revise the change.
I write practical AI workflows here. Follow me for the next one.

7-oktabr kuni Ilon Mask Grok Bot “har qanday vazifa uchun eng yaxshi backend modelidan, jumladan Claude Opus 5.5’dan” foydalanishini yozdi. 79 million marta ko‘rildi.
Bir hafta o‘tgach, mahsulotga qiziqmasligini aytgan NetworkChuck bu borada adashganini yozdi: bir haftadan beri elektron pochtasi, taqvimi va maxsus ilovalari ulangan — hammasi shunchaki ishlayapti.
O‘sha ikki post orasida Grok Bot o‘z elektron pochta manziliga, X’ning barcha bo‘limlariga faqat o‘qish huquqiga, Shopify ulanishiga, to‘lov vositasi sifatida X Money’ga va 30 dollarlik boshlang‘ich tarifga ega bo‘ldi. Bularning ayrimlari hujjatlarda bor. Ayrimlari esa faqat Maskning postlarida tilga olingan.