DEV Community: Khushal Jain

98 stars across 26 repos taught me that engineering effort and GitHub stars are unrelated

Khushal Jain — Thu, 29 Oct 2026 08:44:56 +0000

I have been building open-source tools for Indian markets under
github.com/85599 since 2021. Last week I pulled the actual numbers instead of the
impression I had in my head:

26 public repos, 98 stars, 28 forks, 21 followers
21 of 26 had a description; 21 had a license; 16 had topics, 10 had none
CI runs on 4 of my 6 flagship repos. Two do not.

And the ranking was a slap:

Repo	Stars	Forks	What it is
BankNIFTY-Golden-Ratio-Strategy	18	12	a ~10-line README describing one rule
KJStockScreener	10	4	Streamlit screener, live on Streamlit Cloud
pinesprout	8	3	a Pine Script CLI toolkit with its own lexer, parser, formatter, linter, v4→v6 upgrader, on PyPI
Strike & Hedge	6	0	NSE+BSE chains, Greeks, PCR, max pain, rule engine, optional multi-agent desk
Research-Copilot-Pro	6	2	analyst → bull/bear → risk → PM agent pipeline for Indian equities

The repo I spent the least time on has the most stars, and the one I am proudest of as software has a third
of them. Here is what I think that actually means, plus the levers that did work.

Lesson 1: a rule stated plainly beats a tool nobody can evaluate in 10 seconds

BankNIFTY-Golden-Ratio-Strategy is this, nearly verbatim: golden number = ((prev high - prev low) + first 10-minute opening range) * 61.8%, buy above prev close + that, sell below prev close - that, 0.5% stop, 2%
target. Its own README says "Its a bad but popular strategy that makes decent returns."

I wrote that line honestly and it is the reason people trust the rest. That repo has 12 forks against 18
stars - an absurd ratio, and it means people are taking the rule and coding it themselves rather than
starring and leaving. The engineering-heavy repos get stars from people who want the binary; the one-paragraph
repo gets forks from people who want the idea.

If you only maintain one thing, consider maintaining the idea in a form someone can copy in ten seconds.

Lesson 2: my topics were noise, not search terms

Here is a nice way to check whether your own metadata is doing anything: ask what someone would type into
GitHub search to find your repo, and compare it to the tags you actually set.

pinesprout - a command-line linter, formatter and v4-to-v6 upgrader for Pine Script - was tagged
tensorflow, deep-learning, machine-learning, nlp, data-science. It does not use TensorFlow. It does
not use a model for the linting, formatting or upgrading at all; those are a hand-written lexer and a rule
engine. Meanwhile cli, linter, static-analysis and code-formatter - the four words someone searching
for exactly this tool would type - were missing.

So those are set now, along with open-interest, max-pain and llm-agents on the options desk, and
computer-vision on the chart reader. Three things I learned doing it:

GitHub caps you at 20 topics per repo. nifty-desk was already sitting at 20 (and its 20 are genuinely good ones - ocr, openpyxl, payoff, risk-management), so there was nothing to add. The cap was the problem, not the tags.
PATCH /repos/{owner}/{repo} silently ignores the topics field. My first script "succeeded" on all six repos and changed nothing, because topics live at their own endpoint (PUT /repos/{owner}/{repo}/topics, which replaces the whole list - read it first and merge, or you will delete everything that was there). A 200 response is not a confirmation; read the value back.
Topics and stars are independent. Trading-View has 5 stars and zero topics. Strike & Hedge has 6 stars and 20 topics. Tagging a repo is writing a search term for a stranger; it says nothing about whether anyone wanted the thing.

Lesson 3: what actually moved stars was removing friction

The pattern across every repo that grew:

MIT, stated in the badge. The 2021 ones without a license file read as "all rights reserved" and get skipped. No license does not mean "free to use", it means "legally unclear", and a careful evaluator will close the tab rather than guess.
"No API key needed" in the first sentence. That is a data-source claim, not a feature, and for anyone evaluating a finance tool at 11pm it is the whole decision. Both Strike & Hedge and optionchainpro-terminal lead with it.
A binary for people who do not have Python. nifty-desk ships a Windows exe (NiftyDesk-win64-v1.0.4.zip) precisely because the traders who wanted it were the least likely to run pip install. The install path that reaches the most people is usually not the one engineers prefer.
A GIF of the real flow, and real generated output. No mockups. The Excel screenshot in that README is an actual workbook the tool wrote. This is the only "marketing" skill I have, and it does more than any feature list.
Tests that run offline. 45 tests in Strike & Hedge, 58 in MarketMitra-AI, no network, no keys - so a reviewer can prove the thing works without becoming a trader. python -m pytest tests -q being a green 30-second experiment is worth more than a paragraph of claims.
Honest caveats. The Strike & Hedge README has a table of every public data source it could not find - no intraday FINNIFTY, no futures quotes, BSE not publishing delta-OI intraday - and a Known Limits section saying what the tool refuses to score. Every issue I got after adding it was a feature request instead of a "this is broken" report.

Lesson 4: the graveyard is instructive too

Ten of 26 repos still have zero topics, and the list decomposes cleanly once you look at it:

Seven 2021 relics - 85599.codebook.io, flames.github.io, real-time-chat (all January 2021), Remoting-CMD (February), 85599.github.io and Django-based-stock-trading-platform (March), Thar (also 2021).
Two forks (AI-Trader, nofx), which inherit no topics by design, so they are a non-issue.
One genuine oversight: Trading-View, a 2026 repo of my own with 5 stars and no topics at all.

Those 2021 repos are not embarrassing - 2021 me was learning to push code at all. But they drag on the
profile: a visitor who lands on the repo list sees the last rows of a table of silence.

The rot clustered, but not perfectly - which is the more honest finding. Of those ten topic-less repos, five
had no description and two had no license GitHub could detect. Those two lists overlapped without being the
same list, so "fix the plumbing" turned out to be per-repo work rather than one bulk operation.

And one finding genuinely stung: the repo with the most stars - 18, plus those 12 forks - had no LICENSE
file. Which means, legally, it was all-rights-reserved, even though I wrote it to be copied. Twelve people
forked a strategy they could not safely reuse. If you publish anything, put the license in before you tell
anyone about it; MIT takes ten seconds and its absence quietly suppresses exactly the reuse you wanted.

The worst one, though, was Thar - a 2021 Java repo that GitHub has had blocked for sensitive_data since
August 2021. No description, no license, and the file view returns a block notice. I genuinely do not
remember what is in it. Whatever it was, it has been sitting there flagged for four years while I worried
about whether my Pine Script linter had enough topics. Check your blocked and flagged repos first; that is the
metadata that matters.

What I fixed, and what is still broken

Done, last week:

Real search-term topics merged into the flagship repos (read-then-merge, because that endpoint replaces).
Descriptions added to the four old repos that had none, and MIT files on BankNIFTY-Golden-Ratio-Strategy, Django-based-stock-trading-platform and real-time-chat, credited to the GitHub handle rather than a personal email. That is 24 of 26 licensed; the two that are not are a fork (which is not mine to license) and the blocked repo below.
A dev.to link in the profile README and in three flagship READMEs, so the write-ups and the code point at each other.

Still broken, and I am saying so rather than editing this post later:

Thar stays blocked until I decide to delete it - which is irreversible, so it waits for a clear head. Twenty-four of 26 repos licensed is fine; one repo I cannot open is not something a badge can hide.
CI on Research-Copilot-Pro and tradingview-chartsense. Four of six flagship repos have it; two do not.
A hosted demo path for the repos that need one, longer READMEs for the strategy repos, and a decision on whether each 2021 relic is archived or actually maintained.

If you maintain open source in a niche where the users are not developers - finance, design, ops, healthcare -
what has actually moved your stars? I am specifically looking for the ones that were not "write a better
README". And if any of this is useful to you,
the profile is here; every repo I own and can open is MIT, so forks, issues and
"this exe does not run on my machine" reports are all equally welcome.

Vision models fake precision on charts - so I made every number carry its source

Khushal Jain — Tue, 27 Oct 2026 05:46:32 +0000

Ask a vision model to read a chart and it will tell you "RSI is at 71.4". Confident, specific, and - most of
the time - invented. Multimodal models are very good at the shape of a technical narrative and terrible at
the arithmetic behind it. They will also happily agree with whatever you pasted, because agreeing is the
statistically safe answer.

I wanted the read anyway - screenshots are the only format a chart exists in when you are mid-session - so I
built ChartSense around one rule: the model never gets to
be the source of a number it can be wrong about silently.

Local-first Next.js, MIT, your API key only ever goes to the provider you choose. Here are the three mechanics
that enforce that rule.

1. Every value carries its provenance

Each reading in the output is tagged:

calculated - computed by the app from candles you pasted
read - actually legible off the screenshot (the axis labels, the legend, the LTP)
estimated - interpolated by the model, and always printed with a ~ so you cannot mistake it for a reading
no basis - the model wanted to say something and had nothing to say it from

That last category is the uncomfortable one, and it is the reason this is not just a prompt wrapper. A model
that is allowed to output no basis produces noticeably fewer confident fabrications, because the schema gives
it an honest exit. Here is a trimmed real output from a Gemini read of a NIFTY 50 5-minute chart:

NIFTY 50 · 5m · LTP 22395.0
Verdict: Strong Sell (TradingView gauge 15/100) · Signal clarity 78/100 — how clean the read is, not the odds of profit

Nifty 50 is in a firm intraday downtrend after breaking below the 22474.7 breakdown level. Price continues to
print lower highs and lower lows with all key moving averages sloping overhead.

• Support: 22355.5 and 22305.6
• Resistance: 22474.7, 22576.7 and 22719.9

   +15 Moving average alignment: Price is trading well below all estimated short and intermediate moving averages.
   +15 Trend strength (ADX): ADX is at 40.28 with DI- dominant at 27.4, indicating a strong downtrend.
    -5 Oscillator agreement: RSI has dipped into oversold territory (28.25), warning of potential short-term pullbacks.
   -10 Signal freshness: The sell signal originated at 22583.85 and the move is already quite extended.

• Trigger: Rejection on a retest of 22440.0 - 22474.7  • Invalidation: 22500.0  • Target: 22355.5  • RR: 2.3:1

Note the second clause on the clarity line: how clean the read is, not the odds of profit. A score that
looks like a probability will get treated like one.

2. Paste candles, and the maths stops being AI

lib/indicators.ts is plain TypeScript: SMA, EMA, RSI, MACD, Stochastic, ADX and ATR. When you paste OHLCV
data alongside the screenshot, those get computed from the data and overwrite whatever the model guessed.

So the same chart produces two different quality of answer:

screenshot only → levels and readings are read or estimated, and the output says so
screenshot + candles → the moving averages and oscillators become calculated, and the narrative is pinned to numbers you can re-derive yourself

This is the cheapest reliability trick I know for anything vision-model-shaped: let the model do what it is
good at (describe structure, name the trend, assemble a plan) and take away the keyboard for anything with an
equals sign.

3. The confidence score is code, not vibes

If the model is allowed to return its own confidence, it returns what you would like to hear. So the field it
returns is only a suggestion - the server recomputes it from the factor list:

if (analysis.confidenceFactors.length > 0) {
  const summed = 50 + analysis.confidenceFactors.reduce((total, factor) => total + factor.points, 0);
  analysis.confidence = clampNumber(summed, 5, 85, analysis.confidence);
}

Base 50. Capped contributions per factor. De-duplicated by label, so a model that lists "strong trend" three
times in different words does not get paid three times:

const confidence = factors.length
  ? clampNumber(50 + factors.reduce((total, factor) => total + factor.points, 0), 5, 85, analysis.confidence)
  : analysis.confidence;

And the clamp is the part I would defend hardest: 5 to 85, never higher. One screenshot can never be
certain, and a score that can reach 100 trains people to stop reading the reasons. Every individual factor is
bounded too - e.g. oscillator agreement:

points: clampNumber(((agree - against) / (agree + against)) * 20, -10, 20, 0),

The same idea runs the gauge: clampNumber(50 + lean * 50, 0, 100, 50), and if nothing scored, it returns
{ index: 50, verdict: "neutral" } instead of guessing a direction. Neutrality is a real answer, and code that
has no path to it will lie to get out of it.

There is also an audit trail by construction: confidenceReason prints the arithmetic - how many factors went
into the base of 50, how many of them the app scored from your candles, and which factor was strongest and
weakest. If you disagree with a number, you can find the line that produced it.

No news. No fundamentals. No predictions. Levels come from the chart or your data, and every plan ends with
wait for clear price confirmation.

Run it locally (the security shape)

npm install
npm run dev      # http://localhost:3000

Click Connect AI keys, paste one key - Grok, OpenAI, Gemini or OpenRouter - hit Test key, then Save
keys. No key yet? Demo mode still runs the real indicator maths on candles you paste.

Three deliberate decisions, since this is a tool that holds an API key:

keys are stored in ~/.chartsense, outside the project folder - copying or publishing the source can never carry one
localhost is open by design; any other host is refused until you set CHARTSENSE_ACCESS_TOKEN
every route has per-IP rate limits plus body, image and input validation (details in SECURITY.md)

Local-first also means the privacy claim is structural rather than promotional: there is no account, no
telemetry, and no server of mine. Your screenshot goes to the provider you keyed in, and nowhere else.

What it still gets wrong

It is a single-screenshot read: no multi-timeframe confluence beyond what is visible, and no tick data, so a
level that would need the order book to validate is not something this can give you. The estimated tag is
honest, but honest wrong numbers are still wrong numbers - which is exactly why pasting candles changes the
quality of the answer so much.

Where do you draw the line between letting a model interpret and letting it compute - and has anyone actually
gotten a vision model to read a chart's axis scale reliably without feeding it the underlying data?
Repo: 85599/tradingview-chartsense, MIT.

There is no official grammar for Pine Script, so I wrote a small one

Khushal Jain — Mon, 26 Oct 2026 07:17:55 +0000

If you have ever tried to lint, format, or diff TradingView Pine Script programmatically, you have hit the same
wall: there is no official grammar. TradingView does not publish or maintain a tree-sitter grammar or an
ANTLR grammar for Pine Script. Every parser you can find is third-party, and third-party grammars for a
language that changes with each Pine version go stale quietly - they just stop matching real-world code.

I could not find anything to put in a CI pipeline for my indicators, so I wrote
PineSprout (pip install pinesprout, Python 3.12+, Linux/macOS/Windows,
MIT). This post is about the parser decision and the linter rules, which are the two parts worth stealing.

The whole toolkit in one CLI

pinesprout generate "<prompt>"     # Claude-powered, from natural language
pinesprout template new ema-cross-indicator --title "My EMA Cross" -o my_indicator.pine
pinesprout lint my_indicator.pine
pinesprout format my_indicator.pine --write
pinesprout analyze my_indicator.pine
pinesprout optimize my_indicator.pine
pinesprout explain my_indicator.pine
pinesprout upgrade legacy_strategy.pine --to 6 --write
pinesprout docs my_indicator.pine --format markdown -o DOCS.md
pinesprout readme my_indicator.pine -o README.md
pinesprout report my_indicator.pine

Every command supports --json. That is not a nicety - it is the reason the tool is usable outside a terminal.
Machine-readable output means the linter can gate a PR, the formatter can run in a pre-commit hook, and the
upgrader can be scripted across a folder of old v4 scripts.

Why a hand-rolled lexer instead of tree-sitter

Two options existed: depend on an unofficial grammar, or write a small one. I wrote the small one.

pinesprout/core/
├── lexer.py        # regex-based Pine Script tokenizer
├── parser.py       # lightweight AST builder
├── ast_nodes.py    # typed AST node definitions
├── formatter.py    # deterministic code formatter
├── linter.py       # static analysis rule engine
├── analyzer.py     # structural / complexity analysis
├── optimizer.py    # refactor suggestions
├── upgrader.py     # v4 -> v5 -> v6 migrations
└── version_rules.py# deprecated symbols & migration rules

The deliberate constraint: the output shape mirrors a tree-sitter concrete syntax tree - typed nodes,
line/column spans, a children list. Nothing downstream (formatter, linter, analyzer, optimizer, upgrader)
knows or cares how the tree got built.

That buys two things:

It handles real-world Pine's edge cases without waiting on a third party's release cycle.
If TradingView ever ships an official grammar, it drops in behind parser.py and no consumer changes.

A regex tokenizer is not "proper" compiler design, and I am fine with that. It is ~two files, dependency-free,
well tested, and it removes the only thing in the project I could not control.

The lint rule that pays for itself: repaint risk

Pine's most expensive class of bug is not a syntax error, it is an indicator that looks brilliant historically
and lies in real time. Repainting. So the linter has a dedicated category (repaint-risk) driven by an actual
list in version_rules.py:

REPAINT_PRONE_FUNCTIONS = {
    "request.security",
    "security",
    "ta.valuewhen",
    "ta.barssince",
    "input.source",
}

request.security() on a higher timeframe without a lookahead guard, ta.valuewhen() reading a value that has
not settled on the real-time bar - when one of these shows up in a plot path, the linter flags the line and
explains that the script can repaint historical values on lower timeframes, with a separate note for the case
where the repainting is intentional. There is a matching PERFORMANCE_SENSITIVE_FUNCTIONS set (ta.sma,
ta.ema, ta.rsi, ta.atr, ta.stoch, ta.macd, ta.highest, ta.lowest) because calling a rolling
series inside a loop is the second most common way to make a script crawl.

Alongside those, the rule set covers unused variables, deprecated syntax, and general performance issues - the
four things that actually make an indicator script unmaintainable. Because the rules are a rule engine, not a
pile of regexes, you can add your house style without touching the core:

# .pinesprout/plugins/my_rules.py
from pinesprout.plugins.base import PineSproutPlugin, LintRule
from pinesprout.core.linter import LintIssue, Severity, LintCategory

class NoMagicColorsRule(LintRule):
    name = "no-magic-colors"

    def check(self, source: str) -> list[LintIssue]:
        issues = []
        for i, line in enumerate(source.splitlines(), start=1):
            if "color=color.red" in line:
                issues.append(LintIssue(
                    line=i, severity=Severity.INFO,
                    category=LintCategory.STYLE,
                    message="Avoid hard-coded colors; expose as an input.",
                ))
        return issues

class MyPlugin(PineSproutPlugin):
    name = "my-org-rules"
    version = "1.0.0"

    def lint_rules(self):
        return [NoMagicColorsRule()]

PLUGIN = MyPlugin()

Plugins load from a local .pinesprout/plugins/ folder or through a pinesprout.plugins entry point, so a team
can version its own rule pack as a package.

Upgrading v4 → v5 → v6

Pine's version migrations are mostly mechanical renames, and they live as data rather than as if-statements in
the upgrader:

# `study()` was renamed to `indicator()` in Pine v5.
# `security()` moved to the `request.*` namespace in v5.   -> request.security(
# `strategy.performance` -> strategy.closedtrades.* accessors introduced in v6

A regex rewrite table plus typed DeprecatedSymbol entries is honestly enough for a language whose breaking
changes are namespace moves. upgrade --to 6 --write applies them, and it is the command I reach for most,
because a v4 script you still believe in is worth more than a rewrite you will never start.

The Studio, if you prefer a browser

streamlit_app.py wraps the CLI: describe a strategy in plain English (AI-generated), pick a template, or paste
your own script, then lint / format / analyze / optimize / explain / upgrade / document it with one-click
downloads.

The bit that is genuinely fun is the Template Builder: 25 indicators (trend, momentum, volatility, volume) ×
4 signal patterns × 3 risk-management styles, with every length, threshold and stop-loss % adjustable -
thousands of distinct scripts, all of them lint-clean because they come out of the same formatter the CLI uses.
There is also a live scrolling ticker (NIFTY 50, SENSEX, BANK NIFTY, commodities via yfinance) and an NSE-style
index watch plus a TradingView global heatmap for the market-browsing side.

pip install -e ".[dev]"
streamlit run streamlit_app.py

Guardrails worth stating

PineSprout only ever operates on Pine Script source you provide. It does not fetch, decompile, or bypass
protection on TradingView's invite-only or protected scripts. Anyone building tooling in this space should say
that out loud in the README rather than let people assume - it is the difference between a useful tool and a
ToS incident.

Dev loop is pytest, ruff check ., mypy pinesprout, and CI runs on every push.

What's the buggiest pattern in your Pine scripts - repainting on historical bars, or security() look-ahead?
And if you maintain a TradingView repo, do you run any lint/format gate on .pine files today? The toolkit is
85599/pinesprout on PyPI and GitHub, MIT - the parser is the part I would
most like someone to disagree with.

Windows has a free OCR engine. I pointed it at my broker's position grid.

Khushal Jain — Mon, 26 Oct 2026 07:02:16 +0000

Every options trader I know keeps their book in an Excel sheet they update by hand. Strikes, quantities,
premiums, and a row of "what if NIFTY is here at expiry" columns that they retype every time the market moves.
The sheet is the honest part of the process - it is the only place where the size of the risk is written down.
And it is also the part nobody wants to maintain.

So I built a tool around one idea: the screenshot your broker already shows you is the input format.

Drop it in, get back a workbook with live premiums, live P&L, and a scenario grid that recalculates itself.
No broker login, no API key, and the screenshot never leaves the machine.

The repo is nifty-desk (MIT, Python, Windows). This post is about the
two parts that were actually hard: reading the screenshot, and getting the numbers to stay live.

The trick nobody tells you about Windows OCR

Windows ships an OCR engine - Windows.Media.Ocr, the same one the Photos app uses. It is free, it runs
locally, it has recognizers per language, and it needs no install. The catch is that it is a WinRT API, so
the practical way to reach it from Python is to shell out to PowerShell.

Here is the real call from ocr/winocr.ps1:

Add-Type -AssemblyName System.Runtime.WindowsRuntime
Add-Type -AssemblyName System.Drawing

[Windows.Media.Ocr.OcrEngine,Windows.Foundation.UniversalApiContract,ContentType=WindowsRuntime] | Out-Null
[Windows.Graphics.Imaging.BitmapDecoder,Windows.Foundation.UniversalApiContract,ContentType=WindowsRuntime] | Out-Null

$engine = $null
$langs = @([Windows.Media.Ocr.OcrEngine]::AvailableRecognizerLanguages)
$pick = $langs | Where-Object { $_.LanguageTag -eq $LanguageTag } | Select-Object -First 1
if ($null -eq $pick -and $langs.Count -gt 0) { $pick = $langs[0] }
if ($null -ne $pick) { $engine = [Windows.Media.Ocr.OcrEngine]::TryCreateFromLanguage($pick) }

AsTask + a small Await helper turns the WinRT async calls into something a script can wait on - that is
the only way to drive WinRT from Windows PowerShell without writing a compiled app.

Upscale before you recognise. This was the single biggest accuracy win. The ODIN terminal draws its
position grid in a roughly 9px font. At 1:1 the engine silently drops characters, and a dropped character in
a strike price is not a typo - it is a different trade. So the image goes through a high-quality bicubic
resize at 2x first:

if ($Scale -ne 1.0) {
  $src = [System.Drawing.Image]::FromFile($Path)
  $dst = New-Object System.Drawing.Bitmap ([int]($src.Width * $Scale)), ([int]($src.Height * $Scale))
  $g = [System.Drawing.Graphics]::FromImage($dst)
  $g.InterpolationMode = [System.Drawing.Drawing2D.InterpolationMode]::HighQualityBicubic
  $g.DrawImage($src, 0, 0, $dst.Width, $dst.Height)
}

Twenty-two lines of PowerShell replaced what would otherwise be a cloud OCR bill and a privacy problem.

Parsing: read the header, never the column position

A grid is not a text file. My first instinct was to split each row on whitespace and index into it, which
works exactly once, on my screen, on my broker layout.

The version that ships reads the header row and only uses the columns that header actually spells out.
If a broker hides three columns, Net Qty, Market Price and MTM still land in the right cells, and nothing is
guessed at. Two other things earned their complexity:

CE/PE recovery. When OCR loses the option type on a leg, recover it from the sibling leg of the same strike, or from the live NSE price for that instrument. Do not fail the whole row for one dropped glyph.
Lot size auto-detection. Quantities in the grid are in lots; the workbook needs contracts. The tool infers the lot size from the quantity values instead of asking you to type it.

Then there is the sign convention, which is the part that quietly ruins P&L sheets:

The terminal shows a short as a negative Net Qty. The workbook writes a SELL as a positive Qty with a
Side column, and the scenario grid reads sell-positive / buy-negative so the formulas come out right.

That convention is stated in the README and printed in the sheet, because the alternative is a book that looks
correct and is wrong by twice the position.

Keeping it honest: live prices, not a snapshot

A parsed screenshot goes stale in about four minutes. So each workbook pulls premiums and spot from the public
NSE option chain - no key, no subscription - and refreshes every 5 minutes.

The output is one block per expiry, laid out like the sheet a person would have made by hand:

a full STRIKE / QTY / PREMIUM ladder at a 50-point gap, including the zero rows, so you can type an unstated position straight into the sheet
CP IF <spot> scenario columns at a 100-point gap, each one a live IF formula - edit a quantity or a rate and the whole grid recalculates
CE section, PE section, and a NIFTY futures line that is always present even when the screenshot has no future, so you can add one yourself
a grand TOTAL, with each expiry printing on its own page

This is real generated output, not a mockup:

The line I care about most is the CP IF grid. It answers "what happens to my book if the market sits exactly
where it is - or moves 500 points against me" before the market answers it for you.

Shipping a .exe to people who do not have Python

The traders who wanted this are the least likely to run pip install. So there is a Windows binary built with
PyInstaller (build_exe.bat in the repo does it in one command if you would rather build it yourself).

Two things I got pushed on, and handled deliberately:

"Windows protected your PC." That is SmartScreen, because the exe is unsigned - code-signing certificates
cost money. The README says exactly that, tells you to build from source if you prefer, and the whole source is
right there. I would rather explain the warning than pay for a certificate I cannot honestly make mean more
than it does.

"It read 0 rows." Silent failure is the worst outcome for a parsing tool, so the activity log now names the
cause:

"none of them formed the ODIN position grid" - header row was cropped out of the screenshot
"does not follow the standard ODIN column layout" - columns rearranged or hidden in that terminal
"no text at all" - the English OCR recognizer is not installed (Settings → Time & Language → Language)
"every row was filtered out" - grid parsed fine, untick NIFTY rows only or Hide fully closed

Each message maps to an action. Debugging became a checkbox instead of a support conversation.

Run it

No-Python path: grab NiftyDesk-win64-v1.0.4.zip from the
latest release, unzip, double-click NiftyDesk.exe.
Workbooks land in an output folder next to it.

From source:

pip install -r requirements.txt
python server.py     # http://127.0.0.1:8765/

Privacy note, stated in the code's shape rather than a policy page: the only network request the tool makes is
the public NSE quote call. Positions and screenshots stay local. And it is a risk-visibility and bookkeeping
tool - it places no orders, promises no returns, and is not investment advice.

What I would do differently

Wire the same pipeline to the other popular terminals' layouts (right now it is built around ODIN's grid), and
push the scenario grid to options other than NIFTY, since the parsing is symbol-agnostic but the defaults are not.

Which broker's position grid do you fight with every week - and what does your Excel sheet refuse to tell you
about your own risk? If you want the workbook itself, the repo is
85599/nifty-desk. It is MIT, so fork it, break it, or hand me a
screenshot layout it chokes on.

No API key, no data vendor: pulling live NSE + BSE option chains in Python

Khushal Jain — Mon, 26 Oct 2026 07:00:55 +0000

Retail option analytics in India has a data problem. Licensed feeds cost real money, brokers gate their API
behind accounts, and the free tools that exist hand you a wall of numbers and stop there. Meanwhile the
exchanges publish option chains on their own public websites - which anyone can read, and which nobody will
support you when it changes.

I built Strike & Hedge on exactly those public endpoints: live
NSE and BSE chains, Black-Scholes Greeks solved locally, PCR, max pain, OI walls, expected move, and a
rule-based trade plan. No API key. MIT. 45 offline tests.

This post is the field notes - the parts that are not in any tutorial because they only show up when a
government exchange quietly retires an endpoint on a Tuesday.

The anti-bot wall comes first

Both exchanges sit behind Akamai. Plain requests gets 403s, and no amount of header cosplay fixes it,
because the TLS handshake itself is the fingerprint. What works:

# copilot/nse.py, copilot/bse.py
# curl_cffi impersonates a real Chrome TLS/JA3 profile; warm cookies from the homepage first
from curl_cffi import requests as session   # falls back to `requests` if curl_cffi is unavailable

Keep the fallback. curl_cffi is a compiled dependency and it will not install on some machine you care
about; the tool should degrade to "this source did not load" rather than "this tool does not start".

Endpoints are a moving target, so write down what moved

The specific things that bit me, as of October 2026:

Need	What is actually there
NSE chains	`option-chain-v3` + `option-chain-contract-info`. The old `option-chain-indices` endpoint is retired
BSE (SENSEX) chain	`DerivOptionChain`, which wants the expiry formatted as `15 Oct 2026`
BSE expiry list	not published. Upcoming Thursdays get probed until one answers
NSE futures quotes	gone. `quote-derivative`, `quote-v2` and `last-price-v5` all 404
FINNIFTY daily history	niftyindices.com - Yahoo delisted `^CNXFINANCE`, and NSE's own chart API returns empty for every index
FINNIFTY intraday	no public source exists

Two of those are lies rather than gaps, and they are the dangerous kind:

BSE reports Absolute_Change_OI as 0 intraday. Not "flat" - not published yet. Rendered as a real number, it tells you writers are not active when the exchange simply has not said.
BSE sends no IV. So IV gets solved from the premium. And when a deep-ITM quote will not solve, the row shows —. A solver forced to always answer will happily hand you a 500% IV, and the Greeks downstream will believe it.

When a number cannot be had, derive it and label it

With NSE's futures quote endpoints retired, a futures card has no honest price. The tool derives the futures
level from put-call parity on the ATM strike - from copilot/chain.py:

def synthetic_futures(chain, r=0.065):
    """Futures level implied by put-call parity on the ATM strike: F = K·e^(-rT) + CE - PE."""
    ltp = k * math.exp(-r * t) + c - p
    ...
    "source": "put-call parity on ATM strike",

Then three things matter more than the formula:

the card is labelled as derived, and says it can be tens of points off your broker's price
the parity basis is never scored as a signal - last-traded option quotes put that much noise into it
there is no futures OI or buildup anywhere in the score, because that data does not exist

Same principle for the FINNIFTY intraday panel: it falls back to recent daily bars and says that it did.
Silent fallback is where dashboards go to die. A tool that narrates its own blind spots gets used; one that
hides them gets believed, and then gets abandoned.

And at the close: signals come from a chain snapshot, not tick data, so near 15:30 IST the settled expiry is
dropped. Otherwise you get a ₹0.05 premium with nonsense Greeks, printed as if it were actionable.

Split the deterministic engine from the LLM

The pipeline is deliberately two halves:

 NSE option-chain-v3 ─┐
 BSE DerivOptionChain ─┤→ chain.py    normalise + Black-Scholes Greeks / IV
 niftyindices.com ─────┤      ↓
 Yahoo quotes/VIX ─────┘  analytics.py   PCR · max pain · OI walls · expected move
                               ↓
                          signals.py     bias + entry / stop / target / exit / lots
                               ↓
                    dataflows.py → agents.py → graph.py    (optional AI desk)
                               ↓
                          reporting.py   markdown report + decision log

signals.py needs no key at all and produces BULLISH / BEARISH / RANGE / AVOID with a score and
written reasons, plus a concrete plan: instrument, entry, stop, target, R:R, lots, max loss in ₹, exit rule.
Stops and targets come from ATR and OI walls on the underlying, converted to premium through delta - so
they react to real price geometry instead of a fixed percentage. Never naked selling: bullish → BUY CE beyond
ATM (plus a futures long on the derived level), range → defined-risk credit spreads, sell near the OI wall,
hedge two strikes further out.

The risk model has one behaviour I am stubborn about:

Type in capital and risk % - if one lot already risks more than your capital × risk %, the tool refuses
to round up. It tells you the position does not fit, instead of quietly showing "1 lot".

The AI desk (chain / volatility / flow / news analysts → bull vs bear debate → risk → portfolio manager) sits
on top of the same numbers, across 8 backends: Anthropic, OpenAI, Gemini, DeepSeek, Groq, OpenRouter,
Ollama (fully local, no key), or any OpenAI-compatible endpoint. Two guards make it behave:

Grounding check. The LLM is given the rule engine's numbers. If its quoted entry is far from the live premium - the classic mistake of stating a strike as a premium - the rule-engine level is shown instead, with a warning.
Decision log. Every AI call is scored later against the underlying's actual move with a hit/miss flag, and those lessons feed into later runs. An agent loop with no outcome tracking is a random number generator with good grammar.

Here is the engineering ask buried in that design: keep the rule engine separate. If you only want chains,
Greeks and signals, delete agents.py and graph.py entirely and the rest still works.

Make failure debuggable, and make tests offline

When a chain will not load, the answer is one request away:

curl http://localhost:8000/api/diag/NIFTY     # what each price source actually returned

Endpoints change and rate limits bite without notice, so a debug endpoint that shows raw per-source responses
turns "it's broken" into "NSE is 403ing and BSE is fine".

The test suite is offline on purpose - 45 tests, no network, no keys, so CI stays green whether or not an
exchange is having a day:

python -m pytest tests -q
python tests/ui_harness.py    # full UI on synthetic data → http://127.0.0.1:8765

That synthetic harness is the other half of the trick: it lets a reviewer see the entire UI without a broker
account, a key, or market hours. No frontend build step either - web/ is plain HTML/CSS/JS served by FastAPI.

git clone https://github.com/85599/Strike-and-Hedge.git
cd Strike-and-Hedge && pip install -r requirements.txt
uvicorn server:app --port 8000     # open http://localhost:8000

The part you should read before you scrape

This is a scraper, not a licensed feed. It reads public endpoints at request time and caches briefly; it is
not a redistribution right, and exchanges can change terms whenever they like. Lot sizes in the repo are
fallbacks - SEBI revises them, so verify with your broker. And publishing buy/sell calls publicly can
require SEBI Research Analyst registration, which is worth knowing before you share output anywhere. It is an
educational research tool, not investment advice, and not issued by a registered research analyst.

Which Indian exchange endpoint has wasted the most of your afternoon - and is anyone tracking a working
futures-quote source now that NSE's are 404ing? If you want the whole pipeline to read or break:
85599/Strike-and-Hedge. PRs for endpoint changes, lot sizes and
strike steps are the ones I merge fastest.