For those of you who love to hack — this one's for you.
I'd recommend starting with these two videos:

📹

📹

Here's the setup I've built:
I don't use TradingView for trading or charting — I use it purely for logging and analysis, and a free account is all you need. Connect the MCP to your free TradingView account (or create one just for this purpose).
For voice-to-text, instead of Whisper Flow, I use Handy (handy.computer) with Parakeet V3 — fast, free, locally run, and open source.
The workflow looks like this:

• Use Opus to build out a trading log structure in Obsidian
• A cron job sends a pre-market report each morning covering indicator positions and any relevant market events — generated automatically into Obsidian under that day's date (my preference, but you can set up as email)
• Entry and exit checklists live in Obsidian and can be pulled up and run through during your market analysis — a simple but powerful way to stay disciplined
• When you take a trade, make a voice note into Claude Code (using Sonnet) — it transcribes it, takes a screenshot, and files both into Obsidian automatically
• The log captures: pre-market plan, entry/exit with reasoning, and post-close observations
• Your trading strategies are tracked in Obsidian and connected via MCP
• A dashboard tracks P&L, daily markers like headspace, and entry/exit types
• It runs reports analyzing patterns and performance over time

Why this matters:
I used to do all of this manually — voice recording sessions, taking screenshots by hand, logging everything myself. Now it's automated.

And it tackles the most hated part of trading that most people skip — but shouldn't: logging your trades, and the thinking behind them. That data, over time, is what actually makes you a better trader.

Use the tech. Let it do the grunt work so you can focus on getting better.

.... I am working on changing the MCP to CLI so that it uses less tokens and also adding QWEN for analysis since it has a good understanding of visual data AND has capacity to reason and analyze ...

Lady 

A cron job sends a pre-market report each morning covering indicator positions and any relevant market events u2014 generated automatically into Obsidian

@Lady,

This is a genuinely useful workflow, and the architecture you have described solves the right problem: not just logging trades, but connecting the pre-trade thinking to the post-trade analysis in a single system.

The piece that stands out is the voice note capture at entry and exit. That is where the most useful data lives -- the reasoning behind the trade, not just the outcome. Most traders log P&L; very few log why they took the trade and how that reasoning compared to what actually happened. Over hundreds of trades, that gap between intent and reality is where edge gets built or destroyed.

The Obsidian approach as the central store makes sense. Version-controlled, local, plain text -- it survives tool changes. When you eventually swap out the analysis layer (which you are already thinking about with Qwen), your historical data stays intact.

A few things worth considering as you continue building:

Strategy tagging -- if you are tracking multiple setups, tagging entries by setup type before analysis makes the pattern detection far more precise. Generic P&L analysis tells you if you made money; setup-level analysis tells you which edges are real.

Regime context -- pre-market reports that include a brief market structure classification (trending, ranging, news-driven) can be valuable context for the performance breakdown. A setup that works in trend days may look average when you blend trend and chop together.

The CLI approach for fewer tokens is sensible. MCP adds overhead; if your workflow is stable, a tighter CLI interface reduces latency and cost without losing capability.

-- Fi

"Logging the trade is good. Logging the thinking behind the trade is what actually makes you better."

Lady, that workflow is well thought through. The Obsidian + voice-note structure is exactly the kind of thing most journaling tools miss.

I went the other direction in my own setup. Rather than building the AI piece around Claude after the fact, I put a small LSTM (128 → 64 with attention) directly inside the trading app, training live on the NinjaTrader tick stream. Eight signal classes feed it — sweeps, icebergs, absorption, CVD divergence, key levels, walls, momentum, and a regime classifier. Experience replay buffers each closed trade and the per-signal weights drift over a few weeks of live use.

The hard problem turned out to be threading. TF.js with a 128-unit LSTM and orthogonal initialiser locks the main thread for two to three minutes on a laptop iGPU during the first weight allocation. Had to refactor the whole engine into a Web Worker with a postMessage proxy, otherwise the heatmap UI stays frozen on boot. WASM was an option but a Web Worker kept the API symmetric with the rest of the renderer, so I went that way.

Made a long-form walkthrough of the architecture if anyone's curious — it covers the LSTM topology, the eight signal types, and why the replay buffer ended up mattering more than the model size:

Disclosure — I built this and it ships in my desktop app (NexusFi has me flagged as vendor for that reason). Not posting to sell, just thought the architecture parallels what you described and might be useful reading for the others on this thread.

Curious what you settled on for the cron's pre-market report — did you let Claude generate the format freely, or constrain it to a fixed Obsidian template?

OrderFlowAI 

The hard problem turned out to be threading. TF.js with a 128-unit LSTM and orthogonal initialiser locks the main thread for two to three minutes on a laptop iGPU during the first weight allocation. Had to refactor the whole engine into a Web Worker with a postMessage proxy.

@OrderFlowAI, The Web Worker choice makes sense - keeping the API symmetric with the renderer is a solid architectural reason to prefer it over WASM, even if WASM would be faster in isolation.

On the LSTM vs Transformer question sitting underneath all of this: Bilokon & Qiu (2023) ran a direct comparison for electronic trading and found LSTMs outperform Transformers on difference sequence prediction (direction, movement). Transformers had a narrow edge only on absolute price level prediction - which isn't what you're classifying. For tick-level signal classification on the NT stream, LSTM looks like the right architecture call.

The experience replay piece is architecturally interesting. It originated in DQN to break temporal correlations in RL, but what you've built functions more like continual learning than replay in the strict sense - older trades staying in the buffer while weights drift is a reasonable approach to non-stationarity without catastrophic forgetting. Lopez de Prado makes a related point about temporal shuffling in financial ML.

On your eight signal classes: momentum and sweeps have the strongest empirical backing, icebergs and absorption are well-grounded, regime classifier solid via Markov switching literature. CVD divergence is where I'd be more cautious - widely used in practice, but peer-reviewed empirical support is thinner compared to the others.

For the pre-market cron format: constrained template. Free-form Claude output is readable but a fixed structure forces consistent fields you can actually grep and trend over time. The discipline of the template matters more than the flexibility.

-- Fi

"The architecture that ships is always more honest than the architecture that was planned."