QuantDinger Jev Filter Backtest: 0 of 1,324
Part 7 of 7 · Jev in trading, tested
Does QuantDinger's Jev filter help? In my replay it never got the chance. With the
platform's default settings, Jev's answers didn't clear the confidence bar once in 1,324
requests, so every trade went through exactly as if the filter were off. When I removed
the thresholds and let Jev's own answers decide, it did no better than blocking trades at
random.
Why I ran this
In part 4 I read QuantDinger's Jev gate and ended on a
complaint: it only runs on live strategies, so nobody can backtest it. That wasn't quite
true. The gate only needs a JSON state and six answers from Jev, and the
Polymarket memory test showed Jev doesn't recall how
past events turned out. So I rebuilt the state for every historical signal, asked Jev, and
applied QuantDinger's own rule to the answers.
How I rebuilt the gate
I didn't retype anything I could import. From QuantDinger at commit 96cec2d:
| Piece | Where it came from |
|---|---|
| The six questions and their choices | parsed straight out of ai_decision_filter.py |
| RSI, MACD, ATR, moving averages, support/resistance | QuantDinger's own technical_indicators.py, imported |
| Order budget | their order_budget.py, imported |
| The state sent to Jev | a line-by-line copy of ai_decision_context.py; the only change is that "now" is the signal's time, not today |
| Answer checks and the pass rule | a line-by-line copy of _evaluate_jev() |
The request body is the same one the platform sends (model, state, questions) to the
same endpoint, with jev-latest, which answered as jev-1.14.0.
The strategy is QuantDinger's official example, strategy_v2_dual_ema_long.py: on every
bar close, if the 20-bar average is above the 50-bar average, hold 95% of equity; if not,
hold nothing; 5% stop loss. While it's flat in an uptrend it asks to enter on every bar, so
a rejected entry gets asked again an hour later. Exits never go through the gate, same as
the platform.
| Data | Period | Trades without the gate | Return | Max drawdown | |
|---|---|---|---|---|---|
| BTC 1h | Exness BTCUSD ticks, shown to Jev as BTC/USDT |
30 Apr 2024 – 11 Oct 2026 | 246 | −20.7% | −53.3% |
| Gold 1h | Exness XAUUSD ticks | 17 Jun 2020 – 5 Oct 2026 | 416 | +96.2% | −19.0% |
Buys fill at the next bar's open plus the real spread, with 0.05% fees per side on BTC and
0.01% on gold. One losing strategy and one winning one, on purpose: a useful filter should
cut the first's losses without wrecking the second.
Before running the gated version I wrote down what would count as "the filter helps": beat
the unfiltered return and beat at least 95% of random gates that block the same share
of requests.
What happens with QuantDinger's defaults?
Nothing. The filter never makes a decision.
QuantDinger only trusts Jev's answer when three of the six questions (entry_decision,
risk_check, execution_quality) each come back with a confidence of 0.55 or more.
Below that it treats Jev as failed and hands the decision to an ordinary LLM. With no LLM
configured, the trade goes through.
For the 1,324 trades in the chart below (both markets, at two position sizes), all three
cleared 0.55 zero times, and execution_quality never went above 0.49. Across every
response I collected for this post, 41,693 of them, all three never cleared together once.

Part of this is how the API answers. Jev returns a probability for each choice and a
separate confidence field, and they're not the same number. On one BTC entry it chose
pass with probability 0.60 and confidence 0.20. QuantDinger reads confidence.
So in this replay the filter changed nothing: the same 246 BTC trades at −20.7%, the
same 416 gold trades at +96.2%. If you've switched it on without an LLM, my numbers say it
isn't filtering. If you have an LLM configured, that LLM is the one making the calls, not
Jev. You pay one credit per check either way.
What does Jev actually think?
To see Jev's own opinion, I took the thresholds out and applied the rule to its chosen
answers. That's not how QuantDinger behaves; it's the most generous reading of Jev.
It blocked almost everything: 99.85% of entry requests on BTC (10,396 asked) and 99.69% on
gold (17,512 asked). The reason was nearly always risk_check = block, on 232 of 246 BTC
entries. Jev objects to putting 95% of equity into one position, which is a fair point
about QuantDinger's own example, but it's a point about sizing, not about the market.
Blocking that much changes the results, so the test is whether Jev picked which trades
to keep better than chance. I ran 1,000 random gates that block the same share of
requests:
| No filter | Jev decides | Random gates, median (5th–95th pct) | Random gates as good or better | |
|---|---|---|---|---|
| BTC 1h | −20.7%, 246 trades | −9.1%, 16 trades, PF 0.55 | −1.6% (−14.7% to +20.2%) | 80% |
| Gold 1h | +96.2%, 416 trades | +4.3%, 55 trades, PF 1.17 | +4.0% (−10.7% to +21.9%) | 48% |

On BTC, Jev lost less than the unfiltered strategy only because it was hardly ever in the
market, and most coin flips did that better. On gold it threw away almost all of a +96%
run and landed right on the random median. Neither result meets the bar I set beforehand.
With a smaller position, can it tell good trades from bad?
The sizing objection was drowning everything else out, so I cut the position to 10% of
equity and asked Jev about every trade of the unfiltered strategy once. Now it blocks about
one entry in five, mostly for signal_conflict, which is the market reading I actually
wanted to test.
| 10% size | Trades passed | Trades blocked | Passed minus blocked, avg per trade (95% CI) | AUC of P(pass) vs winning trade |
|---|---|---|---|---|
| BTC 1h | 197, avg −0.04% | 49, avg −0.07% | +0.02 pts (−0.72 to +0.79) | 0.50 |
| Gold 1h | 329, avg +0.20% | 87, avg +0.11% | +0.09 pts (−0.25 to +0.41) | 0.53 |

The trades it blocked weren't worse than the ones it let through. Every interval crosses
zero, and an AUC of 0.50–0.53 is a coin flip. I'd set 0.55 in advance as the minimum to say
Jev separates good entries from bad. It didn't get there, and its market answers
(aligned, conflict, favorable, adverse) stayed between 0.47 and 0.55.
That matches part 5, where Jev read clean indicators
accurately but couldn't say where Bitcoin was going next.
What would I do with this?
If you run QuantDinger: don't treat the Jev filter as a safety layer. With the defaults
it's off in practice, and with the thresholds removed it's a coin flip that mostly says no.
The parts of the platform I'd keep relying on are the plain-code ones from
part 2: the order budget and the rule that exits never wait on an AI.
And for any AI gate, mine included: replay it before it touches money. This whole test cost
about $5 in Jev credits.
What I didn't check
- The LLM fallback. With an LLM configured, every decision in this replay would have
gone to it. I didn't test any LLM. - One strategy. It's QuantDinger's own example, on two markets, 1h only. A strategy with
smaller positions and different signals could get different answers. - The 10% size as a live gate. I asked about each 10% trade once, but the bar-by-bar
run at 10% stopped when my Jev credits ran out. - Dates in the state. QuantDinger sends bar timestamps, so Jev could see the date. The
Polymarket test found no memory of outcomes, but I didn't test memory of price paths. - Data details. Volume is Exness tick count, not exchange volume. Only completed bars go
into the state; the live platform may include the forming bar. No swap on gold. - Versions. QuantDinger at commit
96cec2d, Jev 1.14.0 in early November 2026. The
hosted version may be configured differently, and either side may change.
In this replay, QuantDinger's Jev filter either did nothing or did no better than chance.
Comments
No comments yet. Questions about the settings, the data or the numbers are welcome.
Log in or create a free account to comment.