LLM Trading Lab: a forward-only record of ChatGPT managing a micro-cap portfolio

The question this repository was built to answer

The README opens with a plain motivation: the author kept seeing advertisements claiming an AI could pick undervalued stocks, assumed they were selling subscriptions, and wanted to know how the claim would hold up. The experiment that followed started with $100 and asked whether a large language model could generate alpha or at least make defensible trading decisions using real-time data. The subject is micro-cap equities, which is the hardest place to test that question, because spreads are wide and published research is thin.

The intended audience is narrow. This is for someone who wants to inspect a real decision record rather than a backtest: the repository keeps daily updates, trade logs, weekly research summaries and a 40 page PDF evaluation under Experiments/chatgpt_micro-cap/evaluation/paper.pdf. It is not aimed at someone who wants a library to import. There is no package to install, no API surface described, and no release has been published. The unit of reuse is the folder layout and the scripts inside it.

What the repository actually contains

The layout in the README shows a single experiment directory with a trading script, a graphing folder holding daily_returns.py and drawdown.py, two CSV files named Daily_Updates.csv and Trade_Log.csv, an evaluation folder, collected artifacts, images, a tables directory with metrics.txt, and two metrics scripts, load_dataV3.py and episode_pcr.py. A processing folder holds ProcessPortfolio.py.

Two claims in the README deserve scrutiny. The feature list mentions a live trading engine used in production and automated stop-loss enforcement, but the tree shows one script, trading_script.py, with no broker adapter, no scheduler and no separate risk module. Either the enforcement lives inside that single file or the description is looser than the layout suggests. The repository also states that historical artifacts remain unchanged and that new work is layered on top without rewriting past results. That is a discipline choice, and it means the CSV files function as an append-only ledger rather than a dataset you can freely reshape.

How the pieces fit together

The data flow implied by the tree runs in one direction. Something outside the repository produces a decision, captured in collected_artifacts/chats.md and the weekly summaries. That decision is recorded as a trade in csv_files/Trade_Log.csv and as a portfolio state in csv_files/Daily_Updates.csv. The graphing scripts read those CSVs to produce the images, and the metrics scripts, load_dataV3.py and episode_pcr.py, compute the analytics that end up in tables/metrics.txt and the evaluation report.

The important architectural point is that the model is not in the loop at runtime. There is no inference call in the described layout. ChatGPT produces a decision as text, a human or script transcribes it, and the CSVs become the system of record. That separation is what makes the experiment auditable: the reasoning is frozen in chats.md before the outcome is known. It also means the repository cannot be described as an automated trading system, whatever the feature list says about a live engine.

Getting it running on your own machine

The README gives a requirements.txt and a Makefile at the root, plus a stated stack of Python 3.11 or later, pandas, yfinance as the primary data source, Stooq as a fallback, and Matplotlib. The conventional sequence would be to create a virtual environment, install the requirements, and then invoke the Makefile targets, but the README does not list the target names, so you have to read the Makefile to find them.

The scripts are addressed by path rather than by package name. Expect to run something of the form python Experiments/chatgpt-micro-cap/trading_script.py, with the graphing and metrics scripts invoked the same way. Note the mismatch between the tree, which uses lowercase chatgpt_micro_cap, and the README prose, which writes chatgpt-micro-cap with hyphens. On a case-sensitive filesystem the directory name in the tree is the one that exists. The CSV filenames are capitalised exactly as shown: Daily_Updates.csv and Trade_Log.csv. If you write your own loader, match that capitalisation, because the metrics scripts presumably depend on it.

The limitation that matters most: one $100 run

The entire empirical basis is a single experiment with a single starting balance of $100. That is enough to demonstrate a method and to produce a readable evaluation, and the forward-only logging makes the record honest. It is not enough to support any general claim about LLM stock picking. A sample of one cannot separate the model's skill from the market regime it happened to trade in, and micro-cap prices in particular are sensitive to liquidity conditions that vary month to month.

The $100 figure creates a second problem. In micro-caps, commission and spread costs are large relative to a small position, so the achievable return is bounded by frictions that a larger account would not face in the same proportion. Any reader tempted to scale the result upward should treat the reported metrics as an upper bound rather than a forecast. The README itself concedes that the project moved past chasing alpha, which is a fair framing: the value here is the process record, not the return.

Where a different tool is the right choice

If your goal is to test whether an LLM can make trading decisions under controlled conditions, the LIBB framework linked from the README is the more appropriate starting point. The author describes it as the general experimental framework built for LLM research, and it is intended for upcoming experiments rather than being tied to this one micro-cap run. The difference in approach is scope: LLM Trading Lab preserves one specific live experiment with its own artifacts and its own rules, while LIBB is designed to be reused across experiments. Choosing between them is a question of whether you want a case study to read or a harness to run.

If your goal is automated execution against a broker, neither repository is the answer as described. There is no broker integration in the layout, and the decision step involves a language model producing text that has to be captured. A conventional backtesting library with historical price data would give you faster iteration and larger samples, at the cost of the forward-only property that gives this experiment its evidential weight.

Maintenance, licensing and what to check before you fork

The repository is not archived and the last push is dated 2026-06-24, so it is active. No releases have been published, which means there is no versioned artifact to pin and no changelog to read. Upgrades arrive as commits to main. Because past artifacts are deliberately left unchanged, a pull can add new experiment folders without altering your existing CSVs, which reduces merge risk but also means the repository will accumulate rather than consolidate. Budget time for reading commit history rather than release notes.

The licence is listed as unknown in the repository metadata and the README does not name one. That is the first thing to resolve. Without an explicit licence, the default position is that no rights are granted, so copying the code into your own project carries risk that a permissive licence would remove. Check for a LICENSE file at the root before you reuse anything, and if none exists, ask the maintainer. This is a factual gap in the repository, not a legal opinion, and it is the kind of gap that should be settled before code moves between projects.

Editorial conclusion

Adopt LLM Trading Lab if you want a documented, forward-only record of an LLM making portfolio decisions and a directory structure to reuse for your own run. Do not adopt it as a production trading system: the README describes a single $100 experiment, no releases are published, and the licence is not stated in the repository metadata, so redistribution terms are unclear. Before building on it, open trading_script.py and the csv_files directory to confirm the accounting logic and the stop-loss enforcement match the feature list, and check the repository for a LICENSE file, because that determines whether you can reuse the code at all.

Official sources

1. Issues
2. LuckyOne7777/LLM-Trading-Lab on GitHub
3. README