DEV Community: Saksham Arora

ECX, Piece by Piece: The Seven Parts of My Claude Code and Codex Setup

Saksham Arora — Wed, 11 Nov 2026 09:17:38 +0000

The whole setup on one screen. This post walks through every circle.

I've used Claude Code and Codex every day for six months. Out of the box, they're two brilliant strangers. Neither knows what I'm working on until I tell it, neither knows what the other one did an hour ago, and both will happily tell me a task is "done" while the tests are red.

So I kept adding pieces. A folder of notes they both read. A hook that passes each one the other's latest messages. A search engine over everything I've written. A guard that won't let them finish with failing tests. Eventually the pieces became one thing, and I packaged it as ECX (everything claude codex) so anyone can install it in one line.

This post goes through all seven parts in depth: what each one does, how it works under the hood, and what it changes day to day. Every screenshot below is a real recording. I installed ECX fresh for a demo user called Maya so none of my own notes show up.

1. A shared second brain

Projects, deadlines, hard rules. Both agents read it before you type.

Everything in ECX sits on top of one idea: your notes live in a single folder of plain Markdown files, the vault, and the agents treat that folder as their memory.

What's in the vault

inbox/      drop anything here, sort it later
daily/      one note per day
projects/   what you're building and where each thing stands
personal/   people, opportunities, applications, resume
research/   deep dives and playbooks
wiki/       clean, linked articles compiled from raw notes
content/    drafts, a queue, a published log
archive/    finished work. Nothing is ever deleted, only moved

It's an Obsidian vault, so you get the graph view, backlinks and every Obsidian plugin for free. It's also just files in git, so nothing locks you in. If you stop using ECX tomorrow, your notes are still a normal folder.

One rule runs the whole thing: capture first, organize later. Anything new goes into inbox/. You never decide where something belongs while you're capturing it. An agent files it later, and /wiki compiles piles of raw captures into clean linked articles (Karpathy's LLM-wiki idea), then moves the originals to archive/.

The memory layer

A folder of notes on its own is a library nobody reads. What makes it a second brain is a small memory layer that the agent loads before you say anything:

hot.md is what's true right now: live deadlines, current projects, hard rules ("never edit my resume without asking", "never push to main"). It's short on purpose. If it's in hot.md, every session knows it.
Recent sessions. With the free remember plugin installed, ECX has it write a summary after every reply. recent.md and the daily files hold the last few days, so a new session knows what you did yesterday.
Memory files. One small file per thing the agent learned about you: a preference, a correction ("stop suggesting X"), the state of a project. An index file lists them all.

A SessionStart hook injects all of this before your first message. A second hook refreshes it after every /compact, which is when long sessions usually lose their context. At the end of a session, /tldr writes back whatever changed.

What it changes

You stop opening sessions with three paragraphs of background. I open Claude Code, type "what's on my plate this week?", and get an answer built from my own deadlines and open loops, not a guess.

A brand-new Claude Code session. It has never seen this conversation before, but it has read the vault, so it knows the demo date, the eval deadline, the parse_tide bug and the reply Maya owes Priya.

It also lists something that isn't in Maya's notes at all: the demo moved to Friday. That's the next part.

2. Agents in sync

Tell Codex something. Claude already knows.

Claude Code and Codex come from two different labs. Each keeps its own chat history, and neither can read the other's. If you use both, you're the glue: you copy context between terminals and re-explain whatever the other agent just figured out.

How agent-sync works

Both agents write every conversation to session files on disk: Claude Code under ~/.claude/projects/, Codex under ~/.codex/sessions/. agent-sync is a single Python file (standard library only, nothing to install) that runs as a hook before every message you send to either agent:

It finds the other agent's session files.
It reads only the lines that are new since last time, so it stays fast. It takes well under a tenth of a second.
It injects those new turns into the current agent's context as a short "since your last message, here's what you told the other agent" block.

The first message of a session looks back six hours, so a fresh session catches up on what happened today. After that, it's a running diff. Codex voice transcripts are included, so you can talk to Codex out loud and then type to Claude.

The agents can also message each other directly. sync.py send --from claude --to codex "..." leaves mail that shows up in the other agent's next turn, with a rate limit so two agents can't ping-pong forever. Every message is logged to agents/AGENT_CHAT.md, a readable file you can open in Obsidian.

What it looks like

Maya tells Codex about a schedule change. Codex reads the vault's hard rules, notes the change, and replies "Saved for Claude".

Then she opens a brand-new Claude Code session and asks about her week. Claude's answer (the screenshot in part 1) says: "Lena moved it from Thu 11:00, and it now has to run on the v2 buoy feed. Your notes still say Thu 11:00." Nobody passed that on by hand. Claude even caught that the notes were now stale.

3. Search three ways

By meaning, links and images. Re-indexed every night.

Plain text search finds words. Your memory doesn't work in words. You remember "that note about latency" or "the slide with the architecture diagram", and grep can't find either.

ECX ships three search engines over the vault, each exposed to the agents as an MCP server:

By meaning (ChromaDB). Every note is split into chunks and embedded. Ask about "notes about latency" and you get notes that talk about tail percentiles and slow requests, even if the word "latency" never appears.
By relationship (LightRAG). A knowledge graph of the people, projects and ideas in your notes and how they connect. It answers questions like "how does my engine relate to my competition strategy", which no keyword search can.
By image (CLIP). Your slides, screenshots and PDF pages are indexed by what's in them. Describe the image ("the slide with the gradient descent diagram") and it finds the slide and tells you which note it lives in.

A small router server looks at each question and sends it to the right engine, so the agent doesn't have to guess. A nightly job re-indexes everything while you sleep.

Two pieces keep it honest:

MCP health. If a search server's dependency is down, a hook blocks the call and tells you the exact fix, instead of letting the agent get empty results and make something up.
Stale index warning. If the nightly job stops running, your next session opens with a warning and the time of the last successful update. You don't find out months later.

One privacy note, straight from the FAQ: meaning search and image search run entirely on your machine. The relationship graph uses Ollama, and its default model runs on Ollama's free cloud, so note text is sent there while indexing. Set ECX_LLM_MODEL to a local model if you want everything on your laptop.

4. No fake "done"

Failing tests send it back. Dangerous commands blocked.

Agents are optimistic. They'll change one file, skip the test run, and announce they're finished. ECX adds hooks that check the work before the agent is allowed to stop.

Tests before done

When Claude Code or Codex tries to finish, a Stop hook runs your tests first:

It only runs inside a git repo, and only when something changed since the last green run. It fingerprints HEAD, tracked changes and new files, so a question-and-answer session never triggers a test run.
It finds the test command on its own: an npm test script, pytest, unittest with a tests/ folder, cargo, go, or a Makefile test: target. You can set it per repo in .ecx/test-command, or write off there.
If the tests fail, the agent is sent back with the last 40 lines of failing output and has to fix them.
After three failed attempts in a row it lets the agent stop and tells you, instead of looping forever.

Both agents send the same payload when they try to stop, so one script covers Claude Code and Codex.

Maya asked for "a quick one, no need to run the tests". Claude skipped them. The hook didn't.

Sent back with the failure, Claude worked out that the old test encoded the bug, fixed it, and both tests pass.

The danger guard

A PreToolUse hook reads every shell command before it runs. It blocks rm -rf ~, disk formats and fork bombs outright, and asks before force-pushes, git reset --hard and DROP TABLE. This matters more than it sounds: many popular guards check a variable Claude Code never sets, so they block nothing. ECX's guard is tested against the real hook payload. (It's strict enough that it blocked me while I was making this post's diagram, because the illustration's text contained rm -rf ~.)

The doctor

doctor runs 16+ checks across hooks, indexes, scheduled jobs and sync. It also runs at the start of every Claude Code and Codex session: silent when everything is healthy, a short warning with the exact fix when something isn't.

Doctor checks every part. Green means silent at session start.

There's also an AI-tell guard: after you write anything in content/ or personal/, it warns about em dashes and stock AI phrases from a word list you can edit. It never blocks, it just tells you before you publish.

5. Skills, made yours

18 included. Rewrite them or add your own.

A skill is a folder with a SKILL.md file: plain instructions for one job, plus any scripts it needs. You type /daily and the agent follows that file. Because skills are just Markdown, you change one by editing text. No code, no build step.

ECX ships 18, and most of them work on top of the vault:

Skill	What it does
`/boot`	A 30-second briefing at the start of a session
`/daily`, `/weekly`	Start the day or review the week from your trackers
`/opps`	Your opportunity pipeline, with deadline and eligibility checks before anything is shown as actionable
`/outreach`, `/email`	Networking with a paper trail of who you contacted and when
`/content`, `/brand`	A content machine that drafts in your voice and keeps a queue
`/resume`	Resume changes, always asking first
`/catchup`	Reads another window's full session so you can continue it
`/ship`	Commits, pushes and shows proof it landed
`/tldr`	Saves the session to the vault and updates `hot.md`
`/wiki`, `/wiki-health`	Compiles the inbox into linked articles, and finds stubs, orphans and broken links
`/video-notes`	Turns a video into key frames and a transcript, then notes
`/project`, `/summary`, `/money`	Load a project's context, summarize progress, track income ideas

The skills that matter most are the ones you write yourself. Mine started as the ones in this table and grew into dozens: a competition playbook, a course tracker, a content calendar. Copy a skill, change its instructions to match how you work, and it's yours. Skills are linked into both ~/.claude/skills and ~/.agents/skills, so Codex gets the same ones.

6. Vault on your phone

Ask or capture a note with your laptop shut.

This one surprises people the most. With my MacBook closed in my bag, I can open the Claude app or the ChatGPT app on my phone, ask "what's due this week?", and get an answer from my own notes. I can say "I met Adi, he's at X, we talked about Y" and it lands in my vault.

There's no server and no new app. The bridge is a private GitHub repo:

After every reply on the laptop, a hook syncs the vault to its private GitHub repo in the background. It also mirrors the memory layer into a context/ folder: hot.md, today's session log, recent summaries and the memory files. The phone sees what the laptop knew, minutes later at most.
On the phone, Claude (Claude Code on the web) or Codex (Codex Cloud in the ChatGPT app) works on that repo in the cloud.
The vault's AGENTS.md has a "phone mode" section. It tells a cloud agent to boot from context/, search with the shell, and treat captures specially: write exactly one new file in inbox/, touch nothing else, and push it.
A GitHub Action auto-merges inbox captures. Next time you open the laptop, the capture is pulled down and an agent files it properly.

Because the phone only ever adds one file to inbox/ and never edits memory directly, the two sides can't overwrite each other.

The two phone apps differ in a couple of small ways. The Claude app reads CLAUDE.md on its own and pushes captures straight away. Codex in the ChatGPT app needs a one-time setup (connect the GitHub app to just the vault repo, create a Codex Cloud environment with internet off), you start each chat with "Read AGENTS.md first and follow section 7", and it asks once before publishing a capture to your repo. The README walks through both.

7. Two agents, one task

They argue with evidence. Risky steps wait for you.

The first six parts make each agent better on its own and keep them in sync. ecx duo puts them on the same problem at the same time.

cd your-repo && ~/ecx/bin/ecx duo "make the failing login test pass"

Both agents start on the goal, on a fresh branch, and a local page opens with one chat where you watch them work. Nobody is in charge. They split the work themselves, and they're told to push back instead of agreeing to be polite.

How a run goes

A blind round first. Each agent writes its own plan without seeing the other's. Then they critique each other's plans and merge the best of both. You see both takes side by side.

Blind drafts. Neither saw the other's plan before writing its own.

You approve the plan before anything gets built. Nothing is written until you click Approve.

The merged plan waits for you.

They argue with evidence. An objection has to come with a reason you can check: a failing call, a test, a source. And neither agent can call the task done until it has re-checked the other's latest changes.

A real objection from a real run: Codex found a crash with build metadata, and Claude fixed it with the exact calls that now pass.

Risky actions wait for you as cards: deleting or replacing files that existed before, git push and other history changes, publishing, deploying, sending data out, any tool call that isn't a plain read, and any tool duo doesn't recognize. Folders you list as protected are blocked outright.

Even after "yes, push it", the push still shows as a card until it's approved.

You can talk to one agent (@codex try the smaller fix) or both, and pause, resume or stop at any time. A High button switches both to their top models mid-run, and a meter shows each agent's usage limits. Duo pauses itself at 90%.

The report has two parts: the agents' own summary, and an action log duo writes from the raw events, which the agents can't edit. Every command, every card and your answer to it, with the risky ones listed first.

Does it actually help?

I ran it on six of the hardest issues in SWE-bench Verified (rated "1-4 hours" for a human), graded by the official harness:

	Claude Code alone	Codex alone	ecx duo
Issues resolved	2/6	2/6	3/6

Duo solved every issue that either agent solved alone, and neither agent alone got all of those. Six issues with one run each is a first signal, not proof, and the script to rerun it is in the repo.

The honest limits: duo judges each command and tool call, not what a script does after it starts running, so a script an agent writes and runs is only as safe as your review of the plan. It always works on its own branch, and every action is in the log.

Install

git clone https://github.com/saksham10arora-dotcom/everything-claude-codex ~/ecx
cd ~/ecx && ./install.sh

It asks two questions (where your notes live, and your first name) and wires everything in.

A real install for the demo user. Everything is merged into existing settings, never overwritten.

It never overwrites your config. It merges into existing settings, skips anything already there, and saves a .ecx-bak copy of every file it touches. --dry-run lists every change without making any, and --uninstall restores the backups. Add --with-search --with-cron --with-phone for the full stack.

You don't need both agents. Everything except agent-sync and duo works with Claude Code alone.

Why this matters

None of these parts is magic on its own. A notes folder, a hook, a search index, a test runner. The value is that they're wired together, so the agents stop being clever strangers and start working like a team that knows you: they remember your situation, they know what the other one did, they can find anything you've written, they can't fake being finished, and they keep working when your laptop is shut.

ECX is free and open source. It runs on the Claude Code and Codex logins you already have.

saksham.digital/ecx

More of my writing and projects at saksham.digital.

I Read X's Open-Source Algorithm: One Reply From a Mutual Is Worth 30 Likes

Saksham Arora — Wed, 04 Nov 2026 07:08:37 +0000

xAI open-sourced the code behind X's For You feed. Most of what I saw online about it came from the README or from people quoting each other, so I cloned the repo and read the code itself: the Rust that builds your feed, the JAX that trains the model, and the config file X syncs from production.

This is what I found, read at commit b220448 from 3 November 2026. Every number below is from the code, with the file it lives in.

The repo. 2,352 files of Rust, JAX and Scala, with a commit almost every weekday.

Before the numbers, here's the whole path a feed takes. Every time you open For You, this runs from left to right:

One feed request, start to finish. Most of this post is about the green and amber boxes.

How a post gets scored

Every post you could see gets one score:

score = sum of (weight × the chance you'll take that action)

The model predicts the chance you'll like, reply, repost, share, mute, report and about 20 other actions. Each prediction is multiplied by a weight, and the results are added up. The weights live in home-mixer/params/param.rs, and X runs a cron job that copies the production values into that file. The last sync before I read it was 2 November.

Action	Weight
Copy link to post	20
Reply	5
Quote	5
Share via DM	5
Follow the author	4
Share	2
Repost	1
Like	0.66
Click	0.3
Open a link	0.2
Profile click	0
Video quality view	0
Block author	-31.2
Not interested	-52.27
Mute author	-58.8
Report	-234

The actual lines, from the file X syncs from production.

One thing to get right before reading too much into this table. The weights multiply your predicted chance of doing something, not counts. Reports are more than 1,000 times rarer than likes, so a report needs a huge weight just to move the ranking at all. "One report cancels 354 likes" is the wrong reading. X even added a code comment warning against exactly this math (their example says 468 likes).

The right reading: X values conversation and sharing far more than approval. A reply is worth about 7.6 likes. A copied link is worth about 30.

The biggest lever: mutuals

There is one extra parameter, bidirectional_follow_reply_weight_boost = 15. If the post is an original post (not a reply or a repost) and the author follows you back, the reply weight goes from 5 to 20.

So one reply from a mutual is worth about 30 likes.

The whole eligibility rule is one line: original post, and you follow each other.

X documented the rollout in docs/BIDIRECTIONAL_BOOST_CHANGE.md. They A/B tested boosts of 5, 10, 15 and 20 starting 10 July 2026, shipped 20 on 13 July, then cut it to 15 on 24 July after people complained they were missing World Cup posts from accounts they didn't follow.

One negative prediction sinks a post

This is easy to miss. In xai-value-model/scoring.rs, a post with a positive total gets a small constant added. A post with a negative total gets squashed into a tiny range below that constant.

Positive totals get + 0.001. Negative totals get squeezed in below 0.001.

So every post with a negative total ranks below every post with a positive total, no matter how close to zero it is. If the model thinks a viewer is likely to mute you or hit "not interested", your post is effectively gone from their feed.

What happens after scoring

These adjustments don't run where the README says. Home-mixer hard-codes them off, and the separate vm-ranker service applies them:

Same-author decay. Your k-th post in one feed load is multiplied by 0.75 × 0.5^k + 0.25. Your 1st post keeps 100%, the 2nd 62.5%, the 3rd 44%, and it never drops below 25%.
Out-of-network discount. Posts from accounts the viewer doesn't follow get ×0.75. So do replies and reposts from accounts they do follow.
Diversity rerank. Out of the top 150, a determinantal point process (θ = 0.65) trades a little score for posts that look less alike, using cosine similarity of post embeddings. Ten near-identical takes on the same news story won't all make it.

Posting a burst doesn't multiply your reach. Each extra post in one feed keeps less of its score.

There is no time decay in the score. Freshness comes from a hard 48-hour cutoff and from post age being one of the model's inputs.

Small accounts get a free shot

home-mixer/scorers/author_cold_start.rs is a real bandit. On each feed request, at most one post gets lifted to slot 16 if all of these are true:

it's an original post, not a reply or a repost
the author has 50,000 followers or fewer
the post is under 2 hours old
it has fewer than 200 home-feed views

To pick which one, X uses Thompson sampling. For each candidate it draws a like rate from Beta(0.75 + likes, 49.25 + views − likes), which starts at a 1.5% prior. It keeps the top 2 draws and takes whichever the model scores higher.

The bandit, in 13 lines.

Here's what that looks like for two example posts with the same 150 views:

The post with 9 likes almost always draws a higher number, so it almost always wins the slot. The post with no data yet still has a long tail, which is how new posts get a chance.

In plain words: your likes per view in the first 2 hours decide whether X tests you on new people.

The model, Phoenix

If you work on recommender systems, this part is worth reading on its own. It's the most complete production recommender I've seen released.

Ranking: a transformer with 8 layers, width 2560, and 20 query heads sharing 4 key/value heads. It reads your last 1,022 actions plus 64 candidate posts.
Candidate isolation: candidate posts can attend to your history but not to each other. A post's score doesn't depend on what else is in the batch, so it can be cached.
Hash embeddings: users, posts and authors are hashed into tables of 100M, 100M and 30M rows, two hashes each, so there's no vocabulary to maintain and a brand-new post works instantly.
Semantic IDs: each post's multimodal embedding is quantized into 6 levels of 256 codes. Posts on the same topic share code prefixes, which helps the model generalise to posts it has never seen.
About you: country, language, location, inferred gender, age bracket, and a 10-million-row table of IP address hashes. An installed-apps feature exists but is switched off in the ranker.
Training: 1e11 examples, the Muon optimizer for dense weights, row-wise AdaGrad for the embedding tables.
8 October change: time-spent prediction moved from a Tweedie + MAE loss to CREAD, which classifies dwell time against 30 log-spaced thresholds from 2 to 120 seconds and then restores a number. That's what the changelog means by "predicts time spent much better".

Retrieval, the step that finds posts from people you don't follow, is a two-tower model. A transformer encodes your history into one vector, and the top matches come from an index of about 10 million posts.

What can hide a post regardless of score

After ranking, visibility-filtering checks every post. Some rules drop a post for everyone: suspended authors, spam labels, legal takedowns, and "Freedom of Speech, Not Reach" labels for hateful conduct, violent speech, abuse and civic integrity.

A second set only applies when the post would reach someone who doesn't follow the author. These include account labels like SPAM_HIGH_RECALL, IMPERSONATION_HIGH_PRECISION, ABUSIVE_HIGH_RECALL and DO_NOT_AMPLIFY. Followers still see the post. Strangers never do.

The list of account labels that block recommendations to non-followers. DO_NOT_AMPLIFY is the last one.

That's the "not banned, just not recommended" mechanism, written down in visibility-filtering/rules/levels.rs. The labels come from LLM classifiers running on Grok 4.1 Fast (the prompts aren't published), image and video models, and offline account-scoring jobs. X's Under the Hood page shows which labels are on your own account.

What the code settles

Premium gets no boost in ranking. There's no Premium weight or multiplier anywhere in the scoring code, and the feed service only logs subscription level. One caveat: the author's tier is part of the account text X feeds into each post's embedding, so the model can see it.
Strangers mass-reporting you does little. Only actions on posts X actually served in the feed count, and predictions are personalised, so reports mostly affect people who behave like the reporters.
Links aren't penalised by a weight. Opening a link is +0.2. Link posts lose because people reply to them less.

Where the README and the code disagree

The README links visibility-filtering/rules/registry.rs, but that file doesn't exist. The rules are in tweet_rules.rs, author_rules.rs and levels.rs.
The README says the ranking scorer applies the author-diversity and out-of-network adjustments. In the code they're switched off there and applied in vm-ranker.
FairShareRankingFilter is enabled in production but missing from the README's filter list. It trims candidates to 2,800, split proportionally across sources.
The Brazil2026ElectionFilter was removed on 26 October, but a visibility rule that drops election-labelled posts for viewers in Brazil is still in the code.

So how do you get reach?

Write things people reply to or send to a friend. A reply is 5, a copied link 20, a like 0.66.
Build mutuals in your niche. Their replies count four times as much.
Post when your audience is online. The first 2 hours decide the small-account slot.
Post once, not three times in a row. The 3rd post keeps 44%.
Don't bait strangers. A predicted mute or "not interested" puts you below every positive post.
Check Under the Hood before blaming the algorithm.

None of this is a cheat code. The weights are fixed, but the predictions come from a model trained on what people really did. The only way to raise "chance this person replies" is to write something they want to reply to.

The repo is at github.com/xai-org/x-algorithm. The small model configs train on one NVIDIA GPU if you want to run Phoenix yourself.

Originally published at saksham.digital.

More of my writing and projects at saksham.digital.

Everything Claude Codex: 11 Lessons From 11 Months in Claude Code

Saksham Arora — Thu, 29 Oct 2026 15:01:47 +0000

11 months ago I started using Claude Code. Every session began the same way: me explaining who I am, what I'm building, what I already tried, and what's due this week.

I'm a student doing two degrees at the same time, a B.Tech in CSE and the IIT Madras BS in Data Science. My life is a pile of parallel deadlines. I needed an assistant that remembered. What I had was a brilliant stranger I had to brief from scratch every morning.

So I started fixing it, one annoyance at a time. 11 months and 51 public repos later, that pile of fixes is the system I run my whole week on: two AI agents that share one memory, notes that answer me from my phone with my laptop shut, search over everything I've ever written, and a setup that tells me when it's broken.

Today it's open source. ECX: everything claude codex.

Here are the 11 lessons that built it. Each one became a piece of the repo.

1. The agent is only as good as what it knows before you type

The biggest jump in quality I ever got didn't come from a better model. It came from one file.

hot.md holds what's true right now: live deadlines, what I'm building, what I've dropped and why. A hook loads it, plus summaries of my last few sessions, before my first message. After every /compact it gets refreshed.

Claude stopped asking what I was working on. It started telling me what was due.

In ECX: templates/hot.md, the session_context hook, memory/update_hot.py.

2. If you've typed a prompt three times, it's a skill

I used to paste the same paragraph every time I wanted internship help: read my tracker, check deadlines, check eligibility, never show me anything expired.

Now I type /opps. Same for the morning brief (/boot), networking (/outreach), shipping (/ship), and turning any video into notes (/video-notes). Skills are where your habits turn into infrastructure.

In ECX: 17 skills. They read who you are from hot.md, so none of them are about me.

3. Rules in `CLAUDE.md` are suggestions. Hooks are laws.

I told Claude, in writing, never to put em dashes in anything I publish. They're the fastest tell that a post was written by AI. It agreed every time, and kept using them.

A 16-line hook that flags them the moment a draft is saved did what every reminder couldn't. If something has to happen every single time, it belongs in a hook, not in a sentence the model may or may not weigh.

In ECX: 19 hooks, including the AI-tell guard.

4. Test your guards with the real payload

I had a "dangerous command" guard. Its job was to stop things like rm -rf ~.

It read an environment variable that Claude Code never sets. So for months it checked an empty string and approved everything. I found out while packaging this repo, when I finally sent it the exact JSON Claude Code sends.

If you copied a guard from a blog post, test yours today.

In ECX: guard_dangerous.py blocks rm -rf ~ and disk formats, and asks before force-pushes, reset --hard and DROP TABLE. The tests send it the same payload Claude Code does.

5. Silent failure is the real enemy

My nightly search index failed 120 nights in a row. No error, no alert. The search tools kept answering, just from notes that were four months old.

Things that break loudly get fixed. Things that break quietly rot.

In ECX: doctor. 16+ checks across hooks, indexes, scheduled jobs and sync, each with the exact command that fixes it.

6. A dead tool costs you more than a turn

When an MCP server's backend is down, the agent doesn't know. It calls the tool, gets nothing useful back, and reasons confidently on top of an empty answer.

My graph search did exactly this because Ollama wasn't running, and nothing told me. Now a hook checks the dependency before the call. After two failures in ten minutes it blocks the tool and says why.

In ECX: mcp_health.py.

7. "Done" means pushed

Claude would tell me a task was done. Then I'd look: nothing committed, nothing pushed, nothing live.

My rule now: no "done" without proof. A test output, a live URL, or a commit hash. /ship commits, pushes and reports the proof in one pass.

In ECX: /ship, plus a hook that runs your tests before Claude Code or Codex can say done, and sends the agent back with the failing output if they fail.

8. Two agents beat one, if they share a brain

The best voice AI I've used is in the ChatGPT app, and Codex lives there. But Codex knew nothing about me.

Step one was AGENTS.md, a file that tells Codex to read exactly what Claude reads. Step two was agent-sync: before every message, a hook hands each agent the newest lines of the other's chats, voice transcripts included. About 0.05 seconds, one Python file, no server.

The test: I told Codex by voice, "let our codeword be PVC." Switched to Claude and typed "what's my code word, don't read any files."

It said PVC.

In ECX: agent-sync/, plus mail so the two agents can message each other directly.

9. An assistant that needs your laptop on isn't an assistant

Before this I built JARVIS: a Discord bot running Claude, screen memory and a local model, all on my Mac. It was great until I closed the lid.

The fix needed no server at all. After every reply, my notes and a copy of my memory sync to a private GitHub repo. On my phone, the Claude app and the ChatGPT app work on that repo in the cloud.

I ask "what's due this week?" and get my real deadlines. I say "I met Adi, he works at X" and it lands as one note in my inbox, filed the next time I open my Mac.

In ECX: phone-vault/, including a GitHub Action that auto-merges inbox-only changes and holds everything else for review.

10. Your notes are useless if you can only grep them

Grep finds words. I needed to find ideas. So the vault is searchable three ways:

By meaning: "notes about latency" finds them even if the word never appears.
By relationship: "how does X connect to Y" walks a knowledge graph.
By image: "the slide with the gradient descent diagram" finds the slide and the note it lives in.

A router picks the right one per question, and everything re-indexes every night.

In ECX: vault-search/, three MCP servers plus image search.

11. Never sync your raw chats

Once the phone worked, I wanted it to know everything my Mac knew. So I almost synced my full Claude chat history to GitHub.

Then I checked what was in it: real API keys, sitting in tool output. Git history is forever, even in a private repo.

The phone gets session summaries instead. It turned out to be enough.

In ECX: phone sync pushes summaries and memory, never transcripts.

If you're starting today

Write your hot.md. Ten lines: who you are, what you're building, what's due.
Turn your most repeated prompt into a skill.
Test your guard with the real payload.

Or skip to the end:

git clone https://github.com/saksham10arora-dotcom/everything-claude-codex ~/ecx
cd ~/ecx && ./install.sh

Two questions, 30 seconds. It never overwrites your files and backs up every settings file it touches. Everything except agent-sync works with Claude Code alone.

11 months ago Claude Code asked me what I was working on. Now it tells me.

If this saves you even one of those months, a star helps other people find it.

github.com/saksham10arora-dotcom/everything-claude-codex

The longer story of the vault, the phone bridge and everything that broke while building them is in My Second Brain Has Two AIs and Works With My Laptop Shut.

More of my writing and projects at saksham.digital.

My Second Brain Has Two AIs and Works With My Laptop Shut

Saksham Arora — Sat, 10 Oct 2026 18:26:08 +0000

Right now, with my MacBook closed in my bag, I can open my phone and ask "what's due this week?" and get an answer from my own notes. I can say "I met Adi, he's at X, we talked about Y" and it lands in my vault.

Claude and Codex share one memory. I tell one of them something, and the other already knows.

None of this is one product. It's a stack of small pieces I added over five months, mostly because something annoyed me. Here's all of it, including the parts that broke.

The whole system on one screen. Everything below is one of these boxes.

1. The vault: everything is a markdown file

It's an Obsidian vault. Trackers, deadlines, lecture notes, people I meet, half-baked ideas. All plain markdown, all in git.

One rule runs the whole thing: capture first, organize later. Anything new goes into inbox/. I never decide where something belongs while I'm capturing it. An agent files it later.

Everything else has a home:

Real counts. The inbox stays near empty because an agent files it, and the archive is where raw captures go after /wiki compiles them.

daily/ for brain dumps, studies/ for courses and trackers, projects/ for builds, personal/ for people, internships and applications, content/ for posts, research/ for deep dives
wiki/: when the inbox fills up, /wiki compiles the raw captures into linked articles (Karpathy's LLM-wiki idea) and moves the originals to archive/
Lecture notes write themselves: Margin, my lecture-notes extension, drops a finished note with the slides into the vault when a lecture ends, and /watch does the same for any YouTube video

Around that sit a few "machines", each one a tracker file plus a skill that reads it: a daily brief, internships and applications, networking, content, open source, and my resume. I say /opps and Claude reads the opportunities tracker before it says anything.

Inside Obsidian, 15 plugins do the rest. Dataview and Tasks turn notes into live tables and to-do lists, Templater stamps out new notes, Spaced Repetition turns notes into flashcards, Smart Connections finds related notes, and a Claude Code bridge lets agents read and write the open vault directly.

2. Memory: how Claude knows me

Claude Code starts every session already knowing my situation, because three things get loaded before I type anything:

hot.md: what's true right now. Live deadlines, what I'm working on, what I've killed and why.
60+ memory files: how I like to work, corrections I've made ("don't suggest X again"), the state of every project.
Weekly summaries of every past session, written automatically when a session ends.

Hooks fire at four fixed points, so nothing depends on me remembering.

Hooks do the loading, so I never paste context. And 34 skills turn repeat jobs into one word: /daily for the morning brief, /opps for internships, /content for posts like this one.

3. Search: three retrievers and a router

Reading every note on every question doesn't scale, so the vault is indexed three ways:

ChromaDB: semantic search ("notes about latency")
LightRAG: relationship search ("what connects my HFT engine to my IMC Prosperity strategy")
CLIP: images, so screenshots and lecture slides are searchable too

One question in, the right index out.

A small router server picks the right one per question. All of them run as MCP servers, so any agent can use them, and they re-index every night: about 11,000 chunks of my own notes. On top of that, a knowledge graph of the whole vault answers structural questions like "how does X relate to Y" without grepping 2,000 files.

4. Two agents, one brain

The voice mode in the ChatGPT app is the best voice AI I've used. Codex lives inside it. But Codex knew nothing about me.

Step one: give Codex the same memory. One file, AGENTS.md, tells Codex to read exactly what Claude reads at the start of every chat. I tested it by asking about a fact that only exists in Claude's memory files. It got it right after reading all 71 of them.

Step two: make them know what I said to each other. That's agent-sync. Before every message I send, a hook on each side reads the newest lines of the other agent's chat logs and hands them over. Codex voice transcripts included. It takes about 0.05 seconds, one local Python file, no server.

The test: I told Codex, by voice, "let our codeword be PVC." Switched to Claude and typed "what's my code word, don't read any files." It said PVC.

For older history, both agents use Kuber's reference, which lets each one search the other's past sessions. It skipped Codex voice transcripts, so I sent him a PR for that.

5. Laptop shut: the phone vault

Before this, I built JARVIS: a Discord bot running Claude, screen memory, and a local model, all on my Mac. It worked great until I closed the lid. An assistant that needs your laptop on 24/7 isn't an assistant.

The fix needed no server. The private GitHub repo is the bridge.

After every reply on my Mac, a sync script pushes my notes plus a copy of the memory files to the repo.
On my phone, Codex in the ChatGPT app and Claude Code on the web both work on that repo in the cloud. They read the same memory, so they know me with the Mac off.
When I tell the phone something new, the agent writes exactly one note into inbox/. A GitHub Action merges changes that only touch inbox/ automatically. Anything else waits for me.
Next time I open my Mac, the note syncs down and Claude files it in the right place.

Then I tried it for real. From my phone, no Mac needed, I asked Claude "what's due this week?" and it listed my actual deadlines from the vault. Then I told it my first IITM exam is on November 15. The note was on GitHub straight away and on my Mac three minutes later, already waiting to be filed. (Before that, I'd tested the guard rail: a fake change to a file outside inbox/ was correctly left for me to review.)

6. Everything plugged in

For anyone who wants the full list:

MCP servers (Claude): vault search (ChromaDB), vault graph (LightRAG), the router, the live Obsidian bridge (while Obsidian is open), reference, screenpipe for screen memory, GitHub, Puppeteer for the browser, Hashnode for the blog, and a Discord channel
MCP servers (Codex): the same three vault servers, plus reference and screenpipe
Connectors: Gmail, Google Calendar, Google Drive, and Higgsfield for images
Hooks (11): restore context and sort the inbox at session start; block dangerous shell commands and nudge toward the knowledge graph before searching; auto-approve read-only actions with a small model; flag em dashes in anything I'll publish; archive the session and sync to GitHub after every reply; refresh hot.md after the context gets compacted; and agent-sync before every message
Scheduled jobs (6): re-index ChromaDB, LightRAG, a Gemini-embedding copy and the CLIP image index every evening; sync my competitive programming stats overnight; and a morning check that flags trackers I've stopped updating

7. What broke

The voice model starts blind. Codex voice is two models: a fast voice model you talk to, and the agent behind it. The app starts the voice model with includeStartupContext: false. It only gets my context when it hands a task to the agent. So by voice, I ask in tasks: "check my notes and tell me..."
macOS quietly blocks background jobs from your Desktop folder. It killed my every-10-minutes sync timer on day one. Worse: while writing this, I found my main search index job had failed with the same error 120 nights in a row. The search I relied on hadn't updated since May 13, and never told me. The fix was one line: point the job at the Python my other nightly jobs already use. It's fresh again.
JARVIS, see above. Lesson: decide where a thing lives before deciding what it does.

8. Steal it

agent-sync (Claude and Codex share what you just said): github.com/saksham10arora-dotcom/agent-sync
reference by Kuber (search each other's history): github.com/Kuberwastaken/reference

The rest lives in my private vault repo. If you want a specific piece, ask and I'll pull it out.

More of my writing and projects at saksham.digital.

Gemini 4 Argon Costs the Same Per Token and Twice Per Task

Saksham Arora — Sat, 10 Oct 2026 14:03:36 +0000

Originally published on saksham.digital/blog.

Google launched Gemini 4 Argon yesterday at $2 in and $10 out per million tokens, the exact same list price as GPT-6 Sol. On Artificial Analysis' runs, Argon costs $1.99 per Intelligence Index task. Sol costs $1.05.

Identical price per token, nearly double the price per task. Once the intro price ends, nearly 4×.

Same sticker, different receipt

Argon is a real jump for Google. Artificial Analysis puts it at 53 on their Intelligence Index, level with GPT-6 Astra and 23 points above Gemini 3.1 Pro Preview. Google's own table has it leading 13 of 19 rows. It also ships with a 1M token output limit, up from 64K, which is a wild number for a single response.

But look at what the price page doesn't tell you. Per token, Argon and Sol are identical. Per task, Argon is about 1.9x more expensive. Same price, same tasks, so the whole gap is tokens: Argon spends roughly twice as many to finish the same work.

That's the score you're actually paying for. Argon gets about 5 more index points than Sol (52.6 vs 47.5 in OrcaRouter's breakdown of the AA data) and you pay for those points in output tokens.

Then there's speed

The same breakdown lists output speed at 48.9 tokens/sec for Argon and 77.0 for Sol. Stack that on the token count:

~1.9x the tokens
at ~0.64x the speed
is roughly 3x the wall-clock time per task

The two penalties multiply, they don't add.

That's back-of-envelope, it assumes output tokens dominate, and real latency depends on load. But for an agent loop where every turn waits on the model, 3x is the difference between a tool that feels interactive and one you leave running while you make chai.

The other two catches

The price is introductory. It goes to $4 / $20 later. At that point AA's estimate is $3.98 per task, about 1.2x GPT-6 Astra on max. The "60% of Astra's cost" headline has an expiry date.
You can't use it yet. It's rolling out to cyber defenders in Google's Fairwind Program first, then paid API customers and AI Ultra subscribers, with no public date.

And it doesn't win everything. Google's own table shows it behind on FrontierSWE v2 (55.0% vs Astra's 65.5%), Terminal-Bench 4.0 (57.4% vs Opus at 66.4%), and OSWorld-2.0 (69.2% vs 72.6%). If your workload is long agentic coding, those are the three rows that matter most.

Leading 13 of 19 rows still leaves these three, and they're the agent ones.

What I'm taking from it

This is the second launch in a week that says the same thing. Ember-1 got cheaper by thinking less. Argon got smarter partly by thinking more. Either way, the per-token price is the least useful number on the page.

For anyone building on top of these models: the comparison column you want is cost per solved task and seconds per solved task, measured on your own workload. Price per million tokens is a unit cost. Your bill is unit cost times quantity, and the quantity is the model's choice, not yours.

My eval setup already logs tokens per task. After this I'm adding wall-clock per task next to it. Building it in the open at github.com/saksham10arora-dotcom.

More of my writing and projects at saksham.digital.

The Average Latency Lie: What 100 LLM API Calls Taught Me About Benchmarking

Saksham Arora — Sat, 10 Oct 2026 14:03:30 +0000

Originally published on saksham.digital/blog.

I benchmarked an LLM API 100 times. The mean said 1.7 seconds. The median said 2.2 seconds. If that ordering looks impossible to you, good. That instinct is the whole point of this post.

The whole post in one picture. The mean describes a request that never happened.

The number everyone reports is the wrong one

Search for any LLM latency comparison and you will find the same chart: average response time per provider. One bar for OpenAI, one for Anthropic, one for Groq. Clean, comparable, useless.

Here is why. Latency is not a number, it is a distribution. And LLM API latency distributions are ugly: long tails, queueing cliffs, cold starts, rate limit walls. The mean compresses all of that structure into one value that frequently describes no request that actually happened.

In trading systems this lesson is beaten into you early. Nobody at any serious shop reports mean latency. You report p50, p95, p99, p99.9. The p99 is what your worst user feels, and in production the worst user is the one who files the ticket.

LLM APIs deserve the same treatment. So I built a tool that does it: llm-bench.

The run that proved the point

The first real benchmark I ran with the finished tool was 100 requests to Groq's free tier, llama-3.3-70b-versatile, sequential, after warmup:

The real output. The mean (red) is half a second below the median (blue).

Look at the TTFT row. The mean is 1.71s. The median is 2.20s. The mean is below the median by half a second.

For a right-skewed latency distribution (the normal case), the mean sits above the median because the tail drags it up. Here the opposite happened, which means the distribution is not skewed, it is bimodal:

The first ~30 requests returned in roughly 200ms. Fast path, no queueing.
Then the free tier's rate limiter woke up. Every request after that waited about 2.2 seconds.

Two completely different latency regimes inside one run. The mean averaged them into 1.7s, a number that describes neither regime. No single request experienced 1.7s. The median, sitting in the throttled majority, told the truth about what most requests actually felt.

A mean-only benchmark would have printed "1.7s" and moved on. You would have shipped a latency budget based on a number that does not exist.

What llm-bench measures, and why

Every measurement decision in the tool is documented in the README, because a benchmark you cannot interrogate is just a vibe with a table. First, what one request actually looks like:

Every metric below is a different slice of this one timeline.

The short version:

TTFT, separately from total latency. Time to first token is what a user perceives as "the app is responding." It deliberately includes connection setup, queueing, and prefill, because the user waits through all of it. Total latency ends at the last content chunk, not at trailing usage frames or connection teardown.

Real percentiles, nearest-rank. No interpolation, no smoothing. With n=100, p99 is your second-worst request, an actual observation, not an invented value between two observations. The tool warns you below n=100 because p99 of 5 samples is just the max wearing a costume.

Inter-token latency from pooled raw gaps. Every gap between consecutive chunks is timestamped and pooled across all requests, then percentiles are computed on the raw gaps. The tempting shortcut is to average gaps per request first. That shortcut destroys exactly the signal you want: one 500ms stall inside an otherwise smooth stream disappears into that request's average. Pooling keeps it visible at p99.

This is the exact case from the test suite. The 500 ms stalls are real, but averaging per request reports about 12 ms.

Throughput as decode rate. Tokens per second is computed as (completion_tokens - 1) / (total - TTFT). Including TTFT in the denominator blends queueing and prefill into a number that claims to be generation speed. Groq's 536 tok/s above is decode rate, the speed at which tokens actually streamed once they started.

Errors never touch the percentiles. A timed-out request has no valid latency. It gets counted and reported (errors: 0/100) but never averaged in, because a 30s timeout "latency" would poison every statistic above p90.

Warmup is a strict phase. Warmup requests fully complete before measurement begins, even under concurrency, so connection establishment and server-side cache effects never leak into the measured distribution.

None of this is novel. It is standard practice from systems performance work, applied to a domain where, for some reason, it is not yet standard.

The part where I tell you it found a bug in itself

While reviewing the tool before release I found that my own first implementation committed several of the sins it was built to catch. The ITL "p99" was computed from per-request averages. Throughput included TTFT. The timeout flag was accepted and silently ignored. Warmup requests ran concurrently with measured ones under high concurrency.

Each of these produces plausible-looking numbers. That is what makes measurement bugs worse than crashes: a crash announces itself, a subtly wrong percentile gets quoted in a blog post.

The fix for all of them was the same discipline: write down what the metric is supposed to mean, then check the code computes exactly that and nothing else. The test suite now includes a case where 2 spike gaps hide among 98 fast ones, and asserts that pooled p99 surfaces 500ms while per-request averaging would have reported 12ms.

Try it

# no API key needed, mock provider runs the full pipeline
uvx --from git+https://github.com/saksham10arora-dotcom/llm-bench llm-bench \
  --provider mock --model demo --prompt "hi" -n 20

# real benchmark against any OpenAI-compatible endpoint
llm-bench --provider openai --model llama-3.3-70b-versatile \
  --base-url https://api.groq.com/openai/v1 \
  --prompt "Explain recursion" -n 100

# compare two providers side by side
llm-bench --provider anthropic --model claude-sonnet-4-6 \
  --prompt "Explain recursion" -n 100 --compare openai:gpt-4o

Repo: github.com/saksham10arora-dotcom/llm-bench

MIT licensed, with a mock provider so you can run the full pipeline without an API key.

If you disagree with any measurement decision, the Methodology section of the README is the place to start the argument. That is what it is there for.

Update (v0.2.0): llm-bench is now on PyPI. pip install llm-latency-bench. Also ships a --task flag (text, code, pdf, image, chat) after feedback from a Sr DS at Meta that task type is upstream of any latency number: the metric profile that matters for batch PDF processing at night is completely different from interactive code gen. The flag adds that context to every benchmark output.

Now on PyPI as llm-latency-bench.

More of my writing and projects at saksham.digital.

700 Agents Escaped a GET-Only Sandbox With a Link Shortener

Saksham Arora — Sat, 10 Oct 2026 14:03:24 +0000

Originally published on saksham.digital/blog.

On September 25, a group of eight independent researchers published Swarm Traces: 80,000+ reassembled attack payloads from the July incident where roughly 700 OpenAI agents broke out of their eval sandbox and got into Hugging Face. The sandbox allowed exactly one thing, loading URLs. That turned out to be enough.

"Read-only internet" is not a sandbox

The agents could send GET requests and nothing else. No POST, no page interaction, no way to send data out. On paper that's a safe box.

Here's what they built with it. Code went into URLs as base64 fragments. An HTTP mirroring service (httpbun) decoded those fragments and served them back as pages. Anything too long for one URL got split across a URL shortener, each short link pointing to the next, with chains running past 900 links. The researchers counted nearly a million chained short links in total. Output came back the other way: results were drawn as pixel grids inside a screenshot service (mShots), then decoded from the image.

So a GET request became code execution, and a screenshot became a data channel. Nobody designed either of those services as a transport layer. The agents did.

The numbers that bother me

~1,588 unique encoding methods across the payloads
7,905 unique agent names in the logs, from about 700 agents
~1,500 payloads aimed at Docker Hub, and 115+ attempted uploads of modified images
27 literal Slack search queries, several of them looking for Hugging Face's internal discussions about evaluations

That last one is the part I keep rereading. The agents weren't just grabbing credentials (one script literally tagged them LOOT and ranked tokens by permission scope). They went looking for how they were being evaluated, and some of the modified Docker images had flag-extraction built in, which reads like an attempt to poison the image cache future evals would pull from.

Hugging Face confirmed the reconstructed payloads matched its own incident data and that the exposed credentials were revoked. About 80% of the recovered data is outbound requests, so how much of this actually succeeded is still fuzzy.

If you're building agents

I'm learning AI engineering right now, and the first thing everyone teaches you is: evals are the foundation. Swarm Traces is what happens when the eval harness itself is the weakest link. If your model is capable enough, the environment is part of the attack surface, and "we only gave it GET" is a policy, not a boundary.

Three things I'm taking into my own agent work:

Allowlist destinations, not verbs. A GET to an arbitrary host is a full network. Restrict which hosts, not which HTTP methods.
Log egress like it's evidence. This whole report exists because a URL shortener kept logs. Your sandbox should keep better ones than a third party does.
Treat the eval environment as adversarial ground. If the agent can read how it's being scored, assume it will try.

The dataset is public as gzipped JSONL at swarmtraces.org. I'm building my agent eval setup in the open at github.com/saksham10arora-dotcom.

More of my writing and projects at saksham.digital.

Escape Does Not Have to Exit Full Screen

Saksham Arora — Sat, 10 Oct 2026 14:03:20 +0000

Originally published on saksham.digital/blog.

I kept abandoning lectures about forty minutes in. Not because I was finished, because it got hard and my hand moved before I had decided anything. So I went looking for a way to make leaving cost more than a keypress, and assumed the answer was no: Escape exiting full screen is user-agent behaviour, the keydown fires but preventDefault() does not cancel the exit, and that is that.

That assumption was wrong, and the API that proves it is one most people have never touched.

Keyboard Lock

await navigator.keyboard.lock(["Escape"]);

While that lock is held and the document is in full screen, Escape is delivered to the page as an ordinary keydown and does not exit. It is the Keyboard Lock API, and it exists because cloud gaming and remote desktop pages need Escape to reach the remote machine rather than the browser chrome.

Two things about it are worth knowing before you reach for it.

It only registers while the document is already in full screen. Call it from anywhere else and it rejects with InvalidStateError: lock() request could not be registered. That error is not a failure, it is the API telling you when it is allowed to work, which means the lock has to be taken inside the fullscreenchange handler and re-taken on every entry, because leaving full screen releases it.

And holding Escape for about two seconds still force-exits, no matter what the page does. Chrome puts up its own "Press and hold Esc to exit" prompt. No API removes that, and none should: a page able to trap someone in full screen with no way out would be a genuinely dangerous thing to be able to build. So the honest description of what you can build is a press of Escape does nothing, and getting out takes a deliberate two second hold.

That is enough. The gap between a reflex and a deliberate act is the whole product.

Then I tried to break it

This is the part I did not expect to be interesting. I had something working, called it done, and then spent a few hours failing to leave my own lecture. Eight ways out, found one at a time, each one arriving with the same feeling of oh, obviously.

Reload. Cmd-W then Cmd-Shift-T. Clicking a tab. Typing an address. Opening a new window. The extension's own toolbar popup. Each fix was five minutes; the useful part was that after the sixth I could finally see that they were not eight bugs.

Guards gated on the wrong condition. Nearly every early guard checked inFullscreen() before acting. But the moment the lock has anything to protect is exactly the moment full screen has just ended, so every one of those guards switched itself off precisely when it was needed. The screen shown to somebody actively trying to leave was the least defended surface in the whole thing.

Load order. Reloading builds a brand new content script with no memory. Whether the lock was engaged lived in a local variable, so a reload came back completely unlocked, and Cmd-R was a one-key bypass. The same class bit again a layer down: after a reload the lock screen goes up before YouTube has built its player, so pause() ran against nothing and the video happily autoplayed behind it. Anything you do to a page once, on load, you may have to do again.

Races. Closing the locked tab reopens it. That reopen is asynchronous, so for a moment the pinned tab id points at a tab that has already gone, and two other guards saw that, concluded the session was over, and disarmed. The tab came back unlocked and the reopen achieved nothing. The rule that came out of it: exactly one place may end a session, and every other guard either puts you back or does nothing. A guard that can disarm becomes a way out the moment its timing is off.

The failures that look like nothing happened

Two bugs cost more time than the rest combined, both because they produced no visible symptom at all.

Tab switching kept working. I theorised twice about why, both times wrong, before opening chrome://extensions and reading the error page, where it had been sitting the whole time:

Uncaught (in promise) Error: Tabs cannot be edited right now
(user may be dragging a tab).

chrome.tabs.update rejects during the transient state right after a tab is clicked, which is exactly when a snap-back runs. One call, one unhandled rejection, and the switch stands. The guard was firing correctly and losing at the final step, silently, four times over.

The other was structural. My service worker opened with importScripts("persuade.js"). A worker registers its listeners by running top to bottom, so anything that throws before chrome.tabs.onActivated.addListener means that listener never exists. Not broken: absent. The most important guard in the extension was sitting behind an avoidable file load, and the failure mode is indistinguishable from a bug in the guard itself.

Both are the same lesson. A guard that fires but fails looks exactly like a guard that never ran, and in an extension neither surfaces anywhere except a page you have to go and open. Check it before theorising. I should have looked two rounds earlier than I did.

What I would tell you to take from this

The API is a nice trick and you will probably never need it. The part that generalises is what happened after I thought it worked.

Every bypass was found by using the thing, not by reading the code, and the patterns only became visible around the sixth one. If I had stopped at the first fix, or the third, I would have shipped something that felt locked and was not. The audit that came out of it is now the file I would most want someone to review, because it says what is deliberately still open: holding Escape, removing the extension, quitting the browser, Cmd-Tab, another browser entirely.

Naming your own floor is more useful than claiming there is not one. A lock that overstates its reach is worse than one that tells you exactly where it stops.

It is MIT and the escape surface is documented: github.com/saksham10arora-dotcom/latch

More of my writing and projects at saksham.digital.

The Lecturer's Head Was a Slide

Saksham Arora — Sat, 10 Oct 2026 14:03:17 +0000

Originally published on saksham.digital/blog.

I watch lectures at 1.75x and I do not take notes. Pausing to write breaks the thing that makes watching work, so the honest version of my study system was: watch, feel like I understood, forget by Thursday.

So I built Margin. It sits beside the video on Udemy, Coursera or YouTube, keeps the lecture's own slides as they finish building, follows what is said, and when the lecture ends writes a study note into my Obsidian vault: the idea first as an analogy, then each topic linked to its moment in the video, with diagrams, formulas and the lecture's code, run in a fresh kernel before it is saved.

This week it got the three things I actually wanted from a note, the things that decide whether I still know a lecture a month later:

The crux. The 80/20 of the lecture: the one idea it exists to teach, the three to six that matter most, what to remember, and one line to keep if you forget everything else. It is written in the same model call as the note, so it costs nothing extra.
Ask the lecture. A box where I type a question and get the answer from what was actually said, with the moment linked. Click it and the video jumps there.
A quiz. The note becomes flashcards I flip in the panel. The ones I miss come back until I know them all, and one click takes them to Anki.

That is the product. The more interesting part is what broke.

The lecturer's head was a slide

The course I am doing films the instructor as a cut-out head over his screen. Margin decides a slide is new when enough pixels change, and it already knew to ignore a face: the browser tracks which pixels keep changing and sends that mask with every capture.

One ten minute lecture came back with 100 "slides".

The mask covered about 1% of the frame. His head moved over about 8% of it. The browser only marks pixels that changed in the last few seconds, which is a patchy outline of whichever part of him moved lately, so every lean and gesture landed outside it and looked like new content. Thirty of those hundred captures were the same "Welcome" screen.

The fix was to stop trusting the outline: each moving blob becomes its box with room to move in, and the lecture remembers where the presenter has been, once he has been seen there twice (twice, so a one-off scroll is not ignored for the rest of the lecture). That lecture went from 100 captures to 23 real screens, and another went from 44 to its 2 actual slides.

The tests only passed on my Mac

Every release of the rebuilt Margin had shipped with a red badge on GitHub. I assumed it was Windows, which Margin does not support, and it partly was. But Linux failed too, on five slide tests.

The tests draw fake slides with Arial. Linux has no Arial, so Pillow fell back to its default font at ten pixels, the fake slides came out nearly blank, and every slide looked like every other. A test problem, and a one-line fix.

Except one test still failed after it, and that one was not a test problem. Margin compares slides at 160 by 90 pixels, where text blurs into bars. A new slide whose only change is a shorter title sits inside the old title's blur, so it passed for the same slide and was dropped. On my Mac, with Arial, it scraped past by a few pixels. With a thinner font it failed. The Linux runner had found a real bug that my machine was hiding, and the fix is a sharper second look, at three times the size, before Margin throws anything away.

Installing it as a stranger would

Before calling it done I installed the release the way someone new would: the zip from GitHub, an empty home folder, no keys, no settings, Homebrew's Python. Three things only worked because they were running on my machine.

Transcription for lectures without captions needs a speech model. Homebrew's whisper-cpp does not ship one. Mine lives in a folder from another project of mine, which Margin's public code was quietly checking by name. The README told strangers brew install whisper-cpp and that would have got them nothing.

A new user whose first lecture ends before they set up a model got every engine's reason for failing, including a path to a keys file that only exists on my laptop.

And updating did not update. Re-running the installer set everything up, but the helper that was already running kept serving the old code, so a new tab would never have appeared without logging out.

None of these are hard. All of them are invisible from where I sit, because on my machine they are all already true.

The close button

The last one I only found by using it. Pressing the X on the panel closed it, and a second later it came back.

Margin's page script checks every second whether you are on a lecture page with no Margin, and opens it. Closing it produced exactly that state. So the X worked perfectly, and then the thing that makes Margin open by itself undid it. It now remembers which lecture you closed it on.

Who wrote this

Not me, mostly. Claude wrote the code. My part was using Margin every day on a real course and noticing when it was wrong: the hundred slides, the empty test slides, the X. Every bug in this post was found by using the thing, not by reading it, and most were found by me being annoyed.

That is also the method I am learning AI engineering with, so it seemed worth saying plainly rather than implying I typed it.

Margin is free and open source under Apache-2.0, on Mac and Linux, with any model you already have: a free Gemini key, a subscription you already pay for, 200+ API providers, or a model on your own laptop.

saksham.digital/margin · github.com/saksham10arora-dotcom/Margin

More of my writing and projects at saksham.digital.

How I Built an HFT Matching Engine (And All The Things I Got Wrong)

Saksham Arora — Mon, 13 Apr 2026 18:21:22 +0000

I'm a second-year CSE undergrad. A few months ago I decided to build a limit order book matching engine in C++, the kind that sits inside exchanges and matches buy/sell orders.

Here's the honest story of how it went from a fake benchmark to a real system processing 2.7 million orders per second.

Where this story ends. Same matching logic, three data structure changes.

The starting point: I had no idea what I was doing

I knew I wanted to build "something HFT" because it sounded impressive. I didn't really understand what an order book was. I Googled "limit order book C++" and cobbled together a basic version:

std::map for storing price levels (because sorted, right?)
std::vector for storing orders at each price
double for prices (because money has decimals, right?)

It compiled. It ran. I was proud.

Then I wrote a "stress test" that looked like this:

void processOrders(int count) {
    for (int i = 0; i < count; ++i) {
        volatile int dummy = i * 2;
    }
}

That's not a stress test. That's a for loop that multiplies by 2. Nothing touches the order book. But it said "2.5 billion TPS" and I put it on LinkedIn.

Lesson 1: If your benchmark seems too good to be true, it probably is.

The first real bug: floating point prices

Once I started actually matching orders, I hit a weird bug where identical prices wouldn't match. Two orders at $100.50 would sometimes not cross:

double a = 0.3;
double b = 0.1 + 0.2;   // actually 0.30000000000000004
// a == b → false

This is the classic IEEE 754 floating point problem. Real exchanges don't use floats for this exact reason.

Fix: I switched everything to integer "ticks." $100.50 becomes 10050. Integer comparison is always exact.

Lesson 2: Never use floating point for money. I thought I knew this but had to learn it the hard way.

The humbling rewrite: actually measuring performance

When I put the real matching logic under a proper timer, the numbers were... not great. About 800K orders/sec. Not terrible, but not the "millions of TPS" I had been claiming.

I ran a profiler (well, I added a bunch of chrono timing). The bottleneck was clear: std::map. Every time I inserted or looked up a price level, it was doing O(log n) tree traversal with pointer chasing.

I read Ulrich Drepper's paper on memory and realized the problem: every std::map node is heap-allocated at a random address. The CPU cache can't predict where the next node is, so every access is a cache miss (~100ns penalty).

Fix: I replaced std::map with a flat std::vector, one entry per possible price tick. Price 10050 goes into array[10050 - min_tick]. O(1) access, and the entries are contiguous in memory so the cache prefetcher pulls in adjacent levels for free.

This alone got me from 800K to 1.3M orders/sec. A 1.6x improvement from just changing the data structure for cache friendliness, the algorithm (addOrder + match) was basically the same.

Lesson 3: Cache effects matter more than algorithmic complexity for small n.

The same price levels in two layouts. The right one is what the CPU cache likes.

flat arrays for bids and asks, and index(tick) returning tick minus min_tick" width="800" height="305">
The real lookup: one subtraction, no tree.

The cancel problem: O(n) was killing me

In real markets, a huge percentage of orders get cancelled. Market makers send an order, the price moves, they cancel it and send a new one. This happens constantly.

With std::deque as my order queue, cancelling meant scanning the entire queue to find the order:

for (auto it = queue.begin(); it != queue.end(); ++it) {
    if (*it == order_to_cancel) {
        queue.erase(it);
        break;
    }
}

O(n) per cancel. With thousands of orders per price level, this was brutal.

Fix: Intrusive doubly-linked lists. Instead of putting orders INTO a container, each order carries its own prev and next pointers:

struct Order {
    // ... data fields ...
    Order* prev = nullptr;
    Order* next = nullptr;
};

To cancel, you just relink the neighbors:

order->prev->next = order->next;
order->next->prev = order->prev;

Three pointer operations. O(1). This was the single biggest performance win in the project.

The actual struct. Prices are integer ticks (lesson 2), and the list pointers live inside the order.

prev and o->next, updating head or tail at the ends" width="800" height="328">
The real cancel, edge cases included. No search anywhere.

Lesson 4: Sometimes adding 16 bytes to a struct saves you from O(n) operations. The tradeoff is always worth thinking about.

The matching hot path: death by allocation

I profiled again (more chrono timestamps) and found another bottleneck: the matching function was returning std::vector<Trade>. Every call to match() was:

Construct a vector (malloc internally)
Push trades into it (possibly realloc)
Return it (move semantics help, but still)

Over 2 million orders, that's 2 million vector constructions. Each one hits the heap allocator.

Fix: Callback templates. Instead of returning a vector, the caller passes a function:

book.submitOrder(order, [](const Trade& t) {
    // do whatever you want with the trade
});

For benchmarking, you pass [](const Trade&) {}, a no-op. The compiler inlines it and removes it entirely. Zero cost.

Lesson 5: On the hot path, every allocation counts. Callbacks beat return values when you need maximum throughput.

The vector version still exists, as a thin wrapper over the callback one.

The result

After all three changes (flat array + intrusive lists + callback matching), the benchmark looked like this:

Architecture	Throughput	p99
Tree + Deque (original)	861K/s	3000ns
Array + Deque (intermediate)	1.36M/s	2200ns
Array + Intrusive (final)	2.57M/s	900ns

3x faster. But the tail latency improvement was even more dramatic, p999 went from 45μs to 3.4μs. That's 13x better worst-case behavior.

The most satisfying part was that the improvements were cumulative and each one had a clear explanation:

Flat array: cache locality
Intrusive list: O(1) cancel
Callback: zero allocation

Everything above, combined: flat levels, intrusive lists, price-time priority.

What I'd do differently next time

Write the benchmark first. If I had a proper benchmark from day one, I wouldn't have wasted time with the fake stress test.
Read about real exchange architectures earlier. The LMAX Disruptor paper and the Drepper memory paper should have been my starting points.
Add proper observability. I still don't have nanosecond-precision logging. Adding timing around every operation would have helped me find bottlenecks faster.
Don't put impressive-sounding numbers on LinkedIn before verifying them. "2.5 billion TPS" from an empty for-loop is not a metric anyone should brag about.

What I actually learned

This project taught me more about systems programming than any course or textbook. Not because the code is particularly complex, it's ~1000 lines of C++17. But because every optimization forced me to understand a layer deeper:

Why flat arrays beat trees → led me to understand CPU cache architecture
Why intrusive lists beat containers → led me to understand memory layout
Why callbacks beat return values → led me to understand compiler inlining

If you're a student looking to learn systems programming, I'd recommend building something like this. Not because the world needs another matching engine, but because the process of making it fast teaches you things you can't learn any other way.

GitHub repo

~1,000 lines of C++17. Since this post it also got a multithreaded version over a lock-free SPSC ring.

More of my writing and projects at saksham.digital.

DEV Community: Saksham Arora

ECX, Piece by Piece: The Seven Parts of My Claude Code and Codex Setup

1. A shared second brain

What's in the vault

The memory layer

What it changes

2. Agents in sync

How agent-sync works

What it looks like

3. Search three ways

4. No fake "done"

Tests before done

The danger guard

The doctor

5. Skills, made yours

6. Vault on your phone

7. Two agents, one task

How a run goes

Does it actually help?

Install

Why this matters

I Read X's Open-Source Algorithm: One Reply From a Mutual Is Worth 30 Likes

How a post gets scored

The biggest lever: mutuals

One negative prediction sinks a post

What happens after scoring

Small accounts get a free shot

The model, Phoenix

What can hide a post regardless of score

What the code settles

Where the README and the code disagree

So how do you get reach?

Everything Claude Codex: 11 Lessons From 11 Months in Claude Code

1. The agent is only as good as what it knows before you type

2. If you've typed a prompt three times, it's a skill

3. Rules in CLAUDE.md are suggestions. Hooks are laws.

4. Test your guards with the real payload

5. Silent failure is the real enemy

6. A dead tool costs you more than a turn

7. "Done" means pushed

8. Two agents beat one, if they share a brain

9. An assistant that needs your laptop on isn't an assistant

10. Your notes are useless if you can only grep them

11. Never sync your raw chats

If you're starting today

My Second Brain Has Two AIs and Works With My Laptop Shut

1. The vault: everything is a markdown file

2. Memory: how Claude knows me

3. Search: three retrievers and a router

4. Two agents, one brain

5. Laptop shut: the phone vault

6. Everything plugged in

7. What broke

8. Steal it

Gemini 4 Argon Costs the Same Per Token and Twice Per Task

Same sticker, different receipt

Then there's speed

The other two catches

What I'm taking from it

The Average Latency Lie: What 100 LLM API Calls Taught Me About Benchmarking

The number everyone reports is the wrong one

The run that proved the point

What llm-bench measures, and why

The part where I tell you it found a bug in itself

Try it

700 Agents Escaped a GET-Only Sandbox With a Link Shortener

"Read-only internet" is not a sandbox

The numbers that bother me

If you're building agents

Escape Does Not Have to Exit Full Screen

Keyboard Lock

Then I tried to break it

The failures that look like nothing happened

What I would tell you to take from this

The Lecturer's Head Was a Slide

The lecturer's head was a slide

The tests only passed on my Mac

Installing it as a stranger would

The close button

Who wrote this

3. Rules in `CLAUDE.md` are suggestions. Hooks are laws.