# Shivansh Kalra > Software engineer and CS student at Shiv Nadar University (B.Tech, graduating May 2027). I build things fast, then measure whether they actually work: AI systems and evals, systems and security tooling, and quant research. Previously SDE at Attack Capital (YC-backed), founding engineer (contract) at Pactle. Shipping software since 2021. - Email: shivanshkalra796@gmail.com - GitHub: https://github.com/shivansh193 - LinkedIn: https://linkedin.com/in/shivansh-kalra - Site: https://shivansh-kalra.vercel.app - Resume (PDF): https://shivansh-kalra.vercel.app/Shivansh_Kalra_Resume.pdf - Open to: founding-team roles, research, and conversations worth having. Education: Shiv Nadar University, Greater Noida, India. B.Tech in Computer Science, Aug 2023 to May 2027. ## Experience ### Attack Capital (YC) · HealOS: Software Development Engineer May 2026 – Aug 2026 · Remote - Built EHR automation on network-layer replay (Browserbase + Playwright). Instead of scraping the UI, it replays the EHR's own internal API calls. Integration build time went from weeks to a few hours, and the approach was adopted company-wide. - Implemented TOTP from RFC 4226/6238 (HMAC-SHA1) from scratch so automated workflows could get through authenticator prompts. Also adopted company-wide. - Led the technical side of taking HealOS (50+ US companies) into the UAE, building the integration layer for regional compliance and partner onboarding. - Found and reported 3 critical security vulnerabilities in an EHR platform used by 40%+ of US healthcare professionals. - Tuned ElevenLabs model config, chunk scheduling and streaming for production voice agents across three portfolio products. Stack: Playwright, Browserbase, Node.js, Next.js, Postgres, ElevenLabs ### Pactle: Founding Software Engineer Feb 2026 – Apr 2026 · Remote - Spent my first few weeks on the legacy platform learning the domain, then moved to the generalised product. - Built its frontend from the first commit and co-built the backend: lead management, SLA tracking and round-robin assignment. - The RFQ-to-quote engine I built as my pre-hire assignment (fuzzy search, multi-algorithm scoring, Tesseract OCR for scanned RFQs, approvals, multi-currency) was integrated into Pactle's product. Stack: Node.js, Next.js, Postgres, Redis, Docker, Tesseract ### Thinkly Labs: Full Stack Engineer Nov 2025 – Jan 2026 · Remote - Built North, a content generation engine, from scratch: DB schema, API design and frontend. - Worked with the founding team on distributed system architecture decisions. Stack: Next.js, Node.js, Postgres, Redis ### Frontrunner: Software Development Intern May 2024 – Aug 2024 · Remote - Shipped 2 full-stack apps (React, Node.js, MongoDB) in 8-week sprints, in a team of 5+ engineers. - Set up CI/CD with GitHub Actions, cutting manual deployment work by 70%. Stack: React, Node.js, MongoDB, GitHub Actions ### Vidya Verse: Founding Engineer & Course Instructor Apr 2021 – Sept 2021 · Remote - Built the whole platform as founding engineer. My first paid engineering role, at 17. - Taught and recorded the company's first course on blockchain, and wrote the book that went with it. Stack: React, Node.js, MongoDB, Firebase ## Projects ### Invariant (2025 →) v4 · live · live: https://invar-v4.vercel.app Stack: Rust, Python, TypeScript, Next.js, Playwright, tree-sitter, FastAPI, React Flow My startup. Point it at an app and it scans three ways: a Playwright pass over the public URL, an offline analysis of a recorded login session, and a call graph of the codebase with 8 graph-level analyses. Findings stream into a dashboard and land on GitHub PRs as comments. 30 founder conversations so far, 12 founders validated it. Reads your code and your running app together, so a finding shows up with both halves of the story. I'm building Invariant solo. It started as a static analyzer and grew into three scanners feeding one dashboard: a public-URL scan, an authenticated session recorder, and a codebase call graph. The CLI is Rust, the scan engine is Python, the dashboard is Next.js. Why: Every team I worked with ran a pile of tools that didn't talk to each other, and none of them knew how the code related to the deployed app. I wanted one place where a slow endpoint, the query behind it and the line that wrote it show up together. Components: - Web scanner (Playwright + Python): Checks a public URL across 7 categories, including stack fingerprinting from live traffic, and produces a report you can share. - Call graph engine (tree-sitter + Python AST): 9 node types and 10 edge types. On top of the graph it runs 8 analyses, like duplicate fetches, unbounded fan-out, circular dependencies and endpoints with no auth. Progress streams over SSE. - Rust CLI (Rust + Chrome DevTools Protocol): scan, push, a terminal report, device-flow login, and record/analyze: capture an authenticated browser session and analyze it offline. - Graph view (React Flow + dagre): Four views of the same graph: topology, modules, a request trace and blast radius. Replaced my first D3 version in August. - clipy (Rust, open source): The session-replay part, pulled out as a standalone open-source tool. Key facts: - 9 node types · 10 edge types · 8 graph analyses - Self-scan: 157 files, 126 findings in 1.8 s - 30 founder conversations · 15 demos - Live: invar-v4.vercel.app ### HippoVoice (2026) OSS · benchmarked on LoCoMo · code: https://github.com/shivansh193/hippovoice Stack: Python, PyTorch, Qwen3-4B, Qwen2.5-Omni, Whisper, ChromaDB, NetworkX Long-term memory for voice companions. Memories fade unless they matter or get recalled, and retrieval walks an association graph instead of only matching vectors. On LoCoMo it ties a Mem0-style baseline on recall (29.47% vs 29.11%) and pulls in a third as much irrelevant context. Runs end to end behind Qwen2.5-Omni. Memory that forgets the way people do. Breakfast three weeks ago fades; the thing you mentioned once and cared about sticks. HippoVoice started as a demo I built for Rumik and turned into a proper research project. It combines Ebbinghaus-style decay, emotion-weighted salience and HippoRAG-style graph retrieval. I reimplemented Mem0, A-MEM and a Zep-style baseline on the same harness, because published LoCoMo numbers use different models and lenient LLM judges, and I wanted a comparison I could trust. Why: Plain RAG keeps every turn forever and retrieves by similarity. That's fine on a small benchmark and gets noisier the longer a companion runs. I wanted memory that stays clean as it grows, and a test setup honest enough to tell me if it does. Components: - Decay and salience (Python): Ebbinghaus forgetting curves with a decay multiplier per emotion. Salience drops every turn unless something boosts it. - Graph retrieval (NetworkX + ChromaDB): Vector and BM25 seeds, then a one-hop walk over the association graph, scored by relevance blended with salience. - Fair baselines (Same harness for everyone): Mem0-style, A-MEM-style and Zep-style systems run on identical infrastructure with LoCoMo's published token-F1 scorer. - Voice pipeline (Qwen2.5-Omni + Whisper): The same memory behind an audio-to-audio model. A fact said in one spoken turn is recalled correctly after an unrelated turn in between. Key facts: - LoCoMo, 1,540 questions: 29.47% vs 29.11% for Mem0-style at matched settings. A tie, and I report it as one - Contamination test: 10% irrelevant context retrieved vs 30% for Mem0-style and plain RAG - Audio-to-audio: 25.81% avg F1 on a 40-question run with zero errors - My early lead over Mem0 was a top_k mismatch. Re-running the baseline caught it; it's written up in BUGS.md ### ShelfSense (2026) Amazon Dev Hackathon · Ring track · live: https://www.youtube.com/watch?v=wqKQZixrNSY Stack: Python, FastAPI, aiortc, PyTorch, Qwen2.5-VL, SigLIP, YOLO11-pose, AWS EC2 A shop's Ring camera keeps the bill: it sees what leaves each shelf, names it from the shop's own photos, tracks stock, and leaves anything unsure for a person to check at the exit. Product naming is 98.4% correct within a shelf of 5 products; finding takes on handheld clips is still weak (2 of 8). Built solo for the Amazon Developer Hackathon (Ring track). A shop's Ring camera keeps the bill, and leaves anything unsure for a person to check at the exit. When a hand goes into a shelf zone empty and comes out holding something, that's a take, and the product is named by matching the hand crop against the shop's own photos. Put-backs flag the matching line. Uncertain lines are marked verify at exit; the system only adds or flags lines, only a person removes one, and every decision is logged. Shoppers watch their bill live from a per-session link, and between visits the camera reads how full each shelf is for restock alerts. Why: Small shops already have a camera. The goal was billing and stock from that camera without ever guessing with someone's money. Components: - Funnel (YOLO11n-pose + ByteTrack, Qwen2.5-VL-3B, SigLIP): The cheap model on every frame (13-15 ms), one batched yes/no VLM question per shelf visit (~200 ms), and catalogue matching only on a take (49 ms), using only the products on that shelf. - vjev (open source, Apache-2.0): Turns VLM answers into typed, calibrated decisions. Boxes reach 86.3% Acc@0.5 on RefCOCO, and it abstains on 93.8% of absent targets. - Ring integration (Ring Partner API + aiortc): Device list, live view over WHEP pulled server-side (0.6-0.9 s setup, 1280x720 at 29 fps, about 10 fps analysed), the 30 s / 60 s live-view cap, HMAC-signed motion webhooks and account linking, tested on the Ring Developer Portal Playground. - Exit check and shopper view (FastAPI + vanilla JS): Staff see each flagged line's evidence and keep or remove it with a note; shoppers can tap Not mine. Key facts: - Naming: 98.4% within a shelf of 5 products (81 products, 500 queries); 70% on CCTV-quality crops - Shelf watch: AUROC 0.88 on 484 shelf crops; 82.2% on held-out shelves, catching 92% of empty gaps - Ring: 3 of 3 live WHEP sessions connected and analysed - Not there yet: 2 of 8 takes found on handheld clips (1 false) ### TillLess (2026) research · no public link Stack: Python, PyTorch, OpenCV, FFmpeg, ResNet-18, YOLO-pose Queue-free billing from the CCTV a store already has. It spots which shelf slot a shopper's hand takes from, maps the slot to a product, and has the bill ready by the exit; shoppers only scan what it's unsure about. The interaction detector hits 0.80 frame mAP on MERL Shopping, and training on degraded video cut accuracy loss on a bad camera from 0.27 to 0.07 mAP. Queue-free billing using the CCTV a store already has. TillLess watches which shelf slot each shopper's hand takes from, and the store's shelf map (planogram) turns that slot into a product. By the time the trolley reaches the exit, the bill is ready. Shoppers only scan items the system isn't sure about, and anything disputed goes to staff for a check, never automatic removal. It's software only, with no new cameras. It was the CCTV research groundwork for ShelfSense. Why: Checkout queues at Indian supermarkets come down to one thing: billing happens at the end. Amazon's Just Walk Out needs a store rebuilt around it. Most Indian stores already have CCTV, so I started there. The same camera layer can later handle stock alerts, loss prevention and live online inventory. Components: - Interaction detector (ResNet-18 + dilated temporal CNN): Frozen ResNet-18 features feed a dilated temporal CNN with a boundary head, so it catches when a hand takes from a shelf and when. 0.80 frame mAP on the MERL Shopping benchmark, with timing within ±0.5 s. - CCTV robustness (FFmpeg degradation sweeps): I swept bitrate, frame rate and resolution. Dropping to 8 fps costs almost nothing; resolution is what hurts. Training on degraded video cut the accuracy loss on a poor camera (230×170, 6 fps, 80 kbps) from 0.27 to 0.07 mAP. - Throughput (T4 GPU): About 14 real-time camera streams per T4, with a path to cheap in-store edge boxes. - Market work (Research): Teardowns of Just Walk Out, Zippin, Grabango (which shut down) and Wobot, Indian retail economics, and DPDP Act compliance. Key facts: - 0.80 frame mAP on MERL Shopping, timing within ±0.5 s - Poor-camera accuracy loss cut from 0.27 to 0.07 mAP - ~14 real-time streams per T4 GPU - Next: slot-level localisation on RetailAction, then real store pilots ### clipy (2026) OSS · Rust CLI · code: https://github.com/shivansh193/clipy Stack: Rust, Chrome DevTools Protocol, tokio, ChaCha20-Poly1305 Record yourself using a web app, and clipy works out which values flow between its API requests, which requests actually matter, and writes a Python script that replays the flow. One recording went from 25 requests to the 5 it needed. Built overnight, 33 tests, CI on Linux, macOS and Windows. Turns a browser session into a replay script that pulls fresh tokens from live responses. clipy drives Chrome over the raw DevTools Protocol, records every request, then works out the data dependencies between them. You get a runnable Python script, a Mermaid diagram of the flow and a short report. It's the open-source version of Invariant's session-replay scan. Why: At Attack Capital I automated integrations by replaying internal API calls instead of scraping the UI, and it cut the work from weeks to hours. I did the dependency tracing by hand every time. clipy is the tool I wanted back then. Components: - Recorder (Rust + raw CDP): Drives Chrome, Edge or Brave and follows new tabs, iframes and workers. It reads raw CDP events instead of a typed crate, so a new Chrome release can't break it. - Dependency analysis (Rust): Links a value in one response to the request that later uses it. The evidence bar scales with how random the value looks, so short ids and common words don't create fake links, and a response only counts if it finished before the request started. - Code generation (Python + requests): The replay reads tokens from live responses. CI checks out against a freshly restarted demo shop where every recorded token is already dead. - Secrets vault (ChaCha20-Poly1305 + OS keychain): Recordings are safe to commit. Secrets are sealed with a key that never touches the file, and --forget destroys the key. Key facts: - 25 recorded requests reduced to the 5 that mattered - 33 tests, CI on Linux, macOS and Windows - About 5.9k lines of Rust, built in one night - Deterministic: no LLM anywhere in the pipeline ### QuantEdge (2026) OSS · runs daily · code: https://github.com/shivansh193/quant-edge Stack: Rust, SQLite, SEC EDGAR, FRED, Gemini, GitHub Actions A quant research platform in Rust that I run every day. It picks stocks from momentum, fundamentals, insider filings and macro signals, backtests with a real cost model, and logs each day's picks to a hash-chained file before their outcomes are known, so I can't quietly tune results after the fact. Built around one rule: the only evidence that counts is a prediction written down before you know if it was right. QuantEdge has a point-in-time data layer, a multi-factor stock picker, a backtester and a forward-test log nobody can edit without it showing. Most of the effort went into making look-ahead bias impossible by construction. Why: Backtests always look good if you're allowed to fit them to the past. I wanted a setup where I couldn't fool myself, even if I tried. Components: - Signals (Rust + SQLite): Momentum, fundamentals z-scored within GICS sector (keyed to the actual SEC filing date), insider buying from Form 4, and macro. I tested GDELT and Reddit sentiment live and switched them off because they didn't hold up. - Natural-language strategies (Gemini): Write a strategy in plain English, like 'weight momentum 2x, ignore insiders for tech', and it becomes signal weights. - Backtester (Rust): Next-open fills, spread, slippage and square-root market impact, rank-IC checks, a drawdown circuit breaker, and VaR/CVaR reporting. The data layer can't return anything dated after the as-of date; SQL enforces it and Rust checks again. - Forward-test log (SHA-256 chain + GitHub Actions): CI logs the model's picks every trading day. Each entry carries the hash of the previous one, so editing or deleting history breaks the chain. Key facts: - 194 Rust tests, clippy in CI - NSE and US markets (live universe: 318 US stocks) - Point-in-time fundamentals and S&P 500 membership - Picks logged daily by CI into a hash chain ### Recourse (2026) LexHack 2026 · live: https://recourse-pearl.vercel.app · code: https://github.com/shivansh193/recourse Stack: TypeScript, Next.js, pdf-lib, Gemini Helps a California tenant file a small-claims petition to get a security deposit back. It interviews you in plain language, checks eligibility and fees against dated statute text, fills the official SC-100 form, and hands you a report showing where every claim came from. Built in about 39 hours for LexHack 2026. Legal paperwork where the model is never the one deciding the law. Recourse walks a self-represented tenant from a messy description of what happened to a filled SC-100 and a grounding report. Thresholds and fees are computed in code against dated statute excerpts. The model only extracts facts, checks them and parses sources you paste in. Why: Deposit disputes are simple on paper and miserable to file alone. A tool that hallucinates a filing fee is worse than no tool, so I kept the law in code and used the model only where it's actually good. Components: - Intake and pre-screen (Gemini): Plain-language intake. Evictions, lockouts and safety issues get routed to the court's self-help center or legal aid instead, with an override. - Rule checks (TypeScript): Eligibility and filing-fee tiers computed against statute text with dates, not asked of the model. - Self-verification (Structured output + code): The schema asks for evidence before the verdict, because structured output is generated in order and verdict-first let the model rationalize. A deterministic check overrides a 'supported' verdict when its own note contradicts it. - Form filling (pdf-lib): Fills the official SC-100 and generates a separate grounding report. Names are matched back to the source text after the model swapped one accented character. Key facts: - 20 tests: name matching, fee tiers, PDF text, contradiction checks - Built in about 39 hours - Live: recourse-pearl.vercel.app ### forge (2026) hackathon · 26 hours · live: https://forge-theta-two.vercel.app · code: https://github.com/shivansh193/forge Stack: TypeScript, Next.js, Postgres, Prisma, Vitest Version control for AI agent prompts. Every edit gets a commit with a word-level diff, rollback and forks. Before you commit, it writes a realistic test message and runs the old and new prompt on it, so you see how the behavior changes before you keep the edit. 78 tests, built in about 26 hours. Git for agent prompts, where the diff that matters is the behavior. forge gives each agent's system prompt a real history: commits, word-level diffs, one-click rollback and forks. The interesting part is the behavioral diff, which runs the same message through two versions and compares the outputs. Why: Prompt changes break agents silently. A text diff tells you what you changed; it doesn't tell you what the agent will now do. I wanted that answer before committing. Components: - Prompt history (Next.js + Postgres): Commits, word-level diffs, rollback and forks for every agent. - Behavioral diff (Gemini / OpenAI / Anthropic): An LLM writes a realistic test message from the prompt, both versions answer it, and you compare the outputs side by side. - Regression checks (LLM judge): Exact-match tests kept flagging harmless paraphrases, so I switched to a temperature-0 judge with a deterministic fallback when the judge's output is malformed. - Storage (Prisma + Neon): Moving from localStorage to Postgres surfaced real multi-writer races. I replaced a delete-and-recreate save with per-agent upserts and handled concurrent first-visit seeding. API keys stay in the browser on purpose, so a database leak can't expose them. Key facts: - 78 tests across 15 files - Built in about 26 hours - Live: forge-theta-two.vercel.app ### VaultScope (2026) SIH 2026 · team · code: https://github.com/shivansh193/vaultscope Stack: Python, scikit-learn, XGBoost, tshark, pyshark, FastAPI IPsec VPN analyzer for Smart India Hackathon 2026 (NTRO problem statement). I built most of the analysis core: the IKEv1/v2 parser that rebuilds each session's crypto negotiation, the ingestion and flow-feature stages, both classifiers, and part of the CVE-linked rules engine. The traffic classifier, which guesses what's running inside an encrypted tunnel, went from 0.79 to 0.98 macro-F1 on the team's dataset. ### WTP Dynamic Pricing (2026) Razorpay Buildathon '26 · live: https://wtp-dynamic-pricing-engine.vercel.app/dashboard · code: https://github.com/shivansh193/wtp-dynamic-pricing-engine Stack: Python, FastAPI, LightGBM, SHAP, Next.js, Redis Checkout pricing that adapts to willingness to pay, sitting between a merchant's checkout and Razorpay. It decides price and offer in under 200 ms, explains each decision with SHAP, and never charges a low-trust buyer more than list price. LightGBM regressor R² ≈ 0.91, conversion classifier AUC ≈ 0.72. Razorpay Buildathon 2026, Track 01. ### Amazon ML Challenge (2026) team of 3 · I led · no public link Stack: Python, PyTorch, mBERT, FAISS, cross-encoder Entity resolution for Amazon ML Challenge 2026: match messy business records from two sources to a clean reference set, with no external data and models under 8B parameters. A fine-tuned mBERT bi-encoder retrieves candidates through FAISS and a DistilBERT cross-encoder re-ranks them. I led a team of three over a three-day sprint. Final leaderboard: 0.961 macro F0.5. ### Document Pile System (2026) take-home · no public link Stack: Python, FastAPI, LangGraph, DBOS, Postgres, MCP A hiring assignment for an AI document company. It takes a pile of related contracts, extracts facts that must appear near-verbatim in the source, flags conflicts between documents, and puts every change behind a human approval step. People use a review UI and agents drive it over MCP. Extraction scored P 0.845 / R 0.740 on 18 CUAD contracts. ### Tool Dependency Graph (2026) take-home · no public link Stack: TypeScript, Node.js, Graphviz, GitHub Actions A hiring assignment for an agent-tooling company. It reads a catalog of tool schemas and works out which action produces an id that another action needs, then draws the graph. Every edge comes from the schemas. It ignores parameters like account_id that almost every tool takes, and rejects circular edges where a tool needs the very id it claims to produce. ### Contract Watchdog (2026) hackathon · 10 hours · code: https://github.com/shivansh193/contract-watchdog-agent Stack: Python, Strands Agents, Gemini, Next.js An agent that watches a small business's contracts and only pulls in a human for a real decision, like a renewal inside its notice window or a price jump. In a live test the model re-notified on a contract it had just flagged and made up a reason, so I moved the dedup check into the tool's code with a regression test. It drafts emails but can't send them. 14 tests. ### Cash Flow Oracle (2026) Razorpay Buildathon '26 · code: https://github.com/shivansh193/wtp-dynamic-pricing-engine/tree/master/cash-flow-oracle Stack: Python, GARCH, HMM, Prophet Settlement forecasting for merchants, 30 to 60 days out with confidence intervals. GARCH(1,1) handles volatility, an HMM spots regime shifts, and Prophet does the trend. It also flags stress periods and suggests credit before a crunch. Razorpay Buildathon 2026, Track 04. ### PACER (2026) OSS · negative result · code: https://github.com/shivansh193/pacer Stack: C++, Rust, loom, setbench Can epoch-based memory reclamation for lock-free data structures adapt to workload pressure? I built it in C++ and Rust and benchmarked it against token4 (PPoPP '24). My early 10–22% speedup turned out to be a use-after-free in my own code. After the fix it ties the baseline, and the repo shows exactly how I found out. An idea I tested until it either held up or didn't. It didn't, and the write-up says so. PACER asks whether epoch-based reclamation can adapt how aggressively it frees memory based on load. I implemented it twice, as a C++ reclaimer for Brown's setbench and as a Rust core from scratch, then stress-tested both on Linux. Why: The first numbers showed a 10–22% win and I didn't believe them. More stress testing found a use-after-free in my reclaimer. A tie with the receipts is worth more than a speedup that crashes 6 runs out of 10. Components: - C++ reclaimer (C++ + setbench): A drop-in reclaimer extending token4. It freed the epoch bag while it was still being written to: heap corruption in 6 of 10 runs at 16 threads. After the fix, 20 of 20 clean runs. - Rust core (Rust + loom): Tier selection with hysteresis and snapshot coalescing. Tests and the loom model checker caught a livelock and a torn read. Both are fixed and covered by regression tests. - Backlog tracking (rdtsc histograms): Watching retired-node backlog, not just throughput, exposed an unbounded leak: 1.5M retired nodes vs 255 for DEBRA. Fixed by splitting per-op and per-window reclamation. Key facts: - After the fix: 0.93–1.03× vs token4, a tie - Free-count sweep: K=1 best everywhere; K=64 cost up to 35% throughput - 3 concurrency bugs found and fixed, each with a regression test - Raw CSVs behind every number are in the repo ### Synthetic Market RL (2026) OSS · hackathon · code: https://github.com/shivansh193/open-env-hack Stack: Python, FastAPI, Docker, Gym, GARCH, HMM A market environment for testing trading agents that simulates prices instead of replaying history, so look-ahead bias can't sneak in. GARCH(1,1) gives volatility clustering, an HMM switches regimes, and Poisson-timed news shocks move correlated assets together. Three difficulty tiers, served over FastAPI in Docker. A trading environment that generates the market instead of replaying it, so the agent can't peek at the future. Most backtesting environments replay historical data, which leaks the future in ways that are easy to miss. This one simulates market dynamics from statistical properties, so the agent only ever sees what has happened so far. Why: I kept seeing agents look brilliant on replayed data and fall apart live. Simulation doesn't fix every problem, but it removes the one that bit me most. Components: - Market engine (Python + NumPy): GARCH(1,1) volatility clustering plus hidden-Markov regime switching: volatility clusters, trends and mean reversion. - Difficulty tiers (Gym API): Tier 1 is single-asset trend following. Tier 2 is two assets with guaranteed regime switches. Tier 3 is a four-asset portfolio under stress with a hard drawdown stop. - News shocks (Poisson process): 50+ headline templates arrive at Poisson-timed intervals, with Cholesky sampling so correlated assets move together. - Deployment (FastAPI + Docker): A REST server in Docker with a validation suite for every tier. Key facts: - GARCH(1,1) + HMM regime switching - 3 difficulty tiers - 50+ news templates on Poisson timing - Correlated multi-asset moves via Cholesky sampling ### MoE on a 4 GB GPU (2026) pre-registered study · no public link Stack: Python, PyTorch, Transformers, numba, Kaggle GPUs Mixture-of-experts models like OLMoE-1B-7B need about 14 GB of GPU memory. I measured what happens when only about 20% of the experts fit, on two models and a real 4 GB laptop GPU. The best setup keeps fp16 experts resident and serves misses from int4 copies: 0.24x the memory, HellaSwag 77.2 vs 77.4, and 2.2x faster than standard offloading. What it actually takes to run a mixture-of-experts LLM on a laptop GPU. OLMoE-1B-7B and IBM's Granite MoE need far more memory than a typical laptop GPU has. I studied keeping only a fraction of the experts resident, across five pre-registered phases on Kaggle GPUs, and checked the results on GSM8K, HellaSwag and ARC-Challenge. Why: Most claims about running big models on small hardware come from one benchmark and one model. I wanted numbers I could trust, so every hypothesis was committed to git before its data existed, and the analysis scripts refuse to give a verdict otherwise. The failures are in the report too. Components: - Cache simulator (numba trace replay): Replays real expert-routing traces under LRU, LFU and the offline-optimal Belady bound, so a caching policy can be judged before touching a GPU. - Live evaluator (PyTorch forward hooks): Rewrites each MoE router's choices in place. Dozens of policies run side by side with the full model in one batch, so quality loss is measured exactly, with a noise floor of zero. - Mixed-precision fallback (fp16 + int4 experts): Resident experts stay fp16; misses are served from int4 copies, plus two refinements found during the study. Key facts: - 0.24x GPU memory, HellaSwag 77.2 vs 77.4 - 2.2x faster than standard offloading - Exact offloading is too slow at this budget, even under the Belady bound - Skipping missing experts breaks the model (GSM8K drops to 0%). Replicates on a second architecture ### SNUXplore (2024 →) 30K+ uses in week 1 · tech lead · live: https://snu-xplore-six.vercel.app Stack: Next.js, Gemini, LangChain, RAG The campus app for Shiv Nadar University. I led all the tech as one of three project leads on a team of about 23 (most of the team ran marketing and on-ground work), and I'm the largest code contributor. 30,000+ uses in its first week. A RAG layer answers questions about courses, professors and campus. Now on v4. One campus app instead of five broken ones. 30,000+ uses in its first week. SNUXplore started as a course planner and grew into the place students go for courses, professors, food and campus info. I led all the tech as one of three project leads on a team of about 23, most of whom ran marketing and on-ground work. It's now on v4. Why: SNU's tools were scattered and slow. Finding which courses were open, who taught what or what the mess was serving meant asking around. The first week settled whether that was a real problem. Components: - Spike-ready backend (Caching + tuned queries): Built for registration day, when the whole campus hits the app in the same few minutes. - RAG answers (Gemini + LangChain): Ask in plain English, like which CS electives a professor teaches, and get an answer pulled from campus documents. Key facts: - 30,000+ uses in the first week - Tech lead, one of 3 project leads, ~23-person team - Largest code contributor - Live: snu-xplore-six.vercel.app ### BuildFlow (2025) 500+ projects · college event · live: https://product-roadmap-beta.vercel.app · code: https://github.com/shivansh193/buildFlow_Public Stack: Next.js, TypeScript, Firebase, Gemini An AI project manager that remembers your product between sessions. It helps you go from a rough idea to a scoped MVP, writes tasks sized to the team, and tracks them on a Kanban board. We used it at a college event, where it handled 500+ projects. An AI project manager that doesn't forget your product the moment you close the tab. BuildFlow keeps a persistent picture of your product and helps at each step: rough idea, MVP scope, tasks, tracking. We ran it at a college event, where it handled 500+ projects. Why: I was tired of re-explaining my own product to an LLM every session. BuildFlow keeps that context so the AI can actually help with what to build next. Components: - Ideation with memory (Gemini): Remembers the project's history and doesn't suggest things you've already tried. - MVP scoping (Gemini + React): Separates core features from nice-to-haves and ranks them by impact and effort. - Task generation (Gemini): Tasks sized to the team. A list for a senior engineer looks different from one for a beginner. Key facts: - 500+ projects at a college event - Context kept across sessions - Task generation + Kanban tracking ### Locus (2026) H0 hackathon · live: https://coframe-psi.vercel.app Stack: Next.js, Konva, Aurora DSQL, Gemini A multiplayer canvas where people and an AI agent think together. The AI gets its own cursor, draws nodes and talks. The canvas is a typed JSON op log in Aurora DSQL streamed over SSE, so the agent reads structure instead of pixels. Built in about five days for the H0 hackathon run by Vercel and AWS. ### loom-boom-zoom (2026) browser-only · live: https://loom-boom-zoom.vercel.app · code: https://github.com/shivansh193/loom-boom-zoom Stack: Next.js, ffmpeg.wasm, Whisper, IndexedDB A Loom-style studio for demo videos that runs entirely in your browser: script, teleprompter, recording, compositing and export. Whisper transcribes locally and ffmpeg.wasm renders, so you don't need an account and your footage never leaves your machine. ### ChainedThought (2024) multi-agent research · no public link Stack: Python, LLM APIs, Agent orchestration A multi-agent research system I built in November 2024, a few months before the big deep-research products shipped. It splits a hard question into domain questions, sends each to a specialist agent, and an orchestrator merges the answers while keeping track of where the agents disagree. Specialist agents argue a question from different angles, and the orchestrator keeps the disagreements. ChainedThought takes a complex question, breaks it into domain questions, and hands each to a specialist agent: economics, funding, technology, regulation and so on. An orchestrator writes the final answer and lists where the specialists agreed, where they contradicted each other, and what nobody covered. Why: A single agent answers from one angle and misses the rest. I wanted the disagreements in the open, because that's usually where the interesting part of a question is. Components: - Question decomposition (LLM API): Splits the query into domain questions and spins up one agent per domain. - Specialist agents (Python + LLM APIs): Each has its own priors, tools and criteria. They're supposed to disagree. - Orchestrator (LLM API): Merges the answers and tracks agreements, contradictions and gaps. Key facts: - Built November 2024 - One specialist agent per domain - Contradictions tracked explicitly in the final answer ### NewsOCR / BookOCR (2025) reused in prod · code: https://github.com/shivansh193/news_ocr Stack: Python, Tesseract, Local LLM Tesseract pulls the text and a local LLM cleans it up and structures it. Cheaper than cloud OCR, and it holds up on real books and newspapers. The same OCR core later went into the Pactle quote engine for scanned RFQs. ### OS Resource Manager (2025) IEEE-style paper · code: https://github.com/shivansh193/OSProj Stack: C++, Systems programming A simulated OS resource manager: scheduling that learns from usage patterns, predictive memory allocation, and process trust scoring for anomaly detection, tested on 100–200 simulated processes. Written up as an IEEE-style paper. ### AdvisoryAI (2026) hackathon · live: https://advisoryaihack.vercel.app · code: https://github.com/shivansh193/advisoryaihack Stack: C#, .NET, LLM APIs A .NET engine for Word templates. It treats highlighted sections as blanks and fills them from an LLM or structured input, so a template works without anyone hand-editing it. Built at a hackathon. ### Petner (Sep 2022 – Aug 2023) first startup · age 18 · live: https://petner-plat.vercel.app Stack: React, Node.js, Firebase My first startup, started at 18: a social platform for pet owners. I rebuilt it four times in a year (petnerSocial, v1, Next, Plat) before shutting it down. It taught me more about distribution than any course. ### DeBi (2023) archived · code: https://github.com/shivansh193/DeBi Stack: Solidity, React, TypeScript, Web3.js An NFT launchpad that let a business issue its own fungible or non-fungible tokens, pitched as a digital IPO. Solidity contracts with a React front end, built in 2023. ### DeLogi (2024) co-built · discontinued · code: https://github.com/RohanMathur2002/delogi Stack: TypeScript, QR codes, Supply chain QR-based supply chain provenance: every scan at a production or logistics step adds to an audit trail for the product. Co-built as part of CatalystIQ. We shut it down because the Indian market wasn't ready for it. ### Crypto Tx Tracker (2023) archived · no public link Stack: Python, TypeScript, Blockchain APIs Paste a transaction and it follows the money to whatever depth you set, so you can see whether funds from a flagged transaction were later withdrawn or mixed. Built in 2023, before this was a standard compliance feature. ### News Bias Analyzer (2025) archived · no public link Stack: Python, LLM APIs, Web search Summarizes a news article, classifies its political lean, then searches for coverage of the same story from the other side and flags when it finds contradicting reports. ## Research ### Prediction Markets as Macro Derivatives: A Simulation Framework for Portfolio Hedging with Event Contracts FINVERSE 2026 · March 2026 · 2nd place · Kalra, S. First empirical framework for evaluating institutional viability of event contract hedging. Models 383 Kalshi contracts across 58 macro events (Fed rate + CPI, 2022–2024) as binary derivatives using modified Black-Scholes on VIX surface. At 1% NAV: hedged Sharpe 0.538 vs unhedged 0.065. Quantifies basis risk (100% CPI accuracy, 0% FOMC, which is itself a market-efficiency finding), hedge efficiency decay, and AUM ceiling ($148K current → $14.8M at 100× ADV). JEL: G11, G13, G14, G18. Key facts: 2nd place · Finverse 2026; 383 contracts · 58 events; Sharpe 0.538 vs 0.065 ### PIE: Physics-Inspired Contrastive Learning for Low-Light Image Enhancement PREPRINT · 2025 · IEEE-formatted · first author · Kalra, S. Bag-of-Curves negative sample generation (gamma, sigmoid, logarithmic curves), contrastive learning with Gram matrix triplet loss + InfoNCE objective, unsupervised superpixel segmentation for regional brightness consistency. Evaluated on LOL dataset and real-world smartphone images. Outperforms RetinexNet (20.7 PSNR), Zero-DCE (21.5), EnlightenGAN (20.9). PIE achieves 24.3 PSNR, 0.89 SSIM. Key facts: 24.3 PSNR · 0.89 SSIM; +3.4 dB over best baseline ### Bitcoin Volatility and Regime Forecasting: A Comparative Analysis of Time Series Models IEEE-FORMAT · 2025 · Working paper · sole author · Kalra, S. Comparative analysis of OLS, ARIMA, GARCH(1,1) on Bitcoin returns. Confirms Weak-Form EMH, 50% directional accuracy for OLS/ARIMA. GARCH(1,1): α=0.089, β=0.895, persistence=0.984. Crisis simulation across COVID-19 crash, Terra/Luna collapse, FTX bankruptcy, 2021 bull run. Bull/Bear regime classification showing asymmetric duration and 2–3× volatility differential. Key facts: GARCH persistence=0.984; 4 crisis regimes simulated ### PACER: Pressure-Adaptive Continuous Epoch Reclamation WORKING PAPER · 2026 · Not peer-reviewed · sole author · Kalra, S. Tests whether epoch-based reclamation for lock-free data structures can adapt its freeing policy to workload pressure, extending token4 (Kim et al., PPoPP 2024). Implemented in C++ (setbench) and Rust (loom model-checked). The initial 10–22% speedup traced to a use-after-free in the reclaimer; after the fix, PACER ties token4 (0.93–1.03×) on write-only, 80%-read and range-query workloads. A free-count sweep shows why there's no headroom on single-socket hardware. Multi-socket behaviour remains untested. Key facts: 0.93–1.03× vs token4 (tie); 3 concurrency bugs found + fixed ## Ventures ### InVariant: Founding Engineer (active) Infrastructure intelligence platform. Live-traffic stack fingerprinting, a call graph engine (9 node types, 10 edge types, 8 analyses), a Rust CLI, and the open-source clipy. 30 founder conversations, validated with 12 founders. ### CatalystIQ: Founder & Technical Lead (archived) B2B SaaS I built directly with client companies, Dec 2023 to Apr 2024. Across everything we shipped, 250+ businesses used it. - Phase 1: Services (2024): Web apps and product design for clients. First revenue, first client relationships. - Phase 2: AI freelance marketplace (2024): A freelance platform built around small, AI-assisted gigs. Applicants submitted a piece of the actual work instead of a proposal. - Phase 3: Inventory for quick commerce (2024): Inventory software used by 30–40 quick-commerce companies, plus a logistics optimizer aimed at cutting carbon. We dropped the optimizer when it didn't find market fit in India. - Phase 4: DeLogi (2024): QR-based provenance for imported goods: every scan along the supply chain adds to the product's audit trail. Shut down because the market wasn't ready. - Phase 5: CatalystIQ Hub (2024): An AI resume screener that 10+ B2B clients ran themselves to screen 4,000+ candidates. 65% shorter hiring cycles for clients, 18% conversion rate. - Phase 6: Lead-gen automation (2024): Custom n8n workflows for client lead-generation pipelines. ### Petner: Founder (archived) Social platform for pet owners. My first startup, rebuilt four times over about a year. ## Write-ups ### running a 14 gb moe model on a 4 gb laptop gpu (2026-10) https://shivansh-kalra.vercel.app/writeups/moe-on-a-4gb-gpu i have an rtx 3050 laptop with 4 gb of vram. olmoe-1b-7b needs about 14 gb in fp16. i wanted to know what actually happens when only ~20% of a mixture-of-experts model's experts fit on the gpu, and which of the usual tricks hold up when you measure them properly. ## the setup every test was pre-registered. i wrote the hypothesis and the pass bar into a json file and committed it to git before collecting any data, so i couldn't move the goalposts after seeing results. i ran five phases this way on kaggle gpus, and reported the ones that failed as failures. the pieces: - a router-trace collector that logs which experts every token picks - a trace-replay simulator (numba) to test caching policies: lru, lfu, decaying lfu and belady, the offline-optimal bound - a live evaluator that hooks every moe router, rewrites its choices, and runs many policies as batch rows next to the full model, so output change (kl) is measured in the same forward pass with a noise floor of exactly 0 - task accuracy on gsm8k, hellaswag and arc-challenge with kv-cached generation - 83 tests on tiny random moe models ## what i found at ~3.4 gb of gpu memory (0.24x the full model): | approach | kl vs full model | hellaswag | arc-c | ms/token* | |---|---|---|---|---| | full model (13.8 gb) | 0 | 77.4 | 47.4 | 13.6 | | exact offloading | 0 | same | same | 76 | | skip experts that aren't resident | 2.3 | 31.6 | 25.8 | 13.7 | | quantise every expert to int3 | 0.14 | 73.6 | 43.0 | ~6 | | resident fp16 experts, int4 copy on a miss | 0.0085 | 77.2 | 46.8 | 34 | \* modelled from bandwidths measured on the laptop gpu, not an end-to-end kernel. - better caching can't save exact offloading. even belady, which knows the future, is 4.5x slower than the compute floor at this budget, because routing changes too much from token to token. - skipping experts breaks the model. gsm8k drops to 0 on both models. - quantising everything so it all fits is too lossy. - what works is keeping the hot experts in fp16 and serving a miss from a low-bit copy of the right expert. near-identical accuracy and 2.2x faster than exact offloading. that mechanism isn't mine, it's hobbit-style. what i added is two refinements that helped on both models (exact first positions per document, hqq copies, -11% kl) and a careful evaluation. ## what didn't work - phase 2 failed. substituting a similar resident expert couldn't reach the quality bar. - in phase 3 the method i was testing lost to the plain low-bit baseline. - on granite-3.1-3b-a800m (the replication) 20% residency missed the bar on gsm8k, 104 to 94 of 250. with the same 2.4 gb (40% of its experts) it matches the full model. ## limitations two models. latency is modelled from measured bandwidths. the "users" are streams built from benchmark documents, not real logs. gsm8k doesn't have much statistical power on olmoe's base model. ## what i took away most ideas in this space look good in a simulator and fall apart under a live quality check. pre-registering kept me honest about that, half the hypotheses failed and the thing that worked was the boring one. the code is in a private repo for now, happy to share access if you want to dig in. the follow-up on dense models is [here](https://shivansh-kalra.vercel.app/writeups/dense-residency). ### does per-user neuron residency work for dense models? (no, mostly) (2026-10) https://shivansh-kalra.vercel.app/writeups/dense-residency this is the follow-up to my [moe project](https://shivansh-kalra.vercel.app/writeups/moe-on-a-4gb-gpu). there, keeping the experts a user actually uses in fast memory worked well. the question here: does the same idea carry over to dense models, keeping only the ffn neurons a given user fires in gpu memory and streaming or skipping the rest? short answer, not enough to be worth it. i stopped the track. ## the setup same rules as before. every test was pre-registered in a json file committed before the data existed, with a pass bar written down in advance. - a neuron-usage collector for turbosparse-mistral-7b, a natively sparse model (dReLU, 32 layers x 14,336 ffn neurons) - the test: build a per-user hot set from the user's last ~2,048 tokens, score it on their next 512, and compare it to one global set, at a budget of 20% of each layer's neurons - the comparison set was deliberately the strong one, profiled on all four domains plus general web text - runs on kaggle 2x t4, positive and negative controls in the tests ## what i found **pilot: fails, 0 of 4 domains.** the bar was +10 points of coverage. | domain | per-user | global | gap | |---|---|---|---| | code | 51.5% | 47.1% | +4.4 | | math | 58.6% | 50.9% | +7.6 | | german | 56.3% | 50.1% | +6.2 | | arxiv | 54.7% | 49.7% | +5.0 | the gain is real, every confidence interval is well above 0, it's just too small. against a powerinfer-style set profiled on general web only, the gap is bigger (+8 to +14), but that wasn't the pre-registered comparison, so it can't rescue the claim. most of the gain comes from using any in-domain statistics, not from personalising. **replay (exploratory): partly.** at 20% budget, per-user sets are modelled 17-24% faster than powerinfer-style sets when cold neurons run on the cpu, and about 10% faster when they stream over pcie. **teal on qwen3-4b-base: fails.** current dense models aren't natively sparse, so i tested training-free activation sparsity instead. the bar was staying within 2 points at 40% and 50% sparsity. it narrowly misses at 40% (hellaswag -2.4). about 25% is nearly free (1.4 points or less, 1.28x modelled) and there's a cliff past 50%. ## what i took away per-user residency helps on a natively sparse dense model, but by single-digit points, which doesn't justify per-user machinery. on normal dense models the training-free route buys about 1.3x for almost nothing, which is useful but generic. so i stopped. writing the bar down before running anything made that an easy call instead of a sunk-cost one. the code is in a private repo for now, happy to share access if you want to dig in. ### memory for voice agents, and why my best result is a tie (2026-09) https://shivansh-kalra.vercel.app/writeups/hippovoice-memory i wanted memory for voice agents that behaves less like a vector database and more like a person. a fact someone mentioned once should stick around, what they had for breakfast three weeks ago shouldn't, and what gets pulled up for a question should be whatever's relevant, not whatever was said most recently. voice makes this harder than chat. there's no time to pause and go look something up mid-conversation, so whatever memory gets injected has to be right and small. ## how it works the store is split in two, and that split is the main decision in the codebase. - **semantic memory** holds facts, preferences and people. it doesn't decay, "the user's dog is named max" isn't less true a month from now. - **episodic memory** holds specific events. it decays ebbinghaus-style, salience drops over turns unless emotional intensity or getting recalled again boosts it. an earlier version ran everything through one decaying store, and the forgetting cycle meant for stale episodes was quietly deleting durable facts too. splitting the store by type fixed it. retrieval is hipporag-style: vector seeds, a 1-hop graph walk, then a rerank that blends relevance with the memory's current salience. two simpler versions failed first. raw blending let salience (which spans about 13 orders of magnitude) swamp relevance completely, and reciprocal rank fusion stopped meaning anything once the candidate pool got small. log-normalising salience against a forget threshold is what worked. a few things only showed up in real runs: - blending salience into semantic hits gave every fact a flat bonus and noise jumped to 90% before i caught it. facts are now scored on relevance alone. - embeddings couldn't separate "jon" from "john", two different people in one conversation. exact proper-noun matching needed its own signal and a full-store scan feeding the candidate pool, a bonus at rerank time wasn't enough. - a decay rate tuned for 100-turn chats forgets almost everything before a 600-turn conversation is half done, so decay is a per-scale parameter. ## how i measured it [locomo](https://github.com/snap-research/locomo): 10 long conversations, 369-689 turns each, 1,540 questions with real ground truth. it's what mem0, a-mem and memorybank report on. i didn't compare against published numbers. those use different llms and lenient llm-as-judge scoring (zep alone has been reported anywhere from 58% to 84% depending on who measured it). instead i reimplemented mem0, a-mem and a naive rag baseline locally (plus a simplified zep that's still being re-run) and ran everything through one harness, same llm (qwen3-4b), same scorer (the published stemmed token f1), same retrieval budget. | system | avg f1 | top_k | |---|---|---| | naive rag | 33.9% | 10 | | hippovoice | 29.47% | 10 | | mem0-style | 29.11% | 10 | | a-mem-style | 22.0% | 5 (not yet re-run at 10) | **hippovoice and mem0 are a tie.** an earlier version of this showed hippovoice well ahead (23.4% for mem0), and it turned out that was a retrieval-budget mismatch, mem0 was running at top_k=5 and hippovoice at 10. i found it by re-running the baseline, not because anyone pointed it out. at matched settings the lead disappears. **naive rag wins, and it's worth saying why.** it never forgets anything. on a fixed set of 10 conversations that never grows big enough to cost anything, keeping everything wins on raw recall. that's the regime this benchmark tests, and it says nothing about a store that grows for months. so the number i care about more is noise, how much of the retrieved context is actually irrelevant. on a smaller synthetic benchmark hippovoice retrieves 10% irrelevant context against 30% for mem0-style and naive rag. two caveats i'd rather state than hide: the baselines were measured against hippovoice's earlier 20% run and weren't re-run after the fix, and a-mem-style also gets 10%. so the honest summary is that clean retrieval is achievable without the full decay machinery, and separating them needs a much bigger store than 90 turns. ## voice, end to end the same memory runs behind a real audio-to-audio model (qwen2.5-omni-3b). on an a10g, "my favorite color is blue", then an unrelated turn, then "what is my favorite color?" gets the spoken reply "your favorite color is blue", with real speech in, real extraction and retrieval, and real audio out. a 40-question locomo run through the full audio pipeline finished with zero errors at 25.81% avg f1 (2 conversations, so not comparable to the full-set numbers above). ## what i took away - the most important result here is a tie, and the most useful thing i did was find out my early lead was a bug. - benchmarks test a regime. locomo rewards never forgetting, which is exactly what you can't afford in a real product. - i kept a lab notebook (bugs.md in the repo) with every fix that was tried and reverted and the numbers that killed it. the dead ends are as informative as what worked. code, results and the full lab notebook: [github.com/shivansh193/hippovoice](https://github.com/shivansh193/hippovoice)