Ask an agent to check a stock quote against the position already held in an account. Getting to a short answer can take several model requests as the agent chooses tools, reads their results, and decides what comes next. Each time the client resends the conversation, the tool definitions and earlier results go with it.
A smaller tool catalog trims the context sent at the start. If the model then needs an extra round to finish the job, it can give some of those savings back. Repeat the check throughout the day and the design of those requests becomes part of the operating budget, even when the position stays unchanged.
Inference optimization begins with deciding how much work to send through the model. Give it the tools and evidence the task needs, reuse eligible context, and remove rounds that add no useful work. Alpaca’s Command Line Interface (CLI) and Trading MCP Server offer different ways to arrange that work.
Following a decision cycle through a cost model lets us see where the tokens accumulate and which changes a developer can try. Actual costs and results will vary based on the model, usage patterns, pricing, configuration, and other factors.
The examples below use earlier model versions. As models and tooling evolve, the same framework can be revisited with updated pricing, cache policies, and fresh measurements of the same task.
Key Takeaways
- Count the whole decision cycle. Tool definitions, returned data, and the model’s output can all add cost as a task moves through several requests.
- A smaller catalog can still lead to a more expensive sequence. In the stated scenario, scoped MCP costs $0.0388 per decision versus $0.0391 for thin CLI because it uses one fewer sequential tool round.
- Treat the figures as projections. The three primary configurations model roughly $8 to $10 per day at 200 decision cycles. The $215 boundary case combines a broader catalog, disabled caching, and a longer loop.
- Keep cost savings tied to a complete answer. Scope tools, reuse eligible context, and remove unnecessary rounds while preserving the observations, uncertainty, and controls the task needs.
What a Decision Cycle Carries
A decision cycle covers the whole job, from the initial question to the agent’s response or authorized action. For our account check, that means counting the work needed to retrieve and interpret the quote and position together. A cycle may include:
- Receiving a market question or instruction.
- Reading the available tools and their schemas.
- Requesting market or account data.
- Interpreting returned data.
- Deciding whether another step is needed.
- Producing a response, record, or user-authorized action.
As the work moves through those steps, the bill grows in three ways:
- Prefix cost: instructions, tool definitions, schemas, and other context the model must process before it begins work.
- Tool-result tail: data returned from each tool call, together with intermediate assistant output, that accumulates across later turns.
- Output cost: the model’s own reasoning, structured responses, and final output.
Keeping the three parts separate lets us see where a change saves tokens or adds them:
Inference cost = prefix cost + tool-result tail + output cost
A quote fetched once can pass through the model several times. If the client resends the full conversation, the quote travels into the position check and any requests that follow. Take a sequence of five tool calls, with a model turn after each result. Including the initial request, that makes six model turns.
The first result appears in five later prompts, the second in four, and so on. Summarizing, pruning, or selectively retrieving earlier results changes how much of that history comes back.
By the end of those five calls, the accumulated results have appeared in later requests fifteen times:
1 + 2 + 3 + 4 + 5 = 15 result reads
Caching changes the price of that repetition. In the default Sonnet 5 scenario, a warm, eligible prefix costs one tenth as much to read as ordinary input. A cold eligible prefix uses the five-minute cache-write rate. We assume a 95% chance that a cache-enabled prefix is warm when a decision begins, then check eligibility as the conversation grows. Cached content still occupies context. What you pay for it depends on provider pricing, prompt stability, routing, concurrency, and timing.
We measured the difference in a five-pair Sonnet 5 experiment. With captured Alpaca tool definitions, canned responses, and a prescribed request sequence, the median serialized prefix was 14,602 tokens.
At the dated rates, writing that prefix to the five-minute cache cost about $0.0365, while reading it from cache cost about $0.0029. The roughly $0.0336 difference applies to that prefix’s billing category. Output varied between runs, so the difference in whole-loop bills also includes other changes.
The experiment did not measure how often a cache would be warm in everyday use. The scenarios below assume 95% initial warmth and use estimated context sizes, including an 11,890-token scoped prefix.
The host also determines how much tool information reaches the model. Anthropic’s advanced tool-use guidance describes a case where definitions alone consumed 134,000 tokens and recommends loading tools as needed. Inspect the actual requests in your own workflow before treating a server’s entire catalog as billed context.
How the Configurations Compare
We model the account check in three configurations: thin CLI, scoped MCP, and a full MCP surface.
- Thin CLI uses three sequential tool rounds.
- Scoped and full MCP use two.
- A fourth configuration carries the full CLI reference in context and also uses two rounds.
- The boundary case uses five rounds, a much broader catalog, and no caching.
These are workload assumptions, so the comparison shows how context and round count interact rather than ranking the interfaces in a controlled experiment.
| Modeled configuration | Prefix | Tool-result tail | Output | Modeled cost / decision |
|---|---|---|---|---|
| Thin CLI | ~$0.0011 | ~$0.022 | $0.016 | $0.0391 |
| Scoped MCP | ~$0.0085 | $0.014 | $0.016 | $0.0388 |
| CLI, full reference in context | ~$0.0106 | $0.014 | $0.016 | $0.0409 |
| Full MCP tool surface | ~$0.018 | $0.014 | $0.016 | $0.0484 |
| Boundary case | ~$0.924 | $0.130 | $0.020 | $1.0740 |
The table shows modeled estimates, rounded for readability. Totals use the unrounded request ledger, including cold cache writes and replayed intermediate output. They are projections rather than customer bills.
All three primary configurations remain fairly close in total cost, but look at thin CLI and scoped MCP. The CLI starts with far less context, yet scoped MCP comes out slightly cheaper under the stated modeling assumptions.
The extra round explains why. We give thin CLI three sequential tool rounds and scoped MCP two. Scoped MCP carries definitions for a task-specific subset of the catalog, but avoids a round of replaying and interpreting results. Full MCP adds more definitions and schemas while keeping the same two-round sequence, bringing its modelled total to $0.0484 per decision.
Now let several costs rise together: carry a much broader catalog, disable caching, and extend the loop. The boundary case reaches $1.0740 per decision under those combined assumptions. Because the inputs change together, the total shows their compounded effect. Estimating a particular MCP workflow still requires its own context size, cache behavior, tool-result volume, and loop length.
Before trimming a catalog, inspect the rest of the sequence. A settled CLI command can keep the starting context small, while scoped MCP can carry more definitions and still cost less if it saves a round. A broad catalog left in context adds expense under the model’s billing assumptions. Choose the change that removes work from the task you actually run.
The estimated starting contexts are about 1,200 tokens for thin CLI, 11,900 for scoped MCP, and 25,400 for the full MCP catalog. The Calculation Reference gives the precise inputs for each row.
How We Calculate Each Scenario
To put a price on the sequence, we follow the context through every model request. Each scenario starts with a stable prefix, a number of sequential tool rounds, expected tool-result and output volumes, and an initial cache state. The ledger then accounts for results and assistant output as they return in later requests.
When a prefix first meets the provider’s caching threshold, the ledger applies the cache-write rate. Later requests can read that prefix at the cache-read rate while newly reusable context may incur its own write. Intermediate assistant output can also return as input on a later request. The final response is billed as output and ends the ledger. We apply the same accounting method to all five scenarios using the dated rate and cache-policy snapshot.
The Calculation Reference provides the complete scenario inputs, request ledger, and boundaries of the separate provider-usage experiment. Keeping those records together makes it possible to change one assumption and follow its effect through the bill.
Put the Cost in Context
The ledger puts a dollar price on the completed check. Expressing the same cost in basis points of the position being reviewed lets us compare its scale at different notionals. This comparison is solely a mathematical illustration of inference expenses relative to assessed notional and should not be interpreted as a measure of investment performance or returns.
Where:
- S = notional assessed in one completed check
- b = inference cost per check, in basis points of S
- C = modeled inference cost per decision cycle
Express the cost relative to assessed notional:
b = (C / S) × 10,000
For illustrative purposes, a hypothetical break-even calculation for inference expenses alone would be:
Required benefit per completed task ≥ C
This calculation excludes other operational expenses, transaction costs, market risks, and potential trading losses. It does not assume that the workflow produces any financial or investment benefit.
With $5,000 assessed in one check, scoped MCP’s modeled cost of about $0.0388 is roughly 0.0775 basis points of that notional. Reviewing a $50,000 position at the same dollar cost reduces the proportion to about 0.0078 basis points.
The boundary case costs $1.074 per check, equivalent to 2.148 basis points of $5,000 or 0.2148 basis points of $50,000. Deciding whether either workflow earns back its cost takes a different kind of evidence: which decisions improve, over what period, and on how much capital. Repeated checks of a position still share that capital and its returns.
Budget for Repeated Checks
For the operating-budget comparison, hold the following inputs constant across the five modeled configurations:
- Assumed notional evaluated per decision: $5,000
- Budget year: 252 operating days
- Agent decision cycles: 200 per day
At 200 checks a day, the scoped scenario costs $7.75 per day under the stated assumptions. Each check spends inference budget, even when the decision is to keep the position unchanged. The table counts that workload and expresses the per-check cost at a common $5,000 scale. Trade count, turnover, and return attribution remain outside the model. These decision cycles represent modeled analytical checks and should not be interpreted as actual trades or recommended trading frequency.
| Modeled configuration | Modeled cost / decision | Modeled inference cost / day (200 decisions) | Cost per check / $5,000 assessed (bp) |
|---|---|---|---|
| CLI, thin context + runtime lookup | $0.0391 | $7.83 | 0.0783 |
| Scoped MCP | $0.0388 | $7.75 | 0.0775 |
| CLI, full reference in context | $0.0409 | $8.17 | 0.0817 |
| Full MCP tool surface | $0.0484 | $9.68 | 0.0968 |
| Unscoped boundary stress case | $1.0740 | $214.80 | 2.1480 |
Note. Costs use the unrounded request ledger. The basis-point column expresses operating cost relative to assessed notional, without estimating strategy returns. All figures are illustrative projections, not actual customer charges or guaranteed costs. The examples exclude brokerage fees, market data costs, transaction costs, and other potential expenses.
Pricing Sensitivity Across Models
So far, the calculations have used Claude Sonnet 5 rates. To examine the effect of pricing, we apply the same five scenario ledgers to API rates and cache policies from Anthropic and OpenAI, obtained in August 2026. Each figure below is the modeled cost of one agent decision cycle in US dollars.
| Modeled configuration | Sonnet 5 | Opus 5 | Haiku 4.5 | GPT-5.6 Terra |
|---|---|---|---|---|
| Thin CLI | $0.0391 | $0.0978 | $0.0220 | $0.0423 |
| Scoped MCP | $0.0388 | $0.0969 | $0.0194 | $0.0420 |
| CLI, full reference in context | $0.0409 | $0.1022 | $0.0204 | $0.0441 |
| Full MCP tool surface | $0.0484 | $0.1210 | $0.0242 | $0.0516 |
| Boundary case | $1.0740 | $2.6850 | $0.5370 | $1.0780 |
| Maximum/minimum range | 27.71× | 27.71× | 27.71× | 25.69× |
How to read these figures. Each column applies the stated provider rates and cache policies to the same workload used for the Sonnet 5 illustration. Holding the workload fixed isolates the effect of those pricing inputs. Model-specific tokenization, tool selection, output length, quality, latency, and observed use remain outside the comparison. Displayed costs are rounded, while the maximum/minimum range uses the underlying values. Refresh provider rates and cache rules before production planning. The comparisons do not establish that any provider or model will consistently deliver lower costs, better trading decisions, or superior investment outcomes.
Putting Inference Optimization into Practice with Alpaca
Choose the smallest useful surface
Start with the information you need. A quote-and-position check calls for market data and account positions. As you work out the question, Alpaca’s MCP Server lets you explore both in the AI client or editor you already use. Follow the calls the agent makes and the observations it relies on. Those give you the outline of a routine you can make repeatable.
Once the routine is clear, the Alpaca CLI lets you spell it out in commands and flags. Specify the symbols, date range, feed, adjustment setting, output fields, and completion rule so the procedure can be tested and replayed. Keep the relevant command available and the model may also avoid looking up the syntax again.
Writing the procedure down can save the model from rediscovering the steps each time. An MCP workflow can follow a settled sequence, and a CLI workflow may still need model interpretation. Choose whichever helps you express the task clearly, then inspect the requests that reach the model. Independent data requests can run together in application code before the model interprets their results. When one result determines what to request next, preserve that dependency.
With MCP, begin by exposing the toolsets the task needs. For a workflow that only retrieves stock market data:
export ALPACA_TOOLSETS=stock-data
uvx --with 'fastmcp==3.4.7' --with 'httpx==0.28.1' [email protected]The stock-data toolset also exposes documentation helpers and historical crypto reads, so inspect its tool list before treating it as a stock-only catalog. The earlier quote-and-position model uses a collection of tools from trading and stock-data together.
Inspect the tool definitions that actually reach the model. The host or application controls which ones it sends and how caching is configured.
The results deserve the same care as the tool catalog because they may return in several later prompts. Retrieve the symbols, intervals, and fields the task needs, and keep the feed, timestamps, missing values, and retrieval errors that affect interpretation. Ask for an explanation long enough to make the answer useful and reveal uncertainty or a failed check. Extra output adds to the bill too.
Keep the Cacheable Context Stable
The quote can change from one check to the next while the instructions stay the same. Put durable instructions and tool definitions before the changing observations so an eligible, matching prefix can be reused through cached reads. Then check the provider’s usage records for actual reuse. Cache rules and request timing determine whether that stable prefix receives the lower rate.
Keep Retries and Control Logic in the Application Layer
If a request fails in transit, the next job is to establish what happened. Give the client, broker integration, or application explicit rules for retries, idempotency checks, and reconciliation before it tries again. Keeping that recovery outside the model’s decision loop avoids asking the model to improvise a response to a transport failure.
When a workflow can change account state, make those rules explicit:
- Use paper trading while testing.
- Confirm the account and environment before any mutating request.
- Use client order IDs and reconciliation logic where appropriate.
- Retain the request, result, error response, and retrieval time so a decision can be investigated later.
The Alpaca paper trading environment is useful for testing a workflow’s mechanics, but it remains a simulation. Live execution conditions can differ materially.
Keep the Workflow Proportionate to the Decision
A useful optimization starts with a task you can recognize before and after the change. For the quote-and-position check, preserve the observations, their timing, missing data, and retrieval errors while changing how the model receives them.
Run the same task before and after each change to the catalog, cacheable prefix, or number of model rounds. Save the configuration, request sequence, billed usage, answer, and failures. A lower bill is useful only if the answer still does the work you needed.
Keep a change when the lower bill comes with the information and controls the task needs. The saved request sequence then becomes the starting point for the next experiment.
Choose Your Next Step
Start with one recurring quote-and-position check and measure the complete request sequence. Choose the interface that makes the experiment easiest to repeat.
- Explore interactively. Connect Alpaca’s MCP Server and compare the context sent across successive calls.
- Repeat a known request. Use the Alpaca CLI to keep the command and response shape consistent.
- Build the workflow into an application. Use our SDKs and Tools to manage request routing, retries, and retained records.
If you’re new to Alpaca, create an account and follow the Trading API setup guide before running the paper-account example.
Calculation reference
Assumptions and method
This reference documents the assumptions and illustrative calculations used in this analysis.
Scope and limitations
It models inference cost per agent decision using API rates and cache policies retrieved August 11, 2026. Refresh those inputs before production planning.
The calculation isolates API inference cost under the stated assumptions. Provider billing, customer usage, trading performance, and live execution costs are outside its scope.
Pricing assumptions
The detailed projection uses the dated Claude Sonnet 5 API rates and cache policy shown below.
| Assumption | Value | Use in the projection |
|---|---|---|
| Model | Claude Sonnet 5 standard | Default working example |
| Input rate | $2.00 / MTok | Ordinary uncached input |
| Output rate | $10.00 / MTok | All billed output |
| Cache-read rate | $0.20 / MTok | Warm, eligible prefix reads |
| Five-minute cache-write rate | $2.50 / MTok | Cold eligible-prefix writes |
| Minimum cacheable prefix | 1,024 tokens | Eligibility threshold |
| Initial eligible-prefix warmth | 95% in cache-enabled scenarios | Boundary stress uses 0% |
Scenario inputs
P is the stable prefix; N the number of sequential tool rounds; T tool-result tokens per round; O loop-total output; and h the probability that an eligible stable prefix is warm when a decision begins.
| Scenario | P | N | T | O | h | Cache |
|---|---|---|---|---|---|---|
| CLI, thin context + runtime lookup | 1,200 | 3 | 2,500 | 1,600 | 0.95 | Enabled |
| Scoped MCP | 11,890 | 2 | 2,500 | 1,600 | 0.95 | Enabled |
| CLI, full reference in context | 14,833 | 2 | 2,500 | 1,600 | 0.95 | Enabled |
| Full MCP | 25,366 | 2 | 2,500 | 1,600 | 0.95 | Enabled |
| Unscoped boundary stress case | 77,000 | 5 | 4,000 | 2,000 | 0.00 | Disabled |
These are estimated Sonnet-oriented scenario inputs. The cross-model comparison applies each model’s dated rates and cache policy to the same workload; it does not compare model-native tokenization.
Turn-by-turn billing ledger
Each decision makes Q = N + 1 model requests. Here, P is the estimated stable prefix; N is the number of sequential tool rounds; T is tool-result tokens per round; O is loop-total output; h is the probability that an eligible prefix is warm at the first request; and M is the minimum cacheable prefix. We allocate output evenly across requests, so A = O / Q and D = T + A is the replayable dynamic chunk. Intermediate assistant output is billed when generated and replayed with later tool results; final output is billed but not replayed. U, R, and W denote ordinary input, cache reads, and cache writes; subscripts p and t refer to the prefix and dynamic tail. Rates cᵢ, cᵣ, cʷ, and cₒ denote ordinary input, cache-read, cache-write, and output rates per million tokens.
With caching disabled:
For an initially eligible prefix (P ≥ M):
If a prefix becomes eligible only as the loop grows, earlier requests remain uncached; the first eligible request writes the cumulative prefix; later requests read the stored prefix and write only the newest reusable chunk.
Default Sonnet 5 outputs
Component values are rounded for display; totals and economic calculations use unrounded output.
| Scenario | Prefix | Tail | Output | Cost / decision | Inference cost / day (200 decisions) |
|---|---|---|---|---|---|
| CLI, thin context + runtime lookup | $0.001098 | $0.022040 | $0.016000 | $0.039138 | $7.827600 |
| Scoped MCP | $0.008501 | $0.014257 | $0.016000 | $0.038758 | $7.751603 |
| CLI, full reference in context | $0.010606 | $0.014257 | $0.016000 | $0.040862 | $8.172452 |
| Full MCP | $0.018137 | $0.014257 | $0.016000 | $0.048393 | $9.678671 |
| Unscoped boundary stress case | $0.924000 | $0.130000 | $0.020000 | $1.074000 | $214.800000 |
The maximum/minimum range in the default Sonnet illustration is $1.074000 / $0.0387580167 = 27.710396×: the unscoped boundary case divided by scoped MCP.
Operating-budget illustration
The illustration prices 200 completed checks per day and a 252-day operating year. Per-check inference cost is also expressed in basis points of $5,000 of assessed notional: C / 5,000 × 10,000. Daily cost is 200 × C, and annual cost is 252 × 200 × C. These are workload costs. No return is attributed to an individual check.
| Scenario | Cost per check / $5,000 assessed (bp) | Inference cost / 252-day year | Inference cost / day (200 checks) |
|---|---|---|---|
| CLI, thin context + runtime lookup | 0.078276 | $1,972.56 | $7.827600 |
| Scoped MCP | 0.077516 | $1,953.40 | $7.751603 |
| CLI, full reference in context | 0.081725 | $2,059.46 | $8.172452 |
| Full MCP | 0.096787 | $2,439.03 | $9.678671 |
| Unscoped boundary stress case | 2.148000 | $54,129.60 | $214.800000 |
The basis-point column normalizes cost without estimating investment returns. Repeated assessments can involve the same capital, and a hold decision can incur inference cost without a trade. Commissions, spreads, slippage, market impact, taxes, and other operating costs remain outside the model.
Model-rate sensitivity
Each column below applies provider rates and cache policies retrieved August 11, 2026 to the same Sonnet-oriented workload. This is a sensitivity to the dated pricing inputs. It does not measure model-specific behavior or comparative task quality.
| Model | Input | Output | Cache read | Cache write | Minimum cacheable prefix |
|---|---|---|---|---|---|
| Claude Opus 5 | $5.00 / MTok | $25.00 / MTok | $0.50 / MTok | $6.25 / MTok | 512 tokens |
| Claude Haiku 4.5 | $1.00 / MTok | $5.00 / MTok | $0.10 / MTok | $1.25 / MTok | 4,096 tokens |
| GPT-5.6 Terra | $2.00 / MTok | $12.00 / MTok | $0.20 / MTok | $2.50 / MTok | 1,024 tokens |
| Modeled configuration | Sonnet 5 | Opus 5 | Haiku 4.5 | GPT-5.6 Terra |
|---|---|---|---|---|
| CLI, thin context + runtime lookup | $0.039138 | $0.097845 | $0.021960 | $0.042338 |
| Scoped MCP | $0.038758 | $0.096895 | $0.019379 | $0.041958 |
| CLI, full reference in context | $0.040862 | $0.102156 | $0.020431 | $0.044062 |
| Full MCP | $0.048393 | $0.120983 | $0.024197 | $0.051593 |
| Unscoped boundary stress case | $1.074000 | $2.685000 | $0.537000 | $1.078000 |
| Maximum/minimum range | 27.71× | 27.71× | 27.71× | 25.69× |
Provider-specific tokenization, tool selection, output length, quality, latency, routing, and observed usage remain outside this comparison. Refresh provider rates and cache rules before production planning.
Evidence boundary
A five-run Sonnet 5 scoped cold/warm sample, comprising the original run and four replications, checks cache-billing categories for one serialized read-only fixture. Its median serialized prefix was 14,602 tokens, compared with the 11,890-token scoped scenario input. The sample is descriptive rather than an input to the projection. It does not estimate natural cache warmth, validate the tool-result or output assumptions, measure end-to-end MCP behavior or cross-model performance, or test cache expiry or refresh.
The content of this article is for general informational and educational purposes only. All examples are for educational and illustrative purposes only. The cost estimates, calculations, and comparisons presented are based on hypothetical modeling assumptions and limited testing. They do not represent guaranteed savings, actual customer costs, investment performance, or expected trading results. Actual costs and outcomes may vary depending on system configuration, usage, third-party pricing, and other factors.
Information and outputs generated through Alpaca’s MCP Server or connected AI agents are provided for educational and informational purposes only and do not constitute investment advice or a recommendation to buy, sell, or hold any security. AI-generated outputs may contain errors, omissions, or inaccuracies and should be independently reviewed and verified before being relied upon for investment decisions or trading activity. Alpaca does not recommend any specific security or investment strategy. Users should conduct their own due diligence before making investment decisions. All firms mentioned operate independently and are not responsible for one another's products or services.
Automated trading and AI-assisted workflows involve risks, including inaccurate or unintended trading instructions, programming errors, connectivity disruptions, API failures, and system outages. These risks may result in unintended transactions, execution failures, or financial losses. Automated checks, testing, and risk controls cannot guarantee the prevention of errors or losses.
References to third-party AI providers, models, products, or services are for informational purposes only and do not constitute an endorsement or recommendation by Alpaca. Such third parties are not affiliated with Alpaca unless expressly stated otherwise.
The Paper Trading API is offered by AlpacaDB, Inc. and does not require real money or permit a user to transact in real securities in the market. Providing use of the Paper Trading API is not an offer or solicitation to buy or sell securities, securities derivative or futures products of any kind, or any type of trading or investment advice, recommendation or strategy, given or in any manner endorsed by AlpacaDB, Inc. or any AlpacaDB, Inc. affiliate and the information made available through the Paper Trading API is not an offer or solicitation of any kind in any jurisdiction where AlpacaDB, Inc. or any AlpacaDB, Inc. affiliate (collectively, “Alpaca”) is not authorized to do business.
Securities brokerage services are provided by Alpaca Securities LLC (dba "Alpaca Clearing"), member FINRA/SIPC, a wholly-owned subsidiary of AlpacaDB, Inc. Technology and services are offered by AlpacaDB, Inc.
This is not an offer, solicitation of an offer, or advice to buy or sell securities or open a brokerage account in any jurisdiction where Alpaca Securities is not registered or licensed, as applicable.
