Local vs hosted models for trading
A trading assistant sees your positions, your sizing, your reasoning and your losses. Where the model runs determines who else can see them — and that is a different question from which model is better at the task.
Short answer
- Best capability, standard privacy posture → hosted frontier model. What most people should use.
- Position data must not leave the machine → local model, accepting a capability gap.
- Mixed → local for anything touching positions, hosted for general reasoning that carries no account data. Usually the right answer.
- Phone access → hosted, and see the caveat below.
What actually gets sent
Worth enumerating, because it is more than people picture:
- Positions, balances and exposure
- Entry, stop and size for every plan discussed
- Your reasoning — including the parts you would not say aloud
- Losses, drawdowns and the sequence of them
- Which instruments you follow and when you are active
That is a complete picture of your trading. Not credentials — those stay with the MCP server, see where an MCP server keeps your API keys — but arguably more revealing.
The hosted case
Capability. Frontier hosted models are meaningfully better at the reasoning that makes this useful. On the tasks where AI actually helps — summarising exposure, explaining position behaviour, structuring a plan — the gap is real.
No infrastructure. No GPU, no model management, no quantisation decisions.
The consideration is that your trading data goes to a third party. Whether that matters depends on your threat model and the provider’s retention terms, which are worth reading rather than assuming.
A specific caveat for phone access: hosted clients need a remote MCP server, which changes the security problem entirely — from local credentials to an internet-reachable service holding exchange keys. Alpaca’s own documentation says not to expose its server publicly with your API keys for exactly this reason. See using ChatGPT with a trading MCP server.
The local case
Data stays put. The complete argument, and for some people it is sufficient.
No per-token cost. Hardware instead of usage. Run the numbers through the LLM cost calculator — at low volume, hosted is cheaper than the hardware; at high volume the crossover arrives.
No rate limits, no availability dependency.
The costs, stated honestly:
- Capability gap. Smaller local models are worse at multi-step reasoning and more prone to the failures in how AI hallucination shows up in market analysis.
- Context limits. Chart data plus positions plus history fills a window quickly, and smaller models degrade at long context faster than benchmarks suggest.
- Operational overhead. Updates, quantisation, inference serving. It is infrastructure.
- Weaker tool use. Reliable structured tool calling is where smaller models most often fall short, and it is exactly what an MCP setup depends on.
That last point is the practical blocker more often than raw reasoning quality. A model that cannot reliably emit a well-formed tool call is not usable for this regardless of how well it discusses markets.
The split that usually wins
Not one or the other:
Local for anything touching positions. Exposure summaries, plan drafting, journal review. Data stays on the machine, and these tasks are more structured and less demanding — a smaller model handles them adequately.
Hosted for general reasoning with no account data. Explaining a mechanism, working through arithmetic, discussing an approach in the abstract. No position data is involved, so the privacy question does not arise.
This maps onto a boundary you should be maintaining anyway. Keeping research and trading in separate sessions is the primary defence against prompt injection — and the split above makes that separation the natural configuration rather than a discipline you have to sustain.
What does not change either way
Capability differences do not change the boundaries. Whichever you run:
- The exchange key decides what is possible — read-only vs trade permission.
- Limits belong in code, not prompts.
- Approval happens on real parameters — designing an approval workflow.
- Order calls are never blind-retried.
A local model is not safer to give order tools to. It is a different custody arrangement for your data, not a different risk profile for your account.
FAQ
Should I use a local model for AI trading?
For anything touching position data, it is a reasonable choice and the privacy argument is real. For the reasoning-heavy parts, hosted frontier models are meaningfully better, and the most practical arrangement is usually a split — local where account data is involved, hosted where it is not.
What data does an AI trading assistant actually see?
Your positions and balances, the entry, stop and size of every plan discussed, your reasoning, your drawdowns, and which instruments you follow. Not your API credentials, which stay with the MCP server — but a fuller picture of your trading than the credentials would give.
Is a local model safer for trading?
Safer for your data, not for your account. Where the model runs does not change what your API key permits, whether limits are enforced in code, or whether an approval step shows real parameters. Those boundaries do the safety work regardless.
Can smaller local models handle MCP tool calling?
This is usually the limiting factor rather than reasoning quality. Reliable, well-formed structured tool calls are where smaller models most often fall short, and an MCP setup depends on them entirely. Test it specifically before committing to a local setup.