What an AI trading assistant costs to run
The running cost of an AI trading assistant is the total number of tokens processed across every model call it makes — and a single request typically triggers several calls, each of which resends the entire context accumulated so far. The per-token price matters less than people assume; the number of tokens per decision matters more.
This page explains where those tokens come from, works through an illustrative trade-plan request call by call, and shows which levers actually move the total. It does not quote any provider’s prices. Those change often enough that a figure here would be wrong within weeks, so price stays a variable you supply to the LLM cost calculator.
Why this matters now
A chat model answering a question makes one call. An assistant connected to your exchange through an MCP server does not. Asked to draft a plan, it fetches your balance, your positions, a quote and some candles — and each fetch is another round trip through the model, carrying everything before it.
So estimates built from “one prompt, one answer” undercount, sometimes by a multiple. The same pattern drives rate limits in an MCP trading setup: one question, many calls.
How it actually works
- Two meters. Providers bill input tokens (what the model reads) and output tokens (what it writes) separately, and output is typically priced several times higher per token.
- The whole context is input on every call. The model keeps no memory between calls. The system prompt, your rules, the conversation and every earlier tool result are sent again each time.
- Tool definitions are input too. Every tool the MCP server exposes has a name, description and parameter schema that sit in the context on every call, whether or not the model uses that tool.
- Each tool call is a round trip. The model emits a call, your client runs it, and the result goes back in a new model call along with everything before it.
- Tool results stay in the context. A large result — a few hundred candles, a full order book — is paid for again on every later call in the conversation.
- Repeated prefixes can be cheaper. Many providers offer a reduced rate for input that is identical across calls, such as a fixed system prompt and tool list.
One trade plan, call by call
An illustrative request: “Draft a long plan on this instrument within my usual limits.” The token counts are assumptions chosen to be plausible, not measurements of any product:
- System prompt and rules: 2,000 tokens
- Tool definitions: 3,000 tokens
- Your message: 100 tokens
The model fetches balance and positions (1,500 tokens of results), then a quote (400), then candles (6,000), then writes the plan (700 tokens):
| Call | Input tokens | Output tokens | What happened |
|---|---|---|---|
| 1 | 5,100 | 80 | Requests balance and positions |
| 2 | 6,680 | 40 | Requests a quote |
| 3 | 7,120 | 50 | Requests candles |
| 4 | 13,170 | 700 | Writes the plan |
| Total | 32,070 | 870 |
The final context is under 14,000 tokens, but the request billed about 32,000 input tokens, because early material was paid for four times.
The cost is then:
cost = input tokens × input price
+ output tokens × output pricewith the prices yours to fill in. Suppose output were priced at five times input — an assumption for this example, not any provider’s ratio. Output would then be about 12% of this request’s cost. In a single-call chat, a long answer often dominates the bill; in a tool loop, resent input usually does. Check both shapes in the calculator rather than assuming either.
The stable prefix — system prompt plus tool definitions, 5,000 tokens on each of four calls — is about 62% of the input here. That is the share a reduced-rate cache would apply to, where your provider offers one.
Where it grows: long sessions
Now ask for six plans in one conversation. Each request carries the full history of the previous ones, including their tool results:
| Request in session | Input tokens for that request |
|---|---|
| 1st | 32,070 |
| 2nd | 67,550 |
| 3rd | 103,030 |
| 4th | 138,510 |
| 5th | 173,990 |
| 6th | 209,470 |
Six plans in one session: about 725,000 input tokens. The same six plans in six fresh sessions: about 192,000. Roughly 3.8 times the input for the same work, and the long session is also worse at the job — old quotes sit in the context looking current, as context windows and stale market data explains.
Cost per call vs cost per decision
This is the distinction people confuse. A provider’s price page and most estimates are per call. What you care about is per decision: one plan, one exposure check, one journal review.
The calculator works per call, so there are two honest ways to feed it:
- Per request: enter total input and output tokens for a whole request (32,070 and 870 above) and set calls per day to the number of requests.
- Per call: enter an average call and multiply calls per day by the round trips per request.
Either works. What does not work is entering a single call’s tokens as if they were the whole request, which in this example misses most of the input.
A local model changes the meter, not the arithmetic: no per-token bill, but hardware and a context window that fills just as fast. See local vs hosted models for trading.
Where the boundary should sit
The levers, roughly in order of effect on the example above:
- Start fresh sessions. The single largest saving, and it improves accuracy.
- Fetch in parallel. If model and client support several tool calls in one step, the four fetches become one round trip: two calls and about 18,250 input tokens instead of four calls and 32,070.
- Trim tool results at the server. Returning a summary instead of raw candles — 1,500 tokens instead of 6,000 — cuts the example to about 27,570.
- Expose fewer tools. A read-only toolset for analysis sessions shrinks the prefix on every call, and it is the safer configuration anyway — read-only vs trade permission.
- Cap round trips per request. A hard limit on tool calls bounds cost and also stops a confused model from looping; see how LLM tool calls go wrong on orders.
- Ask for a structured plan, not an essay. Shorter output, and easier to validate — why a trade plan should be structured output.
- Keep the prefix byte-identical so caching can apply.
Whether to pay per token with your own key or buy a subscription is the calculator’s break-even row. CoTrading is free with your own model key and sells hosted credits only as the convenience option; the pricing page has the current terms and the docs cover setup.
FAQ
How much does it cost to run an AI trading assistant?
It depends on tokens per decision far more than on the headline price. One request to draft a trade plan can involve several model calls, each resending the full context — in an illustrative four-call request, billed input was more than twice the final context size. Estimate your token counts per request, then enter your provider’s current prices in an LLM cost calculator.
Why do tool calls make AI assistants more expensive?
Each tool call is a round trip: the model requests data, your client fetches it, and the result is sent back in a new model call together with everything before it. A request that triggers three fetches is four billable calls, and every tool result stays in the context and is paid for again on each later call.
Is input or output the bigger cost for a trading assistant?
Output is priced higher per token, so for a single call with a long answer it often dominates. In tool-heavy requests the resent context usually outweighs it, because the same input is billed on every round trip. The only reliable answer is to compute both for your own setup.
How can I reduce the cost of an AI trading assistant?
Start fresh sessions instead of long ones, let the model fetch data in parallel where supported, have the server return summaries instead of raw data, expose only the tools a session needs, and ask for a short structured plan. Keeping the system prompt and tool list identical across calls lets provider caching apply.