<- all tokdocs
2026.10.02@ray_fu

The Jev Dashboard In This Video Reports 1.50 Seconds While The Voiceover Claims Under 100 Milliseconds

AI
Watch on TikTok

View on TikTok ->

A 49-second 1080x1920 vertical clip posted 2026-10-02 at 23:37 UTC by @ray_fu (channel "Ray Fu"), carrying 3,662 views, 229 likes, 47 comments, 34 reposts and 197 saves at capture, over an original sound credited to will kim. Across 25 extracted frames and a 201-word transcript, the video runs a three-step build: a feed.py panel streaming BTC-USD 1m candles at 48,382 ticks/s against a 64,702.3 USD last price with an order-book-depth ribbon and three tiles (Buyer demand, Order depth, Price gaps); a market_snapshot JSON blob reading {"pair": "BTC-USD", "as_of": "14:32:07Z", "buyer_demand": {"buy_share": 0.63, "trend": "rising"}, "order_depth": {"bids_1pct": 412.8, "asks_1pct": 298.1}, "price_gaps": {"spread_bps": 1.4, "vs_venue_bps": 3.2}} metered at 186 / 8,000 tokens; a Jev console with a "Recommended" model row and three questions (YES/NO "Is the incoming buy flow informed?", CHOICE "Which flow type is this?", SCORE "How strong is the directional pressure?") returning 87% Yes, informed 81% / noise 12% / hedging 5% / spoof 2%, under a header reading "Real Jev output · 1.50 s"; a flow.ts snippet importing from "@typesafe/sdk"; a quote_engine.py market-making loop with the Avellaneda-Stoikov spread card, a 5/5 ACCOUNT LIMITS checklist (position ≤ ±4 lots, order notional ≤ $50k, $375k buying power free, fat-finger band ±1%, message rate ≤ 20/s) and a cycle log reading "Cycle 4: cancelled 2, posted 2 · bid 184.41 / ask 184.68"; and a calibration monitor showing Jev r = 0.99 against Pref. r = 0.97 over 296 resolved markets.

The video's own screen contradicts its own latency claim by a factor of fifteen

The opening line is "under 100 milliseconds while normal LLMs take 3-10 seconds." The Jev answer panel in frame 3 is labeled "Real Jev output · 1.50 s." Those two numbers are in the same video, roughly ten seconds apart, and they differ by 15x.

TypeSafe's own launch post puts the real range in between: "End-to-end response time is 70ms-500ms" (TypeSafe AI blog, Sep 15, 2026). The under-100ms figure is the optimistic floor of the vendor's published band, not a typical result, and the video presents the floor as the norm.

The "3-10 seconds" half of the comparison has no source behind it. The video shows OpenAI, Claude and Perplexity logos while saying it, which reads as a claim about those three products, and none of them publishes a 3-10 second latency figure. TypeSafe's own marketing claim is "40x-200x faster" on System One tasks. Independent reporting is lower still: InfoQ cites an OpenChamber analysis finding a median speedup of 7x and median cost savings of 30x, plus a Vercel engineer reporting a safety classifier running "five to 18 times faster" than the LLM it replaced (InfoQ, Oct 2026). The video's implied 30-100x speedup sits above the vendor's midpoint and roughly an order of magnitude above the independent median.

The SDK snippet in the video will not run

The flow.ts frame shows four things, and all four are wrong against the published SDK.

On screen TypeSafe JS SDK docs
from "@typesafe/sdk" npm install @typesafe-ai/sdk
new Jev({ apiKey: process.env.JEV_KEY }) new TypeSafeClient()
jev.run({ text, questions }) client.systemOne({ state, questions })
yesNo("Is the buy flow informed?") noul(...)

Jev is the model; TypeSafeClient is the client. The three primitives are Choice, Score and Noul, not Choice, Score and yesNo (docs.typesafe.ai). The code card is a rendering of the idea, not a copy-pasteable example, and nothing on screen says so.

One structural claim does hold. The voiceover says Jev "evaluates multiple type questions in parallel," and the model docs state it directly: "Jev ingests the state once and evaluates every question against it in parallel" (docs.typesafe.ai/models).

The yes/no card displays a confidence score that the API does not return

Frame 3 shows the YES/NO card with a "100% sure" badge beside an 87% Yes dial. The CHOICE card reads 94% sure, the SCORE card 91% sure. Confidence on Choice and Score is real. Confidence on a Noul is not.

From the Noul reference: "There is no separate confidence value for a Noul, unlike a Choice or a Score. A Noul's probability distribution has only two outcomes, yes and no, so the single noul value describes it completely" (docs.typesafe.ai/primitives/noul). The "100% sure" badge on the yes/no card is invented for the mockup. A trader wiring a gate on that field would be reading something the API never sends.

The token meter is also off-spec. The console caps the snapshot at 8,000 tokens. Jev's documented budget is "64k tokens per request; 32k tokens for state plus the longest question" (docs.typesafe.ai/models). Eight thousand is the demo UI's own number.

The quote engine math is the one part that fully checks out

The pricing card cites the Avellaneda-Stoikov formula, and the on-screen rendering matches the paper exactly. The card displays δ^a + δ^b = γσ²(T − t) + (2/γ)ln(1 + γ/κ). Equation (3.18) of Marco Avellaneda and Sasha Stoikov's "High-frequency trading in a limit order book" (preprint dated October 5, 2006, published in Quantitative Finance 2008) reads δ^a + δ^b = γσ²(T − t) + (2/γ)ln(1 + γ/k) (Cornell ORIE preprint). Only the kappa-versus-k glyph differs.

The quote_engine.py lines match the paper too. r = s - q*γ*σ**2*t is the paper's reservation price r(s, q, t) = s − qγσ²(T − t). bid, ask = r - d/2, r + d/2 is the spread centered on the reservation price rather than the mid, which is precisely the distinction the paper draws between its "inventory" strategy and the "symmetric" benchmark.

The displayed numbers reconcile. Cycle 4 shows mid s = 184.61, inventory q = +2 lots, T − t = 0.94, reservation r = 184.55, spread Δ = 0.27, bid 184.41, ask 184.68, skew r − s = −0.058. Ask minus bid is exactly 0.27. The bid/ask midpoint is 184.545, matching r. Cycle 1 shows q = +3, T − t = 0.98, skew −0.091. Scaling the cycle-4 skew per the reservation-price formula gives 0.058 × (3/2) × (0.98/0.94) = 0.0907, against the 0.091 displayed. The engine frames are arithmetically sound.

Two things in the same frames are not. The quote engine prices an instrument around 184.60, while step one's feed shows BTC-USD at 64,702.3 USD. The pipeline the video narrates as one continuous system is running on two unrelated price scales. Separately, the TradingView card in frame 15 reads BINANCE:BTCUSDT at 63,194.02, +3,334.02 (+5.57%) — internally consistent with a 59,860.00 prior close, and a third price inconsistent with the other two.

RLCD means two different things, and the video uses the newer one without saying so

The transcript says Jev "is trained with RLCD instead of human preference." That is TypeSafe's own framing, and it checks out: the launch post names the method "Reinforcement Learning for Calibrated Decisions (RLCD)" (typesafe.ai).

The acronym already belonged to something else. RLCD in the published literature is "Reinforcement Learning from Contrastive Distillation for Language Model Alignment," by Kevin Yang, Dan Klein, Asli Celikyilmaz, Nanyun Peng and Yuandong Tian, submitted July 24, 2023 and published at ICLR 2024 (arXiv:2307.12950). That method builds preference pairs from contrasting prompts, which is a preference-data technique, not a calibration-training technique. Anyone searching the acronym after watching this lands on the wrong paper.

The calibration evidence shown is also weaker than the narration. The MARKETS RESOLVING table lists "Unemployment rate ticks up" at Jev 0.82, market 0.79, result NO. The headline reliability claim is a correlation between Jev's confidence and the market-implied probability (Jev r = 0.99 vs Pref. r = 0.97), which measures agreement with prices, not agreement with outcomes. The reliability diagram and the ECE scorecard are the metrics that would measure outcomes, and both are blurred past legibility in every frame.

Key Takeaways

  • The video's on-screen Jev panel reads "Real Jev output · 1.50 s" while the voiceover claims "under 100 milliseconds." TypeSafe's published range is 70ms-500ms.
  • Correction: the SDK import @typesafe/sdk is wrong. The real package is @typesafe-ai/sdk, the client is TypeSafeClient (not Jev), the method is systemOne() (not run()), and the yes/no primitive is noul() (not yesNo()).
  • Correction: the YES/NO answer card shows a "100% sure" confidence badge. TypeSafe's docs state a Noul returns no separate confidence value at all.
  • The console caps input at 8,000 tokens. Jev's documented budget is 64k per request, 32k for state plus the longest question.
  • The Avellaneda-Stoikov formula on screen matches equation (3.18) of the 2006 preprint exactly, and the cycle-1 and cycle-4 quote numbers reconcile to the cent: ask − bid = 0.27 = spread Δ, and the skew scales 0.058 → 0.091 as q and (T − t) change, against 0.0907 predicted.
  • The video shows three mutually inconsistent prices: BTC-USD at 64,702.3 on the feed, BTCUSDT at 63,194.02 on TradingView, and a mid of 184.61 in the quote engine that prices neither.
  • Count-up artifacts, not live data: buyer demand animates 63% → 64% while the JSON at the same as_of: 14:32:07Z reads buy_share: 0.62 then 0.63; order depth runs 393/388 → 399 → 412.8/298.1; price gaps run 1.2 bps → 1.4 bps; the depth tile says "3.4 bps vs venue B" while the JSON says vs_venue_bps: 3.2.
  • RLCD is overloaded. TypeSafe's RLCD is "Reinforcement Learning for Calibrated Decisions." The 2023 ICLR paper's RLCD is "Reinforcement Learning from Contrastive Distillation." The video names neither expansion.
  • The calibration panel's own table shows a miss: Jev 0.82 on "Unemployment rate ticks up," resolved NO.
  • Unverified: the "3-10 seconds" LLM latency figure (no primary source publishes it, and the three logos shown do not); the 48,382 ticks/s feed rate; the "296 resolved" market count and the ECE scorecard values, which are blurred in every frame; and whether any live trading system described here was actually run against a real exchange rather than mocked for the shoot.

Resources

Published October 2, 2026. Writeup generated from a favorited TikTok.