The Bot Ledger
EN

Home / Articles

Should an AI Make Your Bot's Trading Decisions? Cost per Call vs Thin Books

Per-decision model costs against what a $10 ticket on a thin prediction-market book can pay, and where a language model actually earns its keep.

A person analysing charts on several screens

Illustrative figures based on logged runs and list prices

The pitch writes itself: put a language model in the loop, let it read the book and the news, let it decide. Before building it, put two numbers side by side. What a decision costs, and what the market will pay for a right one.

What a decision is worth

On the 5-minute crypto markets the order book is thin where the edge lives. Mid-window, the best ask on the largest coins was about $140 to $165 of stock; on the smaller ones it was $3 to $47. The five best levels together ranged from $55 to about $1,465. The late-window favourite, the one taker edge that held, fires on roughly 19 tradeable windows a day across seven coins, and the median ticket that could be filled at the price the edge was measured at is $10 to $12.

Take a $10 ticket and a 2-point edge after fees. A correct decision is worth about 20 cents. Nineteen of them a day is under $4. That is the whole prize the market offers a taker at this size, before latency and before the edge decays.

What a decision costs

A model that reads the book, the spot feed and a few rules needs about 1,500 input tokens and 100 output tokens per call. At list prices that is about a fifth of a cent on the smallest current model, four tenths of a cent on the mid tier, and a cent on the largest. Cheap, until you count calls.

Cost per decision and per day by model at 1,500 input and 100 output tokens
ModelPer decisionEvery window, 7 coins (2,016 a day)Only tradeable windows (19 a day)
Small (Haiku 4.5)$0.002$4.03 a day$0.04 a day
Mid (Sonnet 5)$0.004$8.06 a day$0.08 a day
Large (Opus 5)$0.010$20.16 a day$0.19 a day
Daily model spend when the model decides every 5-minute window on seven coins, against the roughly $3.80 a day the late-window edge offers at a $10 ticket. List prices, 1,500 input and 100 output tokens per call.

If the model looks at every window, even the smallest one spends more than the edge earns. If it only looks at the windows a fixed rule has already flagged as tradeable, the API bill is pennies. But then the rule made the decision, and the model is a very expensive way to say yes.

The part the price table hides

The late edge needs the order confirmed within about 500 milliseconds of the read. A model call takes one to several seconds. The book reacts to the spot feed in about 16 milliseconds. Whatever the model decides, it decides after the price has moved, and at two seconds of delay the same rule loses four points instead of winning two. The cost that kills the idea is time, not tokens.

Does it know something the book does not?

The question underneath all of this was tested directly. On crypto, on weather and on sport, the exchange's own price forecast its own settlement better than any model built against it, including one fed the National Weather Service's model output and one fed a league's own win-probability feed. A language model reading the same book, the same spot price and the same news has no new input either. It has an opinion. The book already has everyone's.

What did work

A small gradient-boosted tree on nine features read from the book and the spot feed. It runs in under a millisecond, costs nothing per call, was trained on one season and tested once on the next, and returned about 8 points per dollar for a week when fired from a server in the exchange's region. It did not read the news. It did not need to.

Rule of thumb: if the decision has to happen inside a window, it has to be a rule or a tiny local model. Anything that takes a second or costs a cent is already too slow and too dear for a $10 ticket.

Where a language model earns its keep

  • Writing the logger, the backfill and the research code. Weeks of work in days.
  • Reading an exchange's docs and terms every week and flagging what changed; one settlement rule changed overnight during testing and every bot modelling the old rule was wrong from that morning.
  • Reviewing a backtest for the traps that manufacture fake edges: derived labels, frozen books, grid sampling, search without a null.
  • Drafting the kill bar and the checkpoint before launch, so they are written while you are calm.

Those are hourly jobs, not per-window jobs. The bill for a month of that is smaller than one day of deciding every window, and the output is a better bot rather than a slower one.