Post-Opus 4.6, LLMs feel much better at using bash, code, local files, and tools.
So I kept coming back to a simple question: if a model can use a computer reasonably well, why can’t I just give it my broker account, a strategy, and let it trade?
My conclusion is that the blocker is not model capability in the abstract. It is the system around the model.
A raw LLM breaks on a few practical things almost immediately:
• no persistent operating memory across sessions
• no trustworthy record of what it did and why
• no hard approval boundary before money moves
• no cheap always-on monitoring if every check requires an LLM call
• no reliable enforcement of limits, permissions, or workflow rules unless that lives outside the model
So the problem is not really “can the model call a broker API?” The problem is that trading needs a harness.
My friend and I built one for this called Vibe Trade. It is open source, MIT licensed, and currently runs locally on your machine connected to Dhan.
The basic design is:
1. Immutable trade journal
Every action is logged at decision time with timestamp, reasoning, and observed signals. The agent cannot rewrite its own history after the fact.
2. Hard approval gate
Before any order is placed, the system generates a structured approval request. Execution is blocked until the user approves. This is enforced in code, not left to the model’s discretion.
3. Event loop outside the LLM
Market watching is handled in plain JS on a timer. Price checks, time rules, and indicator thresholds run every 30 seconds without invoking the model. The LLM only wakes up when something needs reasoning.
4. Playbooks / skill files
Strategies live in markdown documents that get loaded as operating context on each decision. Example: “replicate the Nifty Defense Index and rebalance weekly.” This gives the agent a stable workflow definition instead of relying on chat history.
The first use case that made this feel real to me was very unglamorous: portfolio rebalancing.
I used to make Smallcase-style index replication portfolios and then forget to rebalance them on time. With this setup, I can define the strategy once, let the non-LLM layer monitor for conditions, and have the agent prepare actions for approval. That was the first point where it stopped feeling like a demo and started feeling useful.
A few caveats:
• UI is still weak; it is mostly a chat interface right now
• Dhan only for now
• local install only for now
• requires Node.js and an Anthropic API key
Repo: github.com/vibetrade-ai/vibe-trade
I’m posting this mainly because I think more people will try building “LLM as operator” systems now that tool use is better, and finance makes the failure modes very obvious.
The questions I’m interested in are:
• What other harness components are missing for something like this?
• Would you trust a local system like this more than a hosted one, or less?
• What repeatable financial workflows would you automate first?
So I kept coming back to a simple question: if a model can use a computer reasonably well, why can’t I just give it my broker account, a strategy, and let it trade?
My conclusion is that the blocker is not model capability in the abstract. It is the system around the model.
A raw LLM breaks on a few practical things almost immediately:
• no persistent operating memory across sessions • no trustworthy record of what it did and why • no hard approval boundary before money moves • no cheap always-on monitoring if every check requires an LLM call • no reliable enforcement of limits, permissions, or workflow rules unless that lives outside the model
So the problem is not really “can the model call a broker API?” The problem is that trading needs a harness.
My friend and I built one for this called Vibe Trade. It is open source, MIT licensed, and currently runs locally on your machine connected to Dhan.
The basic design is:
1. Immutable trade journal Every action is logged at decision time with timestamp, reasoning, and observed signals. The agent cannot rewrite its own history after the fact.
2. Hard approval gate Before any order is placed, the system generates a structured approval request. Execution is blocked until the user approves. This is enforced in code, not left to the model’s discretion.
3. Event loop outside the LLM Market watching is handled in plain JS on a timer. Price checks, time rules, and indicator thresholds run every 30 seconds without invoking the model. The LLM only wakes up when something needs reasoning.
4. Playbooks / skill files Strategies live in markdown documents that get loaded as operating context on each decision. Example: “replicate the Nifty Defense Index and rebalance weekly.” This gives the agent a stable workflow definition instead of relying on chat history.
The first use case that made this feel real to me was very unglamorous: portfolio rebalancing.
I used to make Smallcase-style index replication portfolios and then forget to rebalance them on time. With this setup, I can define the strategy once, let the non-LLM layer monitor for conditions, and have the agent prepare actions for approval. That was the first point where it stopped feeling like a demo and started feeling useful.
A few caveats: • UI is still weak; it is mostly a chat interface right now • Dhan only for now • local install only for now • requires Node.js and an Anthropic API key
Repo: github.com/vibetrade-ai/vibe-trade
I’m posting this mainly because I think more people will try building “LLM as operator” systems now that tool use is better, and finance makes the failure modes very obvious.
The questions I’m interested in are:
• What other harness components are missing for something like this?
• Would you trust a local system like this more than a hosted one, or less?
• What repeatable financial workflows would you automate first?