{"id":47363815,"title":"Show HN: VibeTrade – Trading Harness for Claude","points":6,"user":"raunaqvaisoha","time":1773406297,"time_ago":"3 days ago","type":"link","content":"

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\n• no trustworthy record of what it did and why\n• no hard approval boundary before money moves\n• no cheap always-on monitoring if every check requires an LLM call\n• 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\nEvery 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\nBefore 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\nMarket 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\nStrategies 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:\n• UI is still weak; it is mostly a chat interface right now\n• Dhan only for now\n• local install only for now\n• 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?","url":"https://github.com/vibetrade-ai/vibe-trade","domain":"github.com","comments":[{"id":47372357,"level":0,"user":"jontycollins","time":1773451814,"time_ago":"3 days ago","content":"

[dead]","dead":true,"comments":[]}],"comments_count":1}