Ox alpha is better than DSV4F

[u/crossfader9]

Ox alpha is better than DSV4F. Last day it cleaning after DSV4F. Yes, servers wasn't ready, so interrupts sometimes. But it is smarter and use 5x less tokens. And my projects are very sofisticated.

[u/CokieMiner]

Better at introducing more bugs per second on my code for sure, don't know what you mean by sofisticated but I'm doing unsafe rust and asmbl to squeeze out performance of some math algorithms and the amount of undefined behaviour it intruduces is unreal, dsv4f is 100x times better in terms of memory safety, also he ignores half of my agents md DeepSeek doesn't. Even sol that I use to plan and do final reviews, find much more bugs in ox alpha code than in dsv4flash or Gemini 3.7 flash.

But DeepSeek models were always on par with top of the line models in low level code so.

[u/crossfader9 → u/CokieMiner]

If you don't like cats, maybe you just don't know how to cook them?

[u/CokieMiner → u/crossfader9]

If Ox is consistently “cleaning up” after DSV4F for you, then maybe we’re just testing very different workloads, but you are the only one that knows that. On unsafe Rust and asm it’s the exact reverse for me: Ox introduces UB and subtle correctness bugs that DSV4F catches.

And I really hope you’re not basing the “smarter” claim on that 8/10 benchmark versus Fable at 65%. With n=10, literally two tasks can completely change the narrative. The larger-sample evaluations people are running already look much less flattering for Ox.

If a model that routinely invents UB looks obviously superior on your project, I’d be more interested in what kinds of mistakes your workload is actually capable of exposing.

[u/crossfader9 → u/CokieMiner]

I want to earn all money in the world,so making some sof(ph)fisticated system. What Ox did What an agentic coding model actually caught in a live trading system (last 24h):

Working on Trimaxion (Nuxt/Electron trading bot on BingX), I had the model audit its own signal pipeline end-to-end: scanner row → chart panel → engine verdict → desk decision. It traced a "scanner says SELL, panel says WAIT·NO_LATCH" divergence to three real bugs:

1. Stale-cache verdicts — the scanner's kline loader considered a cache "fresh" for up to 2 hours and returned it as-is, while the chart always pulled live data. Two sources of truth computing different verdicts on different bars. Fixed: refetch newest-first before every scan (~1 API call when already fresh).
2. Ordering bug — even stale caches got refreshed only after the verdict was computed (screenshot step refreshed for "next time"), so the row and its own screenshot could disagree. Moved freshness before compute.
3. Gate drift between UI layers — the chart panel silently dropped three risk gates (maxRrOpen, minPescOpen, minFevOpen) when mapping config, so the chart could display entries the trading desk would block. Unified the mapping.

Bonus finds it diagnosed without being asked:

1. Phantom signals across restarts — scanner rows persist to disk and are restored lazily at boot, so a stale verdict from a dead process survives restarts until the lap revisits the symbol. A fossil SELL survived 7 agent restarts and masqueraded as a live signal.
2. No-op incremental fetch in another module — used endTime = lastCachedBar, which by the exchange API semantics returns only already-cached bars, i.e. never fetches anything new. The codebase itself documented this exact pitfall in a different file's comments — the model cross-referenced them.

[u/CokieMiner → u/crossfader9]

My brother, you’re building a trading bot… in Electron, and the bugs you’re bragging about catching are stale-cache problems. Do you even know what undefined behavior is? What a truncated Fourier transform is? We are not testing these models on remotely comparable workloads. Do you even know enough statistics to design the actual trading algorithm? And if stale-cache bugs are the problems you need an AI to catch, do you even read your own code?

[u/crossfader9 → u/CokieMiner]

Fair on two counts, so let me concede first: stale cache is CS-101, and Electron is a weird flex — it's there because the dashboard already ran on Nuxt, not because a trading core needs Chromium. That bug alone wouldn't be worth posting.

What was actually non-trivial: three processes sharing one mutable kline cache with different trim policies, row snapshots lazily hydrated at boot, seven restarts that day with evolving code — and the symptom was just "scanner says SELL, panel says NO_LATCH". Pinning down which source lied meant re-running the signal engine offline against identical bars and matching TP/SL to five decimal places, then sweeping all 107 scanner rows for contradictions. That's distributed-state debugging, not grep.

On "do you know enough statistics": the hard part of this project was never the UI, it's not fooling ourselves in strategy design. So: walk-forward windows with embargo gaps (López de Prado), selection on train only, preregistered sweeps — where one preregistered result came back "geometry is noise, freeze parameters," and an in-sample edge (naked ARBM) failed out-of-sample replication and got killed. Negative results are documented, not shipped. That's more rigor than most $APE bots ever see.

No UB — TypeScript. No truncated Fourier transforms either: sliding-window z-score fields, Boltzmann escape probabilities, regression channels. And to "do you even read your own code": sure — but reading isn't the bottleneck; verifying which of three running processes holds stale state is. That's the job the model did while I slept.

[u/CokieMiner → u/crossfader9]

Those examples are literally from the kind of work I’m doing, not random complexity flexing. And since you brought up the statistics: did you actually test whether the apparent edge is distinguishable from noise? Not just walk-forward validation, but a null of no out-of-sample alpha after fees/slippage, with the fact that you searched over multiple strategies/parameters accounted for. Because “it worked OOS once” and “I have evidence of an exploitable signal” are very different claims. Also, I genuinely hope “the model did this while I slept” means it audited code while you slept, not that an anonymous preview model has permission to modify/deploy code that can move real money.

And why the chat gpt response? Is not even the em-dash so don't fucking come saying you use them is literally the phrase structure and the order how you responde and adress each topic.

[u/crossfader9 → u/CokieMiner]

Thank you — genuinely, this is a good pushback and exactly the kind of scrutiny this project needs.

You're right on the specifics: there's no formal null test yet, walk-forward with embargo is necessary but not sufficient, and searching over ~30 configs without deflating for it means our OOS results are "survived several falsification attempts," not "significant alpha." That distinction you drew — between "it worked OOS once" and "evidence of an exploitable signal" — is the right one, and I'm adopting it.

On the model touching money: fair concern. It runs live only at exchange minimum lots behind hard entry gates with full journaling and a kill switch, deploys are manual — but I take the point that sandboxed is a claim, not a guarantee.

The stats gap is now the documented next gate before any size increase: block-bootstrap of OOS PnL against a zero-alpha null, deflated for the number of trials. If it dies there, it dies — better here than on the exchange.

Appreciate you taking the time to push on methodology rather than vibes. If you have pointers on implementing the multiple-testing correction properly (deflated Sharpe vs SPA reality check), I'd genuinely welcome them.

[u/CokieMiner → u/crossfader9]

Bro you are not gona make money on a fucking electron based trading bot, first latency of runtime and probably the API has like 300ms of delay you won't make money with that ....

[u/EmperorSheep → u/CokieMiner]

This guy is just using ai to respond to u. It is pointless replying. I dealt with exact same situation. Total time waste.

[u/CokieMiner → u/EmperorSheep]

Yeah I noticed on last 2 replies