quant-desk

Senpi Quant Desk — the desk your AI Quant produces, for any Hyperliquid address

Built for one thing first: the user's own book. A trader joins senpi, pastes their Hyperliquid wallet, and gets their desk — the book they actually run, scored, protected and improved, in the second person, with the next steps recommended to them. That is the default and the experience to design for: "run AI quant on 0x…" means the user is 0x…, whoever the address belongs to. The same engine also reads someone else's book — "run AI quant analyst on 0x…", "review this trader", a leaderboard pick, a whale — to learn from it (third person, learn-from-them follow-ups, a side-by-side compare). Run it plain (--mine) unless the user asks for the analyst read; then --other (alias --analyst), and never let that desk say "you".

HARD RULES — obey these even if you skim the rest.

1. ONE desk at a time, and NEVER re-run one that is still going. A desk is a long command, so exec hands you back {"status":"running", "sessionId": …} and the real result arrives on a later process poll. That handoff is not a failure. Poll the session you already have.

   Launching a second run does not make the first one finish. Both hammer the same per-IP rate limit, so two runs are slower than one and three usually kill each other. On 2026-09-23 an agent that could not see a result launched five concurrent runs of the same wallet, inventing sleep 15 && and sleep 30 && workarounds; three died with HTTP 429 and the reader waited six minutes for nothing. The desk now refuses a second run (exit 5, already_running) — treat that as "your first one is still working", not as an error to route around.

   If a run really is dead, the state dir is the shared surface: the finished desk lands in the same file, so a fresh --section overview after it completes is instant.

   PASS yieldMs, NOT JUST THE HARD KILL — this is the single most common way a reader gets no desk. The hard kill (seconds) is timeoutSeconds when the exec tool lists it, otherwise timeout. Send only the one the exec tool lists. yieldMs is how long exec WAITS before handing you a background handle instead of the output. Without it the tool backgrounds the run at ~10 seconds no matter how large a hard kill you passed, and you get Command still running (session …, pid …) with a progress tail — not a desk. Measured over 24h:

   yieldMs passed	what came back	runs	got the score
   none	backgrounded at 10.1s	19	0
   5000 / 15000	backgrounded at exactly that	2	0
   120000 / 190000	the finished desk, in 39-49s	3	3

   So: yieldMs: 190000 together with a hard kill of 200 seconds on the first desk call. The desk itself is not slow — it lands in well under a minute on a normal book. Twenty-one runs across seventeen users produced nothing last window purely because the wait was ten seconds.

   The hard kill still matters — give a desk on a wide book at least 180s of it, because at 120s the exec tool SIGTERMs it mid-run and you get nothing after paying the whole cost. The two are not alternatives: the hard kill decides when the run is killed, yieldMs decides when you stop waiting for it. You need both.

   If you DO get a background handle, you are not finished: poll it (process poll <sessionId>) until it exits and relay what it printed. Abandoning the handle is how a user ends up with a half-sentence of progress log and no score.

2. Relay it in STAGES — never as one block. The analysis takes 30-60s on a typical book, up to ~2 MINUTES on a very wide one (100+ coins), and the whole desk is thousands of words. Delivering it as a single wall after a silent wait is the worst possible shape: the reader waits with nothing, then gets more than they can read. The first run caches for 10 minutes, so every section after it returns instantly.