Ray Fu, ex-Meta senior engineer and AI automation educator

Ray Fu

I'm an Ex Meta Senior Engineer that makes content and teaches OpenClaw and AI Automations.

stan.store/raycfu

How to Build a 24/7 AI Trading System With Jev

A 24/7 trading bot with Jev

 

This guide walks you through the architecture serious builders use to put Jev, TypeSafe's new decision model, inside a trading bot that runs around the clock. You get the setup, the exact way to split the work between code and AI, copy-paste code for the decision layer and the risk layer, a prompt to have Claude Code build the rest, and the testing steps that keep you from losing money on day one. Expect a weekend to build it and at least two weeks of paper trading before a real dollar touches it.

Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu

What Jev Is (60-Second Version)

Jev is a decision model from TypeSafe AI, the company founded by Diogo Almeida, the former OpenAI researcher behind the work that became ChatGPT. It launched September 15, 2026.

Jev does not write text. You send it a state, like a snapshot of an order book, plus a set of questions with the answers already defined. It sends back a typed answer with a probability attached, usually in 70 to 500 milliseconds. Input costs $0.042 per million tokens and output is free.

Why that matters for trading: a chat model like Claude or GPT takes several seconds to reason about an order book. By the time it answers, the market has moved dozens of times. Jev answers before the next block lands.

It has three question types:

Noul asks yes or no and returns a probability from 0 to 1. "Is this flow likely informed?" gives back 0.83.

Choice picks one option from a list you define. "Which regime is this?" gives back trending, mean-reverting, or chaotic, with a probability for each.

Score rates something on a scale you define. "How good is this for quoting, 0 to 3?" gives back a level and a confidence.

You can ask all of them in one call, and they run in parallel, so six questions take about the same time as one.

There is already proof it works in a live loop. Developer Jarrod Watts built a public demo bot, jev-trader, that reads an on-chain order book, asks Jev for a decision every 300-millisecond block, and places real limit orders. You can see it at jev-trader.vercel.app.

What You Need

A TypeSafe account and API key from https://console.typesafe.ai. If you see a waitlist, apply. People are being approved quickly.

Python 3.10 or newer.

Claude Code, to build the parts of the system around Jev.

An exchange or on-chain venue with an API that supports limit orders and a test or paper mode.

Money you can afford to lose, for much later. Not yet.

Step 1: Get the Architecture Right

Never ask AI to trade

 

This is the step that separates working systems from viral demos.

The mistake almost every failed AI trading bot makes is asking the model to trade. "Look at Bitcoin and tell me what to do" is not a question any model can answer well at any speed.

The right split has four layers:

Code calculates the state. Everything that is math stays in code: the mid price, the spread, order book imbalance, volatility, your inventory, your drawdown. Never spend a Jev call on arithmetic.

Jev interprets the state. Only the fuzzy judgments go to Jev. Is this market trending or chopping? Is this aggressive buying informed or just noise? Is this a good environment to quote into?

Code applies the policy. Your own rules turn Jev's answers into an action. The thresholds live in your code, never in the model.

The risk engine has the final word. Hard limits, checked before every single order, that no model can override.

One more design rule from TypeSafe's own guidance: keep every question atomic. If a question needs to weigh several factors, split it into several questions and combine the answers with your own weights in code. When your priorities change, you edit a number, not a prompt.

Step 2: Set Up Jev

1. Create your API key at https://console.typesafe.ai/keys and save it:

export TYPESAFE_API_KEY="your-key-here"

2. Install the SDK:

pip install typesafe-sdk

3. Install TypeSafe's official skill so Claude Code writes correct Jev calls:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

4. Fire your first decision on a sample market snapshot:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

state = {
"mid": 3.4127,
"spread_bps": 3.5,
"imbalance": 0.71,
"realized_vol_5m": 0.034,
"inventory": -120,
"aggressive_buy_ratio": 0.63,
}

response = client.system_one(
state=state,
questions={
"regime": Choice(
instructions="What market regime does this state describe?",
criteria={
"trending": "Price moving persistently in one direction",
"mean_reverting": "Price oscillating around a stable level",
"chaotic": "Erratic moves with no clear structure",
},
),
"toxic_flow": Noul(
instructions="Aggressive order flow is likely informed rather than noise",
),
"quote_environment": Score(
instructions="How favorable is this state for providing liquidity",
criteria=["Do not quote", "Marginal", "Standard", "Excellent"],
),
},
)

print(response.answers["regime"].choice)
print(response.answers["toxic_flow"].noul)
print(response.answers["quote_environment"].score)

If those print, you are talking to Jev.

Two setup rules that save you later:

Call TypeSafe directly for speed. Jev is also on OpenRouter and Vercel AI Gateway, but every gateway adds a network hop you cannot get back. For a block-speed loop, use the direct API.

Pin the model version and log it with every decision. Your thresholds are tuned to one version of the model. If it upgrades silently and your thresholds stay the same, the system can break without warning.

Step 3: Build the State Snapshot

This is pure code, and it is where most builders cut corners. On every block, compute a compact snapshot. Keep it under about 400 tokens, because you pay per input token and smaller is faster.

What goes in it:

Price: mid price, microprice, returns over 1, 5, and 30 minutes.

Order book: spread, depth at the top three levels, buy-sell imbalance, your queue position.

Flow: aggressive buy and sell volume, trade and cancel intensity.

Volatility: short and medium realized volatility, and how it compares to the last 24 hours.

Cross-market: price gap versus a reference exchange, basis, funding rate.

Your book: inventory, unrealized profit and loss, drawdown, how long you have held the position.

System health: fill ratio, rejected orders, slippage, and your last 10 response times.

Three rules:

Numbers only. Dense and numeric, no descriptions.

No future data. Every field uses only information from before the decision. A single leaked future value makes every backtest a lie.

Log everything. Save every snapshot, the decision Jev made, and what happened next. That record is how you test calibration in Step 8.

Step 4: Fire the Judgment Battery

Six questions, one call

 

One question is a demo. A battery of questions in one call is how you build a real system. It is also how good traders think: not one buy-or-sell call, but several reads at once.

response = client.system_one(
state=snapshot,
questions={
"regime": Choice(
instructions="What regime is the market in right now",
criteria={
"trending": "Persistent move in one direction",
"mean_reverting": "Oscillating around a stable level",
"high_vol": "Large moves both ways",
"crisis": "Disorderly, liquidity vanishing",
},
),
"direction": Choice(
instructions="Most likely price bias over the next 10 blocks",
criteria={
"up": "Higher",
"down": "Lower",
"neutral": "No clear bias",
},
),
"toxic_flow": Noul(
instructions="Aggressive flow is likely informed traders, not noise",
),
"liquidity_stressed": Noul(
instructions="The order book is thinner than its normal level",
),
"quote_environment": Score(
instructions="How favorable is this state for providing liquidity",
criteria=["No", "Marginal", "Standard", "Excellent"],
),
"inventory_pressure": Score(
instructions="How urgently inventory should be reduced",
criteria=["None", "Mild", "Skew hard", "Reduce now"],
),
},
)

Six judgments, one call, one round trip, a tiny fraction of a cent.

Step 5: The Policy Engine and the Risk Engine

Now your code turns those answers into an action. This part is yours forever. It never goes to the model.

def compose_action(ans, snap, limits):
if snap["drawdown"] > limits.max_drawdown:
return "KILL"
if ans["toxic_flow"].noul > 0.6:
return "PULL_QUOTES"
if ans["liquidity_stressed"].noul > 0.7:
return "WIDEN"

q = ans["quote_environment"]
if q.score >= 2 and q.confidence > 0.80:
skew = inventory_skew(ans["inventory_pressure"].score)
return ("QUOTE_BOTH_SIDES", skew)
if q.score >= 1:
return "QUOTE_WIDE"
return "STAND_DOWN"

Set each threshold based on what being wrong costs for that action, not one number for the whole system. Pulling quotes when you did not need to costs a little. Quoting into toxic flow costs a lot. So the bar for quoting should be higher than the bar for pulling out.

The confidence gate is the key idea. Jev is trained with a method called Reinforcement Learning for Calibrated Decisions, built so that when it says 80%, it is right about 80% of the time. That is what lets you act only on high-confidence answers and stand aside on the rest.

The pricing math stays in code too. If you are market making, the classic Avellaneda-Stoikov model calculates where to quote based on your inventory and volatility:

reservation price = mid - inventory x risk aversion x volatility squared x time left

Jev does not replace this. It answers the question the formula cannot: is this a market worth quoting into at all?

The risk engine always wins

 

Then the risk engine. Hard limits, checked before every order, that Jev never touches:

Maximum position size

Maximum daily loss

Maximum drawdown

Maximum order size

Maximum time holding inventory

Maximum age of market data

Maximum leverage

Maximum API errors in a row

Maximum decision response time

Every limit must be checkable by something other than the model saying everything is fine. If a check cannot be verified independently, it is not a check.

Step 6: The 24/7 Loop and the Fallback Ladder

Here is the full loop, once per block:

1. A new block arrives (listen on a WebSocket, with polling as a backup).

2. Read the order book.

3. Compute the state snapshot in code.

4. Fire the Jev battery, six questions in one call.

5. The policy engine picks an action.

6. The pricing math sets your quotes.

7. The risk engine checks every hard limit and can veto anything.

8. Cancel old orders and post new limit orders.

9. Log everything, track fills, update inventory, wait for the next block.

The block deadline rule: if Jev's answer has not come back before the next block, do nothing for that block. Never trade on stale information.

The fallback ladder

 

The fallback ladder is what makes a bot actually run 24/7 instead of 24/7 until the first network hiccup at 2 AM:

Healthy and high confidence: normal operation.

Healthy but low confidence: trade smaller, or just watch.

Answer arrived late: hold, no stale orders.

Jev unavailable: switch to simple rules written in code only.

A hard limit breached: kill switch, close positions, send yourself an alert.

Step 7: Build It With Claude Code

Nine stages is a lot to wire by hand. This is what Claude Code is for, and the TypeSafe skill from Step 2 means it writes the Jev calls correctly.

Open Claude Code in an empty folder and paste this:

Use the TypeSafe skill. I want to build a 24/7 trading system for [VENUE, e.g. an on-chain order book] that uses Jev for judgment and plain code for everything else. Build it in stages, with tests for each stage, and stop for my approval between them:

1. A state engine that computes a numeric snapshot under 400 tokens on every block: price, order book, flow, volatility, my inventory and PnL, and system health. No future data in any field.

2. A Jev decision layer that sends the snapshot with a battery of questions in one call: regime (Choice), direction (Choice), toxic flow (Noul), liquidity stress (Noul), quote environment (Score), inventory pressure (Score). Call the direct TypeSafe API, pin the model version, and log the version with every response.

3. A policy engine in code that turns the answers into an action using confidence thresholds I can edit in a config file.

4. A risk engine with hard limits for max position, daily loss, drawdown, order size, data age, leverage, API errors, and decision latency. It must be able to veto any order.

5. The block loop with a fallback ladder: hold if the decision is late, use code-only rules if Jev is down, and kill and flatten if a hard limit is breached.

6. Paper trading mode only. Do not connect real funds. Log every snapshot, decision, and outcome to a file so I can check calibration later.

Start with stage 1 only.

Do not skip the "paper trading mode only" line. Real money comes after Step 8, not before.

Step 8: Test Before You Trust It

Test before real money

 

Run it in paper mode for at least two weeks. Then check three things.

Does the whole system beat simpler versions? Do not just ask whether Jev predicted the price. Compare the full system against plain hand-written rules on the same data, the same costs, and the same limits. Then compare Jev with the confidence gate against Jev without it. If standing aside when uncertain does not improve results, something is wrong.

Is Jev calibrated on your market? When Jev said 80%, did those events happen about 80% of the time on your venue? Plot what it predicted against what actually happened using the decisions you logged. TypeSafe calibrated Jev on their data, not your market. If the curve is off, adjust your thresholds in the policy layer.

Do the fees eat you alive? This is the one that kills most market-making bots. Canceling and replacing orders every single block costs fees, and on-chain it costs gas. Independent testers who ran the numbers on the Jev demo bot found that naive every-block order replacement can lose money on fees alone against a tight spread. Before going live, do the math: your expected profit per trade has to be bigger than your fees per trade. If it is not, you need wider spreads, orders that rest longer, or a real directional edge.

Only after all three look right do you put real money in, and start small.

Where This Works and Where It Does Not

Works: on-chain order books that move at block speed, a few hundred milliseconds per step. Prediction markets with wide spreads. Tactical calls that play out over seconds, like reading the regime or spotting toxic flow.

Does not work: competing with professional high-frequency firms on major stock exchanges. They trade in microseconds on custom hardware. A 300-millisecond loop has no place there.

What Jev Can and Cannot Do

Jev can return fast, typed, calibrated decisions, run many questions at once for the price of one, sit inside a block-speed loop, and replace fuzzy hand-written rules, slow chat-model classification, and simple regime detectors, all for very little money per month.

Jev cannot write your strategy, chain one answer into the next in a single call (dependent questions need a second call), compete at microsecond speed, replace your market data feed, your math, your exchange connection, or your risk controls, guarantee TypeSafe's published accuracy numbers on your market, or turn a losing strategy into a winning one.

Jev makes decisions fast and cheap. Finding an edge is still your job.

When Things Go Wrong

Decisions are coming back too slowly for your blocks. You are using a gateway instead of the direct API, your snapshot is too big, or your server is far from TypeSafe's. Go direct, shrink the snapshot, and check your latency logs.

Jev's answers look random. Your questions are too vague or too broad. Make each one atomic, and give every Choice option a clear description.

Every answer comes back low-confidence. The snapshot does not contain enough to decide. Add the missing signal, or accept that the market is genuinely unclear and stand aside.

Backtests look amazing and paper trading loses money. You almost certainly leaked future data into the snapshot, or you left fees out of the backtest. Check both.

Thresholds stopped working overnight. The model version changed. This is why you pin and log it.

The bot stopped at 2 AM. The fallback ladder is missing or broken. Test each rung on purpose: kill the network, slow the API, breach a limit.

Rules to Remember

Never ask Jev to trade. Ask it narrow judgments. Code makes the decision.

Math in code, judgment in Jev, final say in the risk engine.

Ask every question in one battery, and keep each one atomic.

Thresholds live in your code, set by what being wrong costs.

Late answer means no trade. Never act on stale data.

Pin the model version and log it every time.

Paper trade for two weeks minimum. Check calibration and fees before real money.

Do not bring a 300-millisecond bot to a microsecond fight.

You now have the full blueprint for a 24/7 trading system with Jev making the fast judgments, your code making the decisions, and a risk engine that always has the final say.

Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu