Built for my own use first: the quant system I am building

The [fusion post](/blog/two-domains-one-map) ended on a loose thread: "the admin-side quant project is being considered for standalone personal use." Here is the answer: it goes standalone, as a research direction, self-use first. This is part one of a three-part series on what I am building, why, and why I am in no rush to make it a product.

Where it started

The turning point was the JEV decision model entering my stack. It turned "can a model make decisions" into a statement of fact — and left a more expensive question behind: can the deciding model be my own? A hosted decision model means per-call pricing, quotas and rate limits, and my strategy logic and position data passing through someone else's servers. So the research direction is sharp: self-hosted, open-weight alternatives to hosted decision models — take the decision layer back with free GPU capacity, then build a personal quant system on top.

Not a gambling machine

Most "AI quant" stories are black-box prediction: feed candles into a model, wait for the money code. What I am building is the opposite. One sentence: an auditable, evolvable, limitedly-adaptive quant operating system — not a prediction slot machine. Three layers:

The deterministic quant engine owns all computation and risk — backtests, stops, position sizing, max-drawdown constraints. No models in this layer, just deterministic code, because it must be reproducible and auditable. The dual-model layer owns context — a cloud LLM reads macro reports and news sentiment and distills them into a few lines of Market Context; the self-hosted decision model makes structured decisions and outputs signals with confidence. Decision Memory is the third layer and, I would argue, the actual asset: whether or not a trade happens, log one row a day — [time | market state | macro events | strategy version | AI call | actual outcome | PnL | correct?]. The longer the system runs, the thicker this experience base gets; Strategy Health and AI Confidence are both computed from it.

Strategies decay and single factors fade — that is not a risk, it is weather. Code is not the asset. The asset is the meta-logic: how to detect a dying strategy, how to let the system propose a new version, how to validate it out-of-sample. Decision Memory is the data foundation of that meta-logic.

Why self-use first

Three reasons. One: validation needs real money, not big money — a few hundred dollars of micro-capital is enough to run the whole chain (data → strategy → model routing → execution → memory) and expose the things only real orders expose: slippage, API latency, whether the stops actually fire. Two: the core data stays mine — every live PnL row and AI decision log is track record, and there is no reason to publish it before the system has earned it. Three: business models come later. Maybe a starter kit or a paid research note on Ko-fi eventually covers the server bill, but that would be a result, not a goal.

How the two engines split

Cloud general LLMs (OpenAI / DeepSeek / Claude): generalization, report summaries, natural-language interaction, sentiment scoring — no local GPU, strong text, pay per call. Self-hosted decision model (open-weight, fine-tuned for financial decisions, on local or free GPU instances): compute-heavy batch factor cleaning, strategy-logic generation, universe screening, sensitive trading logic — zero token cost, no data leaving the box. Between them sits a router with three modes (cloud-only / local-only / hybrid). In hybrid mode the local model does roughly 80% of the coarse filtering and feature building, and the cloud model only refines the final decision — which cuts API cost by 70%+.

Markets: EU/US first — crypto plus US stocks, where free data sources are stable and the APIs do not fight you.

Next post is the practical one: how to run both sides — data and model compute — on a zero budget. CCXT, yfinance, and tiered routing across free LLM quotas with failover.