Nexus II - A Python coded AI that advises and a system that decides.

[dap711]

maybe a re-learn-wipe data periodically would address the lag as it builds up drab data causation or win rate?

Yes — some form of periodic “relearn” is a legit way to fight drift, but a full wipe is usually the most dangerous version of that idea.

What I'm worried about is real: as data accumulates, the SLM can get “dragged” by older regimes and the model’s edge can decay because the market changes (volatility regimes, liquidity, macro, microstructure, etc.). The fix is not bigger history, it’s better recency handling.

What works better than a full wipe:​

1) Rolling training window (most common, most robust)​

Train only on the most recent N trades or last X days (ex: last 500–2,000 closed trades or last 90–180 trading days).

• Keeps the model aligned to current market behavior
• Prevents “drab data” dominance
• Still has enough sample size to generalize

Rule of thumb: if you don’t have many trades yet, don’t window too tight or you’ll overfit.

2) Exponential decay weighting (best if you want “memory” but not “drag”)​

Keep all data, but give newer outcomes more weight.

• Avoids catastrophic forgetting
• Naturally adapts to drift
• Smooths regime transitions

This is often the sweet spot for systems like Nexus II.

3) Regime-aware training (high win-rate upside)​

Tag trades by simple regime features (ex: VIX band, ATR percentile, trendiness, session type), then either:

• train separate models per regime, or
• include regime features so the model learns different behavior per regime

This directly targets the “why did win rate change?” question.

---

When a wipe makes sense (rare)​

A wipe is useful only when:

• you changed core logic so old labels are no longer comparable (strategy definition changed)
• you had a bug contaminating labels/features (bad P/L, wrong exit price, missing fills)
• the feature schema changed so older data is incompatible

In those cases: wipe the derived SLM dataset, not the authoritative ledger/trade history.

---

Practical “safe” policy I’m using for Nexus II​

• Never wipe ledger/trades.
• Maintain an SLM dataset built from ledger.
• Retrain on:
  • Rolling window: last 180 trading days OR last 2000 trades (whichever is smaller but above a minimum)
  • Decay: half-life around 60–90 trading days
• Trigger retrainwhen:
  • rolling 20-trade win rate drops below threshold, OR
  • drift detected (feature distributions shift), OR
  • every week/month on schedule
• Always run a shadow evaluationbefore promoting new weights:
  • compare “current model” vs “candidate model” on last X trades
  • promote only if it beats by a margin and doesn’t increase drawdown / loss tail

This prevents the system from “thrashing” and protects me from a bad retrain.

 

[dap711]

Todays results:

 

[Adeodatus]

Your data is moving with markets, trades reflected yesterday was tough. Live yet?

Here is what turns orange sometimes, then grey too...
I woulnt be against having this code pythoned & traded in API live

 

[dap711]

Your data is moving with markets, trades reflected yesterday was tough. Live yet?

Here is what turns orange sometimes, then grey too...
I woulnt be against having this code pythoned & traded in API live

Short answer: no — not live yet, and yesterday is exactly the kind of day that justifies that decision.

---

What yesterday actually tells us
A tough day showing up immediately in the data is not lag — it’s responsiveness.
That means:

• The system is tracking the market in near-real time
• Losses are being reflected, not smoothed away
• There’s no artificial stability masking regime stress

If the data didn’t react to a rough tape, that would be the red flag.

---

Why this doesn’t mean “go live now”
Yesterday wasn’t just “a bad trading day” — it was a regime stress test:

• Choppy price action
• Fake breakouts
• Poor continuation
• Option spreads behaving badly intraday

Those days are where systems fail operationally, not strategically.
Before live capital, I want to confirm:

• Were losses strategy-correct or execution-driven?
• Did exits fire exactly as designed?
• Did any symbols go stale or desync?
• Did the ledger reflect reality without reconciliation hacks?
• Did the system behave boringly under stress?

You don’t graduate to live trading because a system makes money on easy days.
You do it because it doesn’t break on hard ones.

 

[dap711]

Will have a new update coming tomorrow.

Todays results:

 

[dap711]

Status Update: Still working on a couple of bugs before releasing the next update. I've got the self-learning AI working and will monitor the results for improvement. Next release should be the final one before adding the ability to trade a live account.

 

[dap711]

Nexus II — Update Summary

1. Root Cause Identified: “Missing P/L” was NOT a streamer failure

• Streaming was working for equities and many options.
• “Blank” P/L rows were caused by stale or never-updated option prices, not missing subscriptions.
• Several OPEN option rows had:
  • entry_price == last_price
  • tm_unrealized_pl IS NULL
  • no new ticks for long periods

---

2. Streamer Health Metrics Fixed

• Eliminated false “stale” readings caused by:
  • epoch 0 timestamps
  • symbols that had not yet received their first tick
• Health logic now distinguishes:
  • fresh
  • stale
  • unknown / warming (no ticks yet)
• Removed misleading multi-billion-second ages at startup.

---

3. Option Stream Failure Mode Confirmed

• Schwab opcode=8 (1000 normal close) during topology changes (OPTION ADD / reconcile) is expected.
• Critical discovery: when options stop ticking, on_tick() never fires → watchdog never runs.
• This is why options could stall indefinitely with no recovery.

---

4. World-Class Quant Fix: Heartbeat-Driven Watchdog

• Added a tick-independent heartbeat thread:
  • Runs every few seconds
  • Checks OPEN options for stale prices
  • Forces REST quote refresh (and optional stream rebuild)
• This makes the system self-healing even when no ticks arrive.

---

5. Positions DB Hygiene & Consistency

• Fixed mixed timestamp formats (epoch int vs ISO-8601).
• Added proper datetime, timezone imports.
• Provided a one-time DB hygiene script to normalize existing rows safely.
• Ensured last_update_ts is always valid UTC ISO.

---

6. Dashboard P/L Reliability Improvements

• Added P/L fallback logic:
  • If tm_unrealized_pl is NULL but entry_price and last_price exist, compute P/L deterministically.
• Prevents “blank” P/L display when data is present but TM hasn’t updated yet.

---

7. Config & Scope Bugs Fixed

• Fixed cfg scoping bug in main.py (UnboundLocalError).
• Ensured watchdog + streamer always read the correct YAML config path.
• Removed unreachable code caused by indentation errors.

 

[IPA]

very cool. i want to check this out. great work.

 

[dap711]

It’s been a few weeks since my last update, so I figured it was time to push out the current version of the system. Previously, everything was driven off OCR reading a watchlist and trading from that.

I’ve now added another way to select tickers by integrating with the movers API. Using a multi-timeframe volume-pressure regime, the system identifies the top gainers or losers and places option trades on the top 10 names.

Trading stocks from NYSE, NASDAQ, or SP500 is now just a YAML config switch, and at this point the system is pretty much set-and-forget.

Be sure to read the "READ ME.TXT" file for more information on the setup.