The full reviews behind Chapter 5’s summary: the brokers kept for jobs other than framework execution, Webull’s support channel, and the script-language note.
Robinhood’s distinctive feature for options traders is that a margin account can trade with unsettled stock and option proceeds at once. In a cash account, as at every broker, proceeds from an options sale are safely reused once they settle the next business day. This framework’s spreads require a margin account at Robinhood as at every other broker, or spread approval inside an IRA (Chapter 6). The clean mobile interface makes it a common first brokerage account.
Limitations: Robinhood’s options interface is not designed for the speed and precision that credit-spread management requires. The order entry flow for multi-leg structures is slower than Webull’s. Robinhood has no custom indicator scripting, but that no longer keeps the GEX map off the screen: the chart layer runs on TradingView whichever broker executes. A trader who starts at Robinhood generally moves to a platform with stronger multi-leg order management before trading the framework live; in my case that platform is Webull. Chapter 23, Section 4 covers account structure.
Fidelity’s strength in this ecosystem is options trading within IRA accounts. The options approval process for IRAs is straightforward at Fidelity, and the platform supports defined-risk spreads, the full set of structures this framework uses, within traditional and Roth IRA accounts. For traders managing a multi-account portfolio that includes tax-advantaged retirement accounts, Fidelity provides a reliable environment with strong customer service and capable desktop platforms in Active Trader Pro and its successor, Fidelity Trader+.
Active Trader Pro limitations: Fidelity is phasing out Active Trader Pro in favor of Fidelity Trader+. Active Trader Pro is a capable platform, but it is not optimized for the rapid visual workflow that 0DTE trading requires. The options chain interface and the charting environment are both serviceable. But serviceable is a different category from purpose-built for speed. For IRA options trading where the pace of execution is lower and the primary concern is approved structure access and tax treatment, Fidelity is well suited. As a primary execution platform for high-tempo 0DTE sessions, it is not the first choice.
Schwab’s position in the ecosystem is defined by thinkorswim, the trading platform inherited through its acquisition of TD Ameritrade. thinkorswim remains one of the most capable retail trading platforms available: the options analytics are deep, the charting environment is professional-grade, and thinkScript provides a custom indicator scripting capability that is broadly comparable to Pine Script in its flexibility.
thinkScript and the chart layer: thinkScript, like WebullScript, is not directly portable to Pine Script. Traders who have built indicator libraries in thinkorswim will need to translate those scripts to run them on TradingView, or translate the framework’s chart layer to run it on thinkorswim. The translation is mechanical: the logic transfers, the syntax does not. thinkScript versions are not included in Appendix B because the framework does not chart on thinkorswim, but the Pine Script Suite on this site, which Appendix B documents, is the starting point for that work.
Post-merger history: Schwab completed moving the last TD Ameritrade accounts in 2024. The thinkorswim platform came through largely unchanged. A trader already established on thinkorswim has no structural reason to move.
The relationship between Pine Script and WebullScript is a practical reality of this framework’s ecosystem. The operational charting language is Pine Script, the broader community scripting language, with the most documentation, the most examples, and the most active development. WebullScript is the language of the reference version for Webull charts. Traders will encounter both.
The key operational point is that the framework’s chart layer is built and maintained in Pine Script. When Claude generates a session’s script output, it generates the complete GEX Suite, ready to paste into the TradingView Pine Editor; on request, it generates the WebullScript blocks instead. Chapter 12 covers the chart layer in operational detail. Appendix B prints the WebullScript blocks in full and documents the Suite, whose code is on this site’s Scripts page.
Customer support as a feedback channel: Webull’s in-app support portal functions as a real two-way communication channel rather than a deflection layer. Feature feedback submitted through the channel reaches platform engineering, and the responses indicate that requests are read and considered, not auto-acknowledged and discarded. As one example: I have submitted feature feedback requesting bracketed exit functionality, a single order construct that pairs an upper-end profit limit with a lower-end stop limit, so both resting exits sit on one ticket. Whether that specific request ships is unknown. What the channel demonstrated is that the request was received as a serious operational input rather than dismissed. For a platform that hosts the daily workflow, a working feedback channel is not a luxury. It is part of what makes the platform sustainable.
Integrated AI scripting assistant: Webull has integrated an in-platform AI coding assistant called Vega into the desktop script editor. Vega is positioned as a TypeScript scripting environment for indicator development and supports natural-language code generation against Webull’s charting API. This is a real platform-level capability: few retail platforms have offered integrated AI scripting, and the addition lowers the barrier to custom indicator development for traders who do not already have a scripting background. A few honest caveats matter for framework users specifically. Vega is an in-platform code generator. It is not a replacement for the framework’s external Claude workflow, which serves a different role: premarket analysis, GEX structure interpretation, trade evaluation, post-mortem synthesis, and persistent context across sessions. The Vega/TypeScript environment is also separate from WebullScript; they coexist in the same editor but are not interchangeable. The full evaluation, including a worked translation of the GEX Levels script, is on this site’s Vega evaluation page; Chapter 10 carries the summary. The conclusion: Vega is a capable in-platform code generator and translates WebullScript to TypeScript with high fidelity when given explicit code as input, but it is not a strategic intelligence layer in the way the framework’s external Claude workflow is, and TypeScript’s class-based machinery adds workflow friction without offsetting capability gain for the framework’s static-hline indicator pattern specifically. WebullScript was the framework’s syntax of record at the time of that evaluation; the chart layer has since moved to Pine Script for the reasons in Chapter 12, and the evaluation’s finding on TypeScript stands. Vega is better suited to calculated indicators (Bollinger Bands, MACD, custom oscillators) that fall outside this framework’s scope. At the time of that evaluation, a mid-session level change was made by hand in the level script, and WebullScript’s flat list of hline() calls was faster to scan and change than TypeScript class declarations and plot-handle assignments, a difference that mattered when the edit window was measured in seconds, not minutes. The framework now replaces the whole script on every update, never a partial edit (Chapter 12, Section 7; Appendix B).
Mobile Vega—market-context chatbot: On the mobile app, Vega operates as a generative AI chat assistant rather than a script editor, a different product sharing the same name. Mobile Vega is watchlist-aware, has access to real-time market data, and responds to custom prompts within the trading-platform context. It was tested for end-of-day market summaries, news scans across watchlist symbols, and ad-hoc market-context queries when the phone is the only screen. It was not kept: Claude covers the same queries with web search and the framework’s context loaded, from its own mobile app (Chapter 10; Appendix E). Neither desktop nor mobile Vega is part of the framework’s toolkit.