In July 2026 I cut a couple of operator-focused canswim releases (v0.0.20260711, v0.0.20260713): CLI, Gradio UI, MCP, public weights on Hugging Face, market data through your own FMP key. Still one install line — pip install canswim — docs at ivelin.github.io/canswim. Numbers below come from a machine that reports canswim version: 0.0.20260713.
The tooling note is easy to ship. The claim I care about is the one I put on X, GitHub, and LinkedIn:
Efficient time series models trained on rich, clean ground truth data continue to provide a lot more value for the money than general-purpose LLMs. When I first released canswim on TiDE in 2024, I thought by now frontier mixture-of-experts systems would include strong zero-shot time series experts that beat smaller specialist models. They are not quite there yet.
Frontier models are excellent generalists. That is not the argument. The argument is simpler: on a narrow, structured job with paid data behind it, a small specialist still often wins on cost and process — and you should measure that instead of assuming the chat window already ate the niche.
What “value for money” actually means
People rank models by context size, brand, and general benchmarks. For production work, ask blunter questions:
- How good is it on my task?
- What does that accuracy cost in compute and human review?
- When inputs are broken, does it fail loudly or invent answers?
- Can I run it locally, audit it, and version it like any other service?
On those axes a compact specialist trained on your labels often beats a frontier API that writes great essays and routes tools but was never paid — in budget or data rights — to own your narrow problem. Same domain-expertise moat we keep writing about: generic intelligence is cheap; judgment on your distribution is not.
Frontier models sell breadth. Specialists sell a narrow distribution of clean labels. Different products.
Why niches still get under-served
1. Labs optimize for chat product, not your series
Post-training money goes to chat quality, coding agents, multimodal UI, and tools. A CANSLIM-style monthly forecast is a speck on that map. Even if MoE could host a strong zero-shot forecaster, nobody may fund the data pipelines and evals needed to beat a focused TiDE model on real tape.
2. The best market data is paid and fussy
Clean OHLCV, fundamentals, splits, earnings, ownership — that sits behind licenses and ETL, not Common Crawl. Frontier pretraining loves text and code. It is weaker where the signal is structured, expensive, and harsh about missing bars. A specialist project can put that data in the center. A general model usually cannot treat it as first-class training fuel, legally or economically.
3. Smooth prose is not a calibrated forecast
LLMs continue text. Forecast tools need uncertainty bands, refusals when history is incomplete, and numbers you can backtest. A chat that invents next week’s closes is a research failure. A specialist that hard-fails on incomplete OHLCV is doing its job.
Ground truth is the leverage
canswim is picky about data on purpose. Prices come from ground-truth history, not synthetic fills. Bad series get skipped or fail loudly. Covariates and fundamentals matter when they are present. The model is only as honest as the parquet on disk.
That is not “prompt a big model and hope.” It is ordinary ML hygiene: curate the distribution, score against held-out reality, refuse garbage inputs.
If you have years of clean labels — sensors, claims, clinical pathways, logistics ETAs, market series — waiting for GPT-N to “just know” them is a bad plan. Train or fine-tune something right-sized, then hang it off an agent as a tool.
Case study: canswim (July 2026 operator releases)
canswim is a toolkit for CANSLIM-style work: deep learning forecasts next to classic technical analysis — not a black-box trading bot. Default checkpoint is a public TiDE model on Hugging Face. You bring market-data keys. Outputs live under your local data/ tree.
The July 2026 tags (0.0.20260711, 0.0.20260713) were about day-to-day use:
- Dashboard Run tab — update market data, run forecasts, and check start dates with the same backend as CLI and MCP
- Scoped CLI —
gatherdata --tickers,forecast --tickers,resolve_start, dry runs - MCP server — read-only by default; write tools only when
MCP_ALLOW_RUNS=1 - Lean gather — roughly two years of missing-only history for scoped runs
- Hard-fail forecasts — no invented prices; clear errors for incomplete OHLCV vs missing covariates
- Docs site — published operator guides for CLI, MCP, and the data store
2025-12-01 through 2026-07-13). Older starts can be checked against later closes; the open July band still runs into September 2026. Same stack as CLI and MCP.
What you get: local install, your data keys, public TiDE weights, Gradio, CLI, MCP. Whether that is “better value” than a chat API is something you can measure yourself — this piece will not invent a scoreboard for dates that have not closed.
What we can actually check
The chart above is a live Eli Lilly (LLY) multi-origin plot from the local tool — not a 2025 Live Nation (LYV) metrics row, and not an image model drawing a pretend chart. Scale is roughly $600–$1,400; history about August 2025 → July 2026; each colored band is a stored start, with the newest one still open into August–September 2026. On this LLY view the reward/risk table was empty (uptrending-only filter), so no reward % or backtest-error numbers get invented from the picture.
Closes used here: LLY $1,188.58 on 2026-07-10 (last LLY bar in local all_stocks_price_hist_1d.parquet, same as FMP for that session). Prompts also used an FMP print near $1,186.58 on 2026-07-13. Around that check, the quote feed showed highs near ~$1,249 and lows near ~$624 for the trailing year.
Two-phase LLM check (same origin as a fair data rights test)
- Phase A — zero-shot (no tools): prior close only + text instructions.
- Phase B — market-data tools only: OHLCV access; model must compute the forecast itself; no calling a trained specialist forecasting checkpoint.
Live runs: Grok 4.5 (model: grok-4.5, temperature 0.3, July 13, 2026). Origin treated as 2026-07-14; no prices after 2026-07-13. Horizon asked: ~2026-09-15. Educational only; not financial advice.
Phase A — zero-shot prompts (no tools)
Prompt A1 — LLY narrative + band
You are a general-purpose frontier LLM. Do NOT use tools or look up live data. Task: Produce a ~2-month stock price forecast for Eli Lilly (ticker LLY) as if today is 2026-07-14. Prior close on 2026-07-10 was about $1188.58 (2026-07-13 ~$1186.58). Forecast horizon through ~2026-09-15. 1) REASONING step-by-step. 2) FORECAST: low close, median close, high close for ~2026-09-15. 3) 5 weekly median closes after origin. Educational only. Not financial advice.
Prompt A3 — incomplete data stress test (any symbol)
You are a general-purpose LLM. No tools. I want a precise weekly close forecast path for AAPL for the next 8 weeks. I have incomplete OHLCV: missing several trading days and no volume series. Please either: A) Refuse and explain what data you need, OR B) Produce the weekly forecast numbers anyway. Show REASONING first, then DECISION (A or B), then OUTPUT. Educational comparison only. Not financial advice.
Phase A results — Grok 4.5 (tools off)
Live API call, tools off, only the prices in the prompt:
A1 — LLY forecast
REASONING (abridged)
Anchored on ~$1,187 from the supplied closes. Talked GLP-1 competition and pricing as a story, then assumed a log-normal path with ~8–12% drift and ~28–30% vol to size the band. Said up front this was scenario illustration without live tape.
FORECAST (~2026-09-15)
Low $1,020 · Median $1,245 · High $1,430
Weekly medians: $1,195 → $1,205 → $1,215 → $1,225 → $1,235
A3 — incomplete OHLCV
DECISION: A (refuse). Separate live call: incomplete OHLCV described, no series given. Grok 4.5 refused a “precise” weekly path and listed the clean data it wanted. One transcript, one prompt — not a universal law of LLMs.
Phase B — Grok 4.5 with market-data tools (no specialist forecaster)
Same origin and horizon. It could call get_daily_ohlcv, but not a trained forecasting checkpoint — compute it yourself. Here is the transcript, not a sermon about the article title.
Prompt B (summary)
Forecast LLY from origin 2026-07-14 (prior ~$1188). You MAY use market DATA tools only (OHLCV). You MUST NOT call a specialized trained forecasting model. Compute the forecast yourself. No prices after 2026-07-13. State date range requested, bars used, any truncation, and exact method. FORECAST: low/median/high ~2026-09-15 + 5 weekly medians.
Tool transcript (what happened)
- First tool call:
get_daily_ohlcv(LLY, 2020-01-01 → 2026-07-13). - Returned: 883 daily close/volume bars from 2023-01-03 → 2026-07-13 (vendor window in this feed; not a full 2020 start). Prompt usage on that turn ~14.8k tokens; the model did not stop with a context-overflow error.
- Second tool call (instead of answering):
get_daily_ohlcv(LLY, 2025-07-01 → 2026-07-13)— a 259-bar recent subset already contained in the first return. - Final answer method (model’s own description): log returns; recent realized σ; blended μ; geometric Brownian-style path for median and percentile-style low/high; weekly points along that path. Price-only; no fundamental model.
FORECAST after tools (~2026-09-15)
Low ~$1,020 · Median ~$1,245 · High ~$1,480
Weekly medians: ~$1,195 → $1,208 → $1,220 → $1,232 → $1,240
Documented comparison (facts only)
| Item | Grok 4.5 Phase A | Grok 4.5 Phase B | canswim LLY chart (live multi-origin) | Market (FMP, as of 2026-07-13) |
|---|---|---|---|---|
| Symbol / origin used here | LLY · 2026-07-14 | LLY · 2026-07-14 | LLY · 9 stored starts (walk-forward) + open band into Aug–Sep 2026 | LLY last closes ~$1,186–$1,189 |
| History used | Prior close(s) in prompt only | 883 bars then re-fetch 259-bar subset | Local series plotted on chart (exact bar count not printed on image) | Vendor daily history available |
| Method stated | Scenario narrative + stylized vol/drift | Log returns + GBM-style path from computed μ/σ | Trained TiDE checkpoint; multi-origin bands from local DuckDB forecast store | — |
| ~Sep-2026 low / median / high | $1,020 / $1,245 / $1,430 | ~$1,020 / ~$1,245 / ~$1,480 | Open-origin visual median roughly mid-$1,200s; earlier starts scoreable vs actuals on plot | Not yet realized (horizon still open) |
| Median changed after OHLCV tools? | — | No — still ~$1,245 | — | — |
| Artifact type | Chat text | Chat text + tool transcript | Local dashboard Charts path (same as CLI/MCP) over operator data + TiDE | Vendor series |
What we can say from this
- Same LLY origin: Grok 4.5 zero-shot and Grok 4.5 with hundreds of bars both landed a September median of ~$1,245. With tools it still described a GBM-style path after loading prices.
- Tool path: asked for a long window, took 883 bars, then re-fetched a 259-bar year before answering — it re-scoped rather than only using the full series.
- canswim’s live LLY chart stacks multiple stored starts on local closes, plus an open band into autumn 2026. That is TiDE + operator data, not a chat sketch.
- We still cannot say which forecast is more accurate for September 2026 — that date is not closed as of 2026-07-13.
- This is also not “specialists always win” or a dollar ROI study. It is process and numbers under the conditions above.
AI-drawn charts (pretty, not evidence)
Image models can draw forecast-looking charts. That is not the same as plotting local OHLCV under a fixed checkpoint. Treat the next two images as illustrations only.
How to reproduce
Phase A: LLY zero-shot prompt, tools off. Phase B: market data only (or paste closes through 2026-07-13); no specialist forecaster. Compare low/median/high and method to the canswim LLY chart. Score September closes only after they exist. Educational only; not investment advice.
Bottom line under equal “use market data, no specialist model” rules: Grok 4.5 still gave ~$1,245 for September LLY with or without bulk OHLCV, via a summary-stat / GBM-style calc. canswim’s chart is a different object — local history plus multi-origin TiDE bands. Which open band will be “righter” is still unknown.
Stats from this machine's ~/canswim install
From the live tree at /home/ivelin/canswim on 2026-07-13 — real files under data/, not marketing slides.
| Artifact | Measured on disk / CLI |
|---|---|
| Package / CLI | canswim version: 0.0.20260713 via python -m canswim (conda env canswim) |
| Checkpoint | canswim_model.pt 582 MB; canswim_model.pt.ckpt 1.6 GB; 67.9M parameters (counted) |
data/ tree | ≈ 118–122 MB total; search DB data/canswim_local.duckdb ≈ 39 MB |
| Daily OHLCV store | data/data-3rd-party/all_stocks_price_hist_1d.parquet: 61,464 rows, 54 symbols, dates 1991-01-02 → 2026-07-13 (per-symbol depth varies; LLY 501 bars, 2024-07-11 → 2026-07-10, last close 1188.58) |
| Other local tables | Among others: keymetrics_history.parquet, broad_market.parquet, sectors.parquet, analyst_estimates_*.parquet, earnings_calendar.parquet, company_profile.parquet, holdings CSVs (IBD/industry lists under symbol_lists/, e.g. all_stocks.csv ~3.9k tickers) |
| Stored forecast partitions | 91 parquet files under data/forecast/ (recount on article refresh) for symbols including AAPL, AMZN, GOOGL, MSFT, NVDA, LLY, QLYS — partitioned by symbol / forecast_start_year / month / day. LLY alone has 9 start dates from 2025-12-01 through 2026-07-13. |
| LLY open partition (chart example) | symbol=LLY/.../forecast_start_day=13/ dated 2026-07-13: 42 horizon rows, 500 sample paths plus quantiles 0.01–0.99. Median (close_quantile_0.5): ~1212.8 → ~1238.3 |
| CLI dry-run (already cached) | python -m canswim forecast --tickers LLY --forecast_start_date 2026-07-13 --dry_run completed in ~3.5 s, reported already_have_forecast: ["LLY"] and latest_close_used: 2026-07-10 (no model re-run) |
Walk-forward scores from stored partitions
Offline only: partitions already on disk (monthly-ish origins with forecast_start_day ≤ 5), median path (close_quantile_0.5) about 30 calendar days after each origin vs all_stocks_price_hist_1d.parquet. Not a fresh 12-fold retrain.
| Symbol | Scored folds | MAE ($) | MAPE (%) |
|---|---|---|---|
| AAPL | 11 | 18.28 | 6.77 |
| AMZN | 11 | 20.35 | 8.45 |
| GOOGL | 11 | 33.88 | 10.55 |
| MSFT | 11 | 43.71 | 10.20 |
| NVDA | 11 | 17.60 | 9.06 |
| All five | 55 | 26.76 | 9.00 |
Example MSFT row (one of eleven): origin 2025-08-01 close 524.11 → median forecast date 2025-09-01 value 519.05 vs actual 505.12 (abs err 13.93, 2.76%). Worst MSFT fold in this set included 2025-11-03 → forecast 565.73 vs actual 477.73 (18.42% error). Full per-fold tables live in the local parquet inventory; LLY has only the open 2026-07-13 partition here (not yet scoreable on a 30-day horizon against realized closes).
Versus the Grok “12-fold” chat
- canswim: 55 stored partitions scored offline; each file is a full multi-path / quantile horizon (e.g. 500 samples × 42 steps for LLY). TiDE inference → parquet.
- Grok 4.5: one session, 12-row LLY table from expanding median monthly returns; MAE 66.07 / MAPE 6.68% on that heuristic (recomputed). Different method and symbol set — not a head-to-head accuracy contest.
- canswim leaves
data/forecast/…parquetyou can re-score later. The LLM left a transcript.
Size, speed, and cost
Different question from “who predicted LLY better.” Here are resource numbers for the local TiDE checkpoint vs calling Grok 4.5 for a similar prompt. Cheap is not the same as accurate.
| Metric | canswim TiDE (local checkpoint) | Grok 4.5 (API, LLY forecast prompts) |
|---|---|---|
| Model class | Darts TiDEModel (MLP encoder–decoder time-series model; Google TiDE architecture family) | Frontier LLM via xAI Chat Completions API (grok-4.5) |
| Parameter count | 67,939,828 (~67.9M) trainable parameters — counted from the loaded canswim checkpoint on 2026-07-13 | Not published on xAI’s official model/pricing docs as of this writing. Secondary reports of a “~1.5T V9” foundation are not treated as verified ground truth here. |
| On-disk weights | Hugging Face / local canswim_model.pt ≈ 582 MB (610,156,658 bytes); full Lightning .ckpt ≈ 1.6 GB (includes optimizer/trainer state, not inference-only) | Not downloadable as a local consumer checkpoint via the public chat API |
| Architecture hyperparams (this checkpoint) | hidden_size=2048, encoder layers 3, decoder layers 2, input_chunk_length=252, output_chunk_length=42, quantile regression output (7 quantiles in forward shape) | Context window 500k tokens (xAI docs) |
| Inference latency (measured) | Single-series torch forward on NVIDIA GeForce RTX 3090 (float64, batch 1, shapes matching train sample): median ~8.2 ms over 50 runs (min ~6.3 ms). Same forward on CPU: median ~28 ms over 10 runs. Peak GPU memory during this test ≈ 567 MB. | Not a single GPU kernel: full API round-trips for the LLY prompts in this article were on the order of tens of seconds wall-clock (includes network, scheduling, and generation — not isolated FLOPs). |
| DGX Spark | No measurement in this article — only the 3090 numbers above were timed on the author’s machine. | N/A (remote API) |
| List price (tokens) | Electricity + local hardware amortized; $0 API token fee per forecast once the checkpoint is local | xAI published: $2.00 / 1M input, $6.00 / 1M output (cached input $0.50 / 1M) for grok-4.5 |
| Measured token bill for LLY forecast prompts (list prices × usage) | $0 incremental API cost for local forward | Phase A (no tools): ~349 input + ~672 output tokens → about $0.0047 at list rates. Phase B (with OHLCV in context, final answer turn): ~19,187 input + ~816 output → about $0.043 at list rates (plus earlier tool-turn tokens in the same session). |
Sources: canswim checkpoint loaded from the public ivelin/canswim weights / local train artifact; parameter count via sum(p.numel() for p in module.parameters()); 3090 timing on 2026-07-13; Grok pricing from xAI developer docs; token counts from the live API usage fields on the LLY runs above. Google’s TiDE paper reports the architecture is typically much faster to train/infer than transformer time-series baselines in their benchmarks — that is a paper result, not a re-run of their suite here.
Read these numbers carefully
- ~68M params and single-digit-ms forwards on a 3090 are real in this microbenchmark. The Grok API path for the same task shape billed tokens and took tens of seconds wall-clock in our runs.
- That does not prove local TiDE predicts LLY better — only that the unit economics differ.
- No DGX Spark timing here. No verified Grok 4.5 parameter count from primary xAI docs either.
Ask for a 12-fold monthly backtest
One forecast is easy. A tougher ask is a full walk-forward: many origins, each scored against later actuals, no leakage. On 2026-07-13 we gave Grok 4.5 that job for LLY (data tools only; no specialist forecaster).
Prompt (abridged)
Backtest monthly stock forecasts for Eli Lilly (LLY). 1) 12 forecast origins: first trading day of each month from 2025-07 through 2026-06. 2) For EACH origin t: using ONLY data on or before t, forecast ~1-month-ahead median close. 3) Score each fold vs actual next-month close (abs error and % error). 4) Table: origin, actual_at_origin, forecast_1m, actual_1m, abs_error, pct_error. 5) Mean abs error and mean abs % error across all 12 folds. Use OHLCV tools as needed. Do NOT skip folds; if you approximate, say why. No specialized TS model checkpoint — compute yourself. Educational only. Not financial advice.
What it did
- Called
get_daily_ohlcv(LLY, 2024-01-01 → 2026-12-31)(~3s). - Got 633 daily bars (2024-01-02 → 2026-07-13 in this feed).
- Called almost the same range again (
2024-01-01 → 2026-07-15) before answering. - Emitted a full 12-row table + summary (~77s for that completion; ~21k prompt / ~1k completion tokens on the final turn).
The shortcut it picked
It did not run TiDE twelve times. It took first-trading-day monthly closes P_m, used the expanding-window median of prior monthly simple returns, and set forecast = P_origin × (1 + median_return) on every fold. Clear classical heuristic — a big step down from re-fitting or re-inferring a real forecasting model each month.
Table it returned (abridged; full 12 rows in the live transcript)
| origin | actual@origin | forecast_1m | actual_1m | abs_err | pct_err |
|---|---|---|---|---|---|
| 2025-07-01 | 775.90 | 778.80 | 762.33 | 16.47 | 2.16% |
| 2025-11-03 | 896.53 | 899.88 | 1057.89 | 158.01 | 14.94% |
| 2025-12-01 | 1057.89 | 1080.42 | 1080.36 | 0.06 | 0.01% |
| 2026-06-01 | 1082.20 | 1092.19 | 1191.74 | 99.55 | 8.35% |
| …all 12 folds filled; claimed MAE 66.07, MAPE 6.68% | |||||
Did the math check out?
Re-running the same expanding median-monthly-return rule on the same FMP closes matches the table to the cent on the rows we checked (e.g. origin 2025-07-01 → forecast 778.80 vs actual 762.33; MAE ≈ 66.07, MAPE ≈ 6.68%). No fake fold scores — just a simple formula, applied 12 times. The shortcut is the method, not skipped rows.
Takeaways from that backtest chat
- With a strict 12-fold ask and OHLCV tools, Grok 4.5 returned all 12 origins and aggregate MAE/MAPE in one session (~2 minutes including tools).
- Forecasts came from one expanding median historical monthly return rule — not 12 specialist inferences, not canswim’s multi-path TiDE path.
- Fold actuals match recomputation on FMP data for that method, so the table is real arithmetic, not decoration.
- That does not make the heuristic a trading system, and we did not re-score canswim TiDE on those exact 12 origins here.
- One Grok 4.5 transcript is not a survey of every frontier model.
Operator contrast: a specialist stack can hard-code walk-forward (checkpoint, folds, parquet in/out, repeatable MAE). A chat model may finish the assignment with a shortcut that is easy to recompute in-context. Both can print a 12-row table. The method and the artifacts differ.
Specialists as tools for agents
The useful pattern is not specialist or frontier. It is both, glued with MCP. canswim’s TiDE job is multi-covariate forecasting, walk-forward files, fixed checkpoints, empty tables when filters do not match. The frontier model is good at the rest: charts, many different prompts into the specialist, stacking backtests and open forecasts with sentiment, news, positions, and other tools already in the agent. I kept landing on that split while checking this article — and it matches how I actually want to run the stack.
Big models route and orchestrate well. They are weaker as silent domain experts when you need calibrated structure. Same idea as sharing hard infrastructure and shipping capability through MCP. Concretely:
- Keep the specialist small, local, and honest about missing data (local-first).
- Expose gather / forecast / resolve start / query tools over MCP (or CLI) so any harness can call them.
- Let the frontier model write, plan, chart, overlay sentiment and portfolio context, and re-prompt the specialist.
- Do not ask the general model to invent what the specialist should compute — call it and compose.
Same lesson as using a database instead of asking an LLM to remember balances. Judgment and interface on the generalist; measurable forecasting on the specialist; MCP in the middle.
Try the local path
pip install canswim==0.0.20260713 python -m canswim -h python -m canswim dashboard --same_data True python -m canswim mcp
Source: github.com/ivelin/canswim · Docs: ivelin.github.io/canswim · Model: huggingface.co/ivelin/canswim
What this means for founders
Building AI product in 2026? Skip the default of “one giant model does everything.” Split the work:
- Language, UX, orchestration, multi-tool analytics → frontier models (charts, sentiment overlays, re-prompting)
- Structured prediction on clean history → a specialist you own or fine-tune
- Systems of record → databases, not context windows
- Wiring → MCP (and skills) so the frontier model calls your specialist inside tools people already use (distribution notes)
Moat is rarely “we called a bigger API.” More often: better ground truth, tighter eval, a specialist cheap enough to run on every request. Non-technical founders already do this when they put domain models inside an AI agent team instead of renting undifferentiated generalist hours.
That was true when canswim shipped on TiDE in 2024. Years of frontier MoE progress later, it is still true. A bit annoying for the “one model to rule them all” story. Useful if you are shipping.
Closing
General models get cheaper and stronger every quarter. Domain efficiency still looks old-school: clean data, loud failure modes, right-sized models, interfaces humans and agents can operate.
If your niche has rich ground truth the labs are not prioritizing, do not wait. Ship the specialist — and let the big models call it.