AI Trader - Moses Yebei

The Problem

LLM trading agents are hard to evaluate honestly: backtests overfit, and there is no standardized arena to compare strategies across markets. AI-Trader runs multiple LLM agents autonomously in live markets (NASDAQ 100, SSE 50, crypto) with zero human input, publishing results to a public leaderboard at ai4trade.ai.

What This Does

This is a fork of HKUDS/AI-Trader (21.5k stars upstream), a framework where you submit a strategy agent and it competes against others in live markets. agent/base_agent/ defines the base agent classes (daily and hourly variants); agent/base_agent_astock/ and agent/base_agent_crypto/ adapt them to A-share and crypto markets. agent_tools/ wraps trading, news, search, math, and price-lookup services. configs/ holds per-market JSON configs. The bulk of the repo — 1,714 of 1,796 files — is market data and agent run logs under data/.

How It Is Wired

Execution starts at main.py. The import graph is small — 58 internal modules, 39 edges — and it centers on two hubs. tools/general_tools.py is imported by 17 modules; tools/price_tools.py by 10. Both are high-blast-radius: a change in general_tools.py ripples across nearly a third of the codebase. The base agents in agent/base_agent/ sit mid-graph (Ca 2, Ce 3, instability 0.6). There is one import cycle: agent/base_agent_crypto/base_agent_crypto.py and prompts/agent_prompt_crypto.py are mutually reachable, which makes either file harder to change in isolation.

Agents reach the outside world through agent_tools/ — tool_trade.py, tool_alphavantage_news.py, tool_jina_search.py, tool_get_price_local.py — which is where effects leave the process (external APIs, trade execution). The function-level runtime path from main.py to those calls is not mapped by the available analysis; the import graph gives module edges only.

How To Use It

Setup: pip install -r requirements.txt. This is the only dependency manifest; there is no lockfile, so installs are not reproducible.
Configuration: copy .env.example to .env and set API keys. Per-market settings live in configs/*.json (default_config.json, default_astock_config.json, default_crypto_config.json).
Running: invoke main.py. Per the README, the intended contribution flow is a PR adding agent/{your_strategy}.py (inheriting from the base model), a config, and run instructions; the platform runs it for a week and publishes results.

Real-World Use

A team building a strategy-evaluation harness would subclass base_agent, register a config, and let the platform run the strategy against live markets alongside competitors. The public leaderboard provides a comparable benchmark instead of self-reported backtests, and the data/ logs give per-day JSONL traces of reasoning and positions for post-hoc analysis.

Code Health & Issues

Static analysis (measured, not opinion) found 61 findings: 16 high, 45 medium, across 7 kinds. Notable ones:

High — duplicated code: 2,509 repeated 6-line blocks across 47 files, concentrated in agent/base_agent/ and its variants; the three base-agent families are near-copies of each other.
High — deep nesting: 38 instances, max indentation depth 9 in tools/price_tools.py and the base agents.
High — import cycle: agent/base_agent_crypto/base_agent_crypto.py ↔ prompts/agent_prompt_crypto.py.
Medium — broad exception handling: 12 bare except clauses in tools/general_tools.py and tools/price_tools.py.
Medium — hub module: tools/general_tools.py has 17 dependents.

No test suite exists (39 source files, zero tests), so regressions ship undetected. CI runs GitHub Actions but has no dependency vulnerability scan, and the deploy workflow keeps persist-credentials at default with no job timeouts.

The Bottom Line

A functional LLM-trading competition framework with a real live leaderboard and public results — the data and logs are the asset. Code quality is research-grade: heavy duplication across market variants, a central hub module, and no tests. Use it to benchmark strategies, not as a base for production trading infrastructure.

What the analyser found

Deployment readiness

4/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,796 files

JSON176
Python39
Shell12
Markdown7
JavaScript6
HTML3

Express

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["docs 19 modules"] g1["data 13 modules"] g2["agent 7 modules"] g3["agent_tools 7 modules"] g4["tools 5 modules"] g5["prompts 3 modules"] g6["(root) 3 modules"] g2 -->|10| g4 g3 -->|8| g4 g5 -->|6| g4 g2 -->|5| g5 g6 -->|2| g5 g6 -->|2| g4 g5 -->|1| g2

Module dependencies

The 10 most depended-upon modules of 58, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_tools_general_tools["general_tools"] n1_tools_price_tools["price_tools"] n2_prompts_agent_prompt["agent_prompt"] n3_agent_base_agent_base_agent["base_agent"] n4_ent_astock_base_agent_astock["base_agent_astock"] n5_prompts_agent_prompt_astock["agent_prompt_astock"] n6_ent_crypto_base_agent_crypto["base_agent_crypto"] n7_prompts_agent_prompt_crypto["agent_prompt_crypto"] n8_t_base_agent_base_agent_hour["base_agent_hour"] n9_stock_base_agent_astock_hour["base_agent_astock_hour"] n3_agent_base_agent_base_agent --> n2_prompts_agent_prompt n3_agent_base_agent_base_agent --> n0_tools_general_tools n3_agent_base_agent_base_agent --> n1_tools_price_tools n8_t_base_agent_base_agent_hour --> n0_tools_general_tools n8_t_base_agent_base_agent_hour --> n1_tools_price_tools n8_t_base_agent_base_agent_hour --> n2_prompts_agent_prompt n8_t_base_agent_base_agent_hour --> n3_agent_base_agent_base_agent n4_ent_astock_base_agent_astock --> n5_prompts_agent_prompt_astock n4_ent_astock_base_agent_astock --> n0_tools_general_tools n4_ent_astock_base_agent_astock --> n1_tools_price_tools n9_stock_base_agent_astock_hour --> n4_ent_astock_base_agent_astock n9_stock_base_agent_astock_hour --> n5_prompts_agent_prompt_astock n9_stock_base_agent_astock_hour --> n0_tools_general_tools n9_stock_base_agent_astock_hour --> n1_tools_price_tools n6_ent_crypto_base_agent_crypto --> n7_prompts_agent_prompt_crypto n6_ent_crypto_base_agent_crypto --> n0_tools_general_tools n6_ent_crypto_base_agent_crypto --> n1_tools_price_tools n2_prompts_agent_prompt --> n0_tools_general_tools classDef cyc stroke:#ef4444,stroke-width:2px; class n6_ent_crypto_base_agent_crypto,n7_prompts_agent_prompt_crypto cyc;

Dependencies

1 of 6 declared dependencies are a major version behind. Resolved 6 of 6 against the registry.

Package	Declared	Latest	Behind
`fastmcp`	==2.12.5	3.4.7	1 major

Findings

MediumNo test files detected - untested code paths repository-wide
LowDependencies declared without a lockfile - non-reproducible builds requirements.txt

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high2

medium3

low1

Upgrade the pinned dependency carrying a critical advisorycritical14 occurrences

fastmcp@2.12.5 CVE-2026-32871 (critical) +13 more

The manifest pins the exact version the advisory covers, so this is not a warning about drift: the vulnerable code is what installs, and a critical rating means it is reachable over the network without credentials or user interaction.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Upgrade the pinned dependency carrying a published advisoryhigh4 occurrences

langchain-openai@1.0.1 CVE-2026-41488 (high) +1 more; langchain@1.0.2 CVE-2026-55443 (medium) +1 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Add a test suite; this repository has nonehigh39 occurrences

39 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/deploy-pages.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow

.github/workflows/deploy-pages.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.