sukul bagai
Back to portfolio

Case study

NIFTY Options Trading Co-Pilot

An event-driven NIFTY options system where Claude fuses technicals, options-chain positioning, and scored news into an explainable trade call, backed by a risk-gated execution engine now in active build.

In active rebuild — not yet live with real capital. Dry-run is the default mode; the system has never placed a real broker order. The execution engine itself is built — going live is blocked on a static outbound IP the broker requires, not on missing code. The co-pilot's analysis and the execution engine also aren't wired together yet: a human reads the recommendation and separately places every order by hand.

TypeScriptClaude (Anthropic) — 3-tier routingFastifyZerodha Kite ConnectPostgreSQL + PrismaTradingView Pine Scripts

The problem

Why this exists

Intraday NIFTY options entries are driven by fast-moving, multi-modal context — options positioning, technical structure, and slower qualitative signals like news — that frequently disagree with each other. A purely rules-based strategy can weigh price and indicator state, but can't synthesize genuinely unstructured context or explain why a confluence exists. The system keeps the directional math deterministic and auditable, and reserves the LLM for the part rules can't do: synthesizing that structured signal together with news and commentary into an explained, confidence-scored recommendation — with an explicit case for what would invalidate the trade. A human is still structurally required to read that output and act on it; it's built as a co-pilot, not an autopilot.

Architecture

How it works

  1. 1Live TradingView technical indicators and options-chain data (open interest, put-call ratio, max pain) stream in continuously and get fused by a deterministic, auditable scoring engine — plain weighted math, not an LLM call, so the directional signal underneath everything is testable and explainable on its own.
  2. 2Claude synthesizes that fused signal together with scored news and commentary into an explained trade recommendation, with a confidence score and an explicit "what would invalidate this" section — reasoning over qualitative context a rules engine can't parse.
  3. 3A separate risk-gated execution engine — built in a second phase, deliberately sequenced first this time — checks a kill switch, daily trade limits, and order-level validation before anything reaches the broker, then manages fills and exits against the live order book.
  4. 4A first-class dry-run mode writes the exact same order, exit, and fill records as a live trade, so paper trading exercises the real code path — not a simulated stand-in for it — before any capital is at risk.
  5. 5The co-pilot's recommendation and the execution engine aren't connected yet: today a human reads the analysis and separately places every order by hand through a manual console.

Judgment calls

Key decisions

Deterministic fusion, LLM synthesis — never the reverse

The confidence and directional scoring that feeds the co-pilot is plain, weighted, auditable math — not an LLM asked to numerically weigh five noisy inputs on every cycle. The model is reserved for the part that's genuinely qualitative: synthesizing that score together with unstructured news and commentary into an explained recommendation.

Three-tier model routing by how much judgment a task needs

The heaviest reasoning model runs the trading co-pilot itself; a faster, cheaper model handles high-volume, low-judgment work like scoring news relevance. A deliberate cost/latency allocation instead of one model doing everything.

The single biggest reversal: rebuilding the roadmap around "execution first"

The first version spent roughly three months building analysis — indicators, news scoring, signal fusion — with execution sequenced last, and it stalled having never placed a single order. The postmortem it produced became the explicit premise for the rebuild.

Dry-run as a first-class code path, not a shortcut

A mid-project decision that a simulated order writes the identical record shape as a real one, differing only in the order ID and a simulated fill — specifically so the paper-trading validation stage exercises real code, not a simulation of it.

Honest lessons

What didn't work

Three months building an opinion the system had no way to act on

The first version's own postmortem, written candidly as a self-audit: every completed task improved the quality of an analysis the system had no way to act on, because order execution sat behind a long list of other roadmap items and was never reached. It's the single lesson the rebuild is organized around — whatever gets built next, execution comes first.

Never blind-retry an order on an ambiguous broker response

A network timeout on order placement is genuinely ambiguous — the order may or may not have gone through. The system's own rule calls a blind retry here "the single worst failure mode" it could have. Instead, every order carries a correlation tag at placement; on a transient error, the system never retries — it polls the broker's own order book and matches by tag, and if still unconfirmed, leaves it flagged for a human to reconcile rather than risk a duplicate.

A broker SDK bug that silently broke session recovery

Automatic handling for an expired trading session checked an error field the broker's own SDK never actually sets — found only by reading the vendored SDK source directly. Automatic session recovery had likely been silently failing for most of the project's life until the fix.

Pieces that looked wired but weren't

Early on, several scheduled jobs logged a line and returned without doing any real work — enough to look like a working system without being one. The rule adopted after finding it: a job is either real or it doesn't exist. One related gap is tracked openly rather than hidden: the kill switch is in-memory only today, so a server restart would silently re-enable trading — hardening that is the next piece of the risk manager.

By the numbers

What's real, not aspirational

70.5%

Win rate on 44 paper-tracked signals from the original rules-based tracker — not live trading

237 tests

Automated tests across 16 files, covering risk gates and order-state transitions

3 pipelines

Signal tracking, LLM co-pilot, and order execution — built, not yet fully wired together