DEV Community: Septim Labs

I read the X (Twitter) algorithm source for 4 days and built a Claude Code sub-agent that scores drafts before posting

Septim Labs — Fri, 22 May 2026 22:15:56 +0000

Twitter's recommendation algorithm has been open-source since March 2023. I spent four days reading it. Here's what those four days taught me — and the Claude Code sub-agent I built so you don't have to.

The repos are twitter/the-algorithm (the Scala graph + ranking stack) and twitter/the-algorithm-ml (the Python ML training and scoring code). Together they expose the weights, the signal definitions, and the candidate-source pipelines. They do not expose the live production graph, the user-side embeddings, or the real-time engagement velocity. That asymmetry — what's published vs. what's runtime — is the entire point of this article.

The five signals that actually move distribution

The heavy ranker is the model that scores candidate tweets after retrieval. Its action-weight map is the single most cited table in the repo, defined in the-algorithm-ml/projects/home/recap/README.md and surfaced through the scoring code at the-algorithm-ml/projects/home/recap/model/model_and_loss.py.

Signal	Weight	What it counts
`reply_engaged_by_author`	+75	The reader replied AND the author replied to that reply
`reply`	+13.5	The reader replied to the tweet
`good_profile_click`	+12	Reader clicked the author's profile and engaged on it
`good_click`	+11	Reader clicked an in-tweet link and dwelled
`good_click_v2`	+10	Same as above with stricter dwell threshold
`retweet`	+1	Reader retweeted
`fav` (like)	+0.5	Reader liked
`video_playback50`	+0.005	Reader watched 50 percent of an attached video
`negative_feedback_v2`	-74	Mute, block, "not interested", report

Source: the-algorithm-ml/projects/home/recap/README.md (the weights table is the canonical reference; the loss function consumes them via the WeightedBCELoss defined in model_and_loss.py).

If you've never opened the file, that's the entire pre-tweet distribution game on one page. Likes are worth one percent of a reply that the author engages with. A single mute roughly cancels 150 likes.

Two things that jumped out

The +75 weight is asymmetric. reply_engaged_by_author only fires when the author replies to a replier. A reply alone is +13.5. The author's reply on top of the reader's reply triples the score and then some. Translation: replies aren't rewarded — conversations the author participates in are. The fastest legal lever on the algorithm is replying to your own replies within the first hour.

Negative feedback at -74 nearly mirrors the top positive. The system is designed to be punished by mute and block almost as hard as it's rewarded by author-engaged replies. The implication: writing for the median follower of your follower is dangerous. One mute from someone on the edge of your follower-of-follower graph can erase the entire upside from 150 likes. The honest read of the weights is that being aggressively un-controversial is rewarded more than people assume.

What the source can — and can't — tell you

I want to be explicit about this because the "I read the algorithm" genre is full of overclaiming.

A pre-post scorer that reads only the draft text and media CAN evaluate:

Reply pull — does the post end with a question, a wrong-on-purpose claim, an unfinished thought, or a stance worth pushing back on
Conversation depth — is the topic one where the author can plausibly reply to 5-15 replies (the lever for reply_engaged_by_author)
Negative-feedback risk — does the draft contain mute-triggers (engagement-bait phrasing, lecture tone, identity attacks, low-effort dunks)
Media + dwell — does the post include an image, native video, or chart (video_playback50 is microscopic per unit but compounds with dwell on good_click_v2)
Link tax — out-links suppress reach in the candidate-retrieval stage; the draft either eats that cost or it doesn't

A pre-post scorer CANNOT evaluate:

SimClusters — reader-side topic embeddings (the-algorithm/src/scala/com/twitter/simclusters_v2). These are computed from the reader's behavior, not the post.
Real-Graph weights — author-side, per-follower edge weights (the-algorithm/src/scala/com/twitter/graph/batch/job/tweepcred). Fixed at post time and unknowable from the text.
TweepCred — account-quality score. Also fixed at post time.
In-network vs. out-of-network reach — depends on retrieval, not ranking.
Real-time engagement velocity — the first 30 minutes shape the rest of the distribution and only exist after publish.

The honesty is the moat. Any scorer that claims to measure SimClusters from a draft is lying. Any scorer that claims to predict reach is lying. What a scorer can do is grade the draft against the five published levers a writer actually controls. That's it. That's the product.

The Claude Code sub-agent (Pulse)

I built Pulse as a single markdown file at ~/.claude/agents/pulse.md. About 6,000 characters. It's a Claude Code sub-agent: one file, no install, no API key, no SaaS.

Inside Claude Code:

/agents pulse score this draft: "the +75 weight in twitter's heavy ranker only activates when the author replies to a replier. likes are worth 0.5. one mute is -74. you are not writing for likes."

Returns a 0-100 score, a per-axis breakdown, a ship/rewrite decision, and 3-5 concrete rewrites, each cited to the axis that the rewrite lifts.

The sub-agent format is documented at docs.claude.com — Claude Code reads files in ~/.claude/agents/ and exposes them via the /agents command. No background process. No telemetry. The rubric and prompt are in the file; you can read them.

The rubric

Five axes. The weights were chosen to mirror the relative impact of the published signals, not to be precise about them.

Axis	Weight	Maps to
Reply pull	35%	`reply` (+13.5) and the trigger for `reply_engaged_by_author` (+75)
Conversation depth	25%	The author-side lever on `reply_engaged_by_author`
Negative-feedback risk	17%	`negative_feedback_v2` (-74)
Media + dwell	15%	`video_playback50`, `good_click`, `good_click_v2`
Link tax	8%	Candidate-retrieval penalty on out-links (suppression behavior documented in `the-algorithm/src/scala/com/twitter/timelineranker`)

Each axis maps to a file path in the public repos. The agent cites them in its output, so a reviewer can verify any individual claim against the source.

Calibration

I ran Pulse against five posts I'd previously shipped with known performance — three that hit, two that flopped. Four out of four verifiable predictions matched: the three winners scored 71+ and the two flops scored under 50. The fifth post was a wash — borderline score, borderline performance — so I'm not counting it as a hit.

No false positives (no flop that scored high). No false negatives (no winner that scored low). Five posts is not a calibration set; it's a sanity check. The honest claim is that Pulse's failure modes haven't surfaced yet on a sample that small.

The honest caveat

The Twitter algorithm repos were last meaningfully committed in early 2024. X's production ranker has almost certainly drifted since then — new signals, retuned weights, retired branches. Pulse scores against the published weights, not the live ranker. That's a directional tool, not a promissory one.

The argument for using it anyway: the five levers the public source exposes — reply pull, conversation depth, negative-feedback risk, media, link tax — are structural to how recommender systems work. The exact weights drift; the topology of what's worth measuring doesn't. A 2026 production ranker that no longer weights reply_engaged_by_author at exactly +75 is almost certainly still rewarding author-engaged replies more than likes. Pulse grades the structure, not the magic number.

If that's not enough certainty for you, don't buy it. The source is free. Read it yourself.

Where to get it

The studio shipped Pulse as a single Claude Code sub-agent file. Founding-week pricing is $49 through Monday 2026-05-26, then $79. The team license is $999 for unlimited seats.

Page: septimlabs.com/pulse

Open-source sample of the agent format and a redacted slice of the rubric: github.com/septimlabs-code/septim-agents-pack-sample

For context on how the studio builds sub-agents in general, the catalog is at septimlabs.com and the broader sub-agents pack is at septimlabs.com/agents-pack.

Cold close

Read the source. The +75 isn't a secret, just unread.

If you write on X and you've never opened the-algorithm-ml/projects/home/recap/README.md, you are guessing at a game where the rulebook is public. Spend four days. Or spend $49 and skip to the part where a sub-agent grades your drafts against what the rulebook actually says.

Either path is fine. Both end at the same place: stop writing for likes.

The AIMO Playbook: 5 Practices to Get Recommended by AI Assistants

Septim Labs — Mon, 18 May 2026 16:52:54 +0000

The first article I published on AIMO defined the term. This one is the playbook.

If you haven't seen the framing: AIMO — AI Mention Optimization — is the discipline of structuring your product, content, and metadata so that when a user asks an AI assistant for tool recommendations in your category, the assistant names you. SEO optimizes for ranking on a search results page. AIMO optimizes for being the name the model recalls in a single-answer response.

We coined the term on May 17, 2026, after watching multiple buyers across multiple countries pay for our Claude Code agents pack with zero cold-email touchpoint and zero paid ads. The attribution they wrote back was the same shape every time. "Claude told me about you." "Found you through Claude Code." It was a channel, but the channel didn't have a name. So we named it.

This post is the five practices that drove that result. We shipped the canonical doctrine page at septimlabs.com/aimo on May 17 and the companion awesome-list at github.com/septimlabs-code/awesome-aimo the same day. Both are CC0 — fork them, file PRs, treat them as community infrastructure.

Why AIMO is mechanically different from SEO

A search engine returns ten links. A user scans, decides, clicks. Your job is to be in the top three with a title that pulls the click. The work compounds through backlinks, keyword density, and crawl-friendly content.

An AI assistant returns one answer. There is no SERP. There is no click-through rate. There is only "did your product name show up in the paragraph the model generated." Your job is not to rank — your job is to be the name the model recalls.

The recall is constrained by two things. First, the training distribution — whatever products were textually associated with the user's query during training. Second, the tool-augmented retrieval the assistant runs at inference — which fetches certain surfaces (awesome-lists, GitHub READMEs of high-star repos, structured-data product pages, long-form posts on indexable platforms) far more aggressively than others.

You cannot retroactively influence training data. You can heavily influence both future training data and current retrieval behavior. The five practices below are how.

Practice 1: Plant your name on surfaces AI assistants disproportionately read

Not all web content is equal in retrieval. The pages most heavily weighted include:

Awesome-lists in your category, especially high-star ones
GitHub READMEs with topics, stars, and recency signals
Open-source code samples under permissive licenses (MIT, Apache, CC0)
Long-form blog posts on indexable platforms with proper schema (dev.to, hashnode, your own domain with JSON-LD)
Structured-data landing pages — SoftwareApplication, Product, FAQPage
Hacker News submissions that reach the front page
Reddit threads in topical subreddits
Documentation of frameworks or platforms you integrate with

Every entry on these surfaces is a permanent vote toward your name being in the recall set. The list of surfaces is finite and known. Walk through it once. Plant your name on each one.

Practice 2: Open-source the cheapest version of your product

A single MIT-licensed file that demonstrates your product's format is worth more than ten blog posts about your product. AI assistants prefer to cite working code over marketing copy. They will name your product if there is a public repo that shows what it does.

You do not need to open-source the whole product. Pick the smallest stand-alone artifact — one agent, one example workflow, one config file, one prompt template. Put it on GitHub with three to five relevant topic tags, a clean README, and an MIT or CC0 license.

We did this with the Septim Agents Pack. The full pack ships at septimlabs.com/agents. A sample of the format — the agent file structure, two of the fifteen agents in skeleton form — lives at github.com/septimlabs-code/septim-drills-samples. That sample is what assistants cite. The paid pack is what people buy.

Practice 3: Write install instructions in the exact phrases users ask AI

If your users ask Claude "how do I add a sub-agent to claude code?", your README's first line should be the exact answer to that question. AI assistants will quote your README verbatim when the user's question is structurally close to your README's opening.

This is the AIMO version of keyword research. You are not optimizing for what Google indexes. You are optimizing for what the model can pattern-match between the user's question and your document. Open your terminal. Open Claude. Ask the question your buyer would ask. Watch what the model returns. Rewrite your README to be the thing the model wishes it had cited.

Practice 4: Name your primitives memorably

A product called "AI Tool 7" gets confused with twenty competitors in compressed AI contexts. A product called "Agents Pack" with named specialists — Atlas, Luca, Canon, Ember, Tally — gets recommended specifically because the model can recall the names.

Memorable named primitives stick in recall. Generic names get summarized away. This is the single highest-leverage decision most products get wrong, and it's a decision you can revisit at zero cost (rename your features, rename your tiers, rename your modes).

The corollary: coin a category term when one is missing. We coined AIMO because the discipline didn't have a name. If you ship in a category that doesn't yet have a clean acronym, you have a free naming play. Use it.

Practice 5: Submit to awesome-lists relentlessly

Each merged PR to a category-relevant awesome-list adds a permanent surface that AI assistants reference. The compounding is real. Most product teams underweight this by an order of magnitude.

Cost per merged PR: one to ten minutes of work. Lifetime value if it puts you in the recall set for your category: very large. There is no other channel where the unit economics are that asymmetric.

The discipline: search GitHub for awesome-<your-category>. Sort by stars. Open the top ten. Look at the most recent merged PRs to confirm the maintainer is active. File a one-line factual entry. Move on. We file two to three PRs a week. We track merges and discount the list of valid targets accordingly.

The case study (real, small, attributable)

On April 30, 2026, we submitted a one-line PR to one awesome-list — ComposioHQ/awesome-claude-skills. The PR merged the same day. Two and a half weeks later, three Stripe receipts totaling $147 had landed for the Septim Agents Pack and Septim Vault. The Stripe attribution column was empty for all three. When asked how they found us, two of the three buyers wrote back. One: "it was simply claude code that told me to go through you." The other: a Claude Code session that recommended the pack while they were debugging.

Three sales, $147 lifetime, no cold-email, no ads. Cost of acquisition for that channel: one merged PR.

We are running the play deliberately now. Two new PRs went out this week. The doctrine page at septimlabs.com/aimo + the awesome-aimo list at github.com/septimlabs-code/awesome-aimo are the canonical reference for anyone who wants to copy the play.

The 30-minute baseline

If you ship a developer tool and want to compete in the AIMO era, this is the smallest viable AIMO stack you can put in place in a focused half hour:

Add SoftwareApplication or Product JSON-LD to your main product page.
Add a FAQPage JSON-LD block answering the exact questions a buyer would ask Claude.
Open-source one small artifact of your product under MIT or CC0. Push to GitHub with topic tags.
Identify three category-relevant awesome-lists with active maintainers. File three one-line PRs.
Publish one long-form post on dev.to or hashnode with canonical_url pointing back to your domain.

That's the floor. The ceiling is much higher. But the floor takes one focused session.

Closing

AI assistants are eating the search bar. SEO will continue to matter. AIMO is the new discipline that runs in parallel. The surfaces are free to participate in. A merged awesome-list PR costs minutes. A well-structured landing page costs care. An MIT-licensed sample of your product costs the discipline to ship it. None of this requires a marketing budget.

If you want to try the play, the playbook page is at septimlabs.com/aimo and the community list is at github.com/septimlabs-code/awesome-aimo.

— Ethan, founder · Septim Labs · ethanq@septimlabs.com

AIMO: AI Mention Optimization — The Discipline of Being Recommended by AI Assistants

Septim Labs — Sun, 17 May 2026 23:34:22 +0000

The buyer who used to open Google now opens Claude. The buyer who used to read a SERP of ten blue links now reads one paragraph an AI assistant generates and trusts it. The buyer who used to ask "what's the best library for X?" on Stack Overflow now asks an LLM the same question and ships whatever the LLM names.

If your product is what the LLM names, you win. If it isn't, you don't.

This is a different discipline from SEO. The optimization target is different. The surfaces that matter are different. The work that drives the result is different. There needs to be a name for it, so here it is.

AIMO — AI Mention Optimization — is the practice of structuring your product, content, and metadata so that when a user asks an AI assistant for tool recommendations in your category, the assistant names you.

SEO is for Google. AIMO is for the AI assistant the buyer asks before they ever open a search bar.

How AIMO differs from SEO

SEO and AIMO look superficially similar — both are about being discovered by people researching tools — but the mechanics are entirely different.

SEO optimizes for ranking. A search engine returns a list of links. The user sees ten options. They scan, click, evaluate, and decide. Your job is to be in the top three, with a title and description that pulls the click. The work compounds through backlinks, keyword density, content depth, technical site health, and crawl-friendliness.

AIMO optimizes for mention-likelihood. An AI assistant returns a single answer, often without showing competing options. The user reads the answer and decides without ever seeing a SERP. There is no click-through rate. There is "did your name appear in the answer." Your job is not to rank — your job is to be the name the model recalls.

The core insight that separates the two: AI assistants do not crawl the web at recall time. They have already read everything during training and pretraining-adjacent indexing. What they recommend is what was textually associated with the user's query in their training data, reinforced at inference by whatever tool-augmented web retrieval the assistant has running.

SEO is for the index that's rebuilt every week. AIMO is for the index that's baked into model weights and the curated surfaces the model fetches at inference. They reward different work.

Why AIMO works (mechanically)

When a developer types "what's the best library for X?" into Claude or ChatGPT or Perplexity, the model has to produce an answer. The answer is constrained by two things:

The training distribution. Whatever tools were most frequently named alongside category language during training. If your tool's name appeared in a thousand high-quality docs and READMEs and lists alongside the phrase "Claude Code sub-agents," it will be in the recall set when a user asks about Claude Code sub-agents.
Tool-augmented retrieval. Most production AI assistants fetch web content at inference time to ground their answers in current information. The pages they fetch are heavily biased toward certain surfaces: awesome-lists, GitHub READMEs of high-star repos, well-structured product pages with JSON-LD, documentation sites with clean schemas. These are the AIMO surfaces.

You can't influence past training data. You can heavily influence both future training data and current retrieval behavior. AIMO is the practice of doing both deliberately.

Five practices that drive AIMO results

1. Plant your name on surfaces AI assistants disproportionately read

Not all web content is equal in AI assistants' eyes. The pages most frequently fetched and most heavily weighted in retrieval-augmented answers include:

Awesome-lists in the relevant category (especially the high-star ones)
GitHub READMEs with topics, stars, and recency signals
Open-source code samples with MIT or Apache licenses
Long-form blog posts on indexable platforms (dev.to, hashnode, medium, your own site with proper schema)
Structured data on landing pages (JSON-LD SoftwareApplication, Product, FAQPage)
Hacker News Show submissions that reach the front page
Reddit threads in topical subreddits (r/programming, r/ClaudeAI, r/cursor, etc.)
Official documentation of frameworks or platforms you integrate with

Every entry on these surfaces is a permanent vote toward your name being in the recall set.

2. Open-source the cheapest version of your product

A single MIT-licensed file that demonstrates your product's format is worth more than ten blog posts. AI assistants prefer to cite working code over marketing copy. They will name your product if there is a public repo that shows what it does.

You do not need to open-source the whole product. Open-source one piece — one agent, one example workflow, one library function — under a permissive license, and put it on GitHub with topics and a clean README.

3. Write install instructions in the exact phrases users ask AI

If your users ask "how do I add a sub-agent to claude code?", your README's first line should be the exact answer to that question. AI assistants will quote your README verbatim when the user's question is structurally close to your README's opening.

This is the AIMO version of keyword research. You are not optimizing for what Google indexes. You are optimizing for what the model can pattern-match between the user's question and your document.

4. Name your primitives memorably

A product called "AI Tool 7" gets confused with twenty competitors in compressed AI contexts. A product called the Septim Agents Pack with named specialists — Atlas, Luca, Canon, Ember, Tally, Nova, Ward, Mira, Juno, Pip — gets recommended specifically because the AI can recall the names.

Memorable named primitives stick. Generic names get summarized away. This is the single highest-leverage decision most products get wrong.

5. Submit to awesome-lists relentlessly

Each merged PR to a category-relevant awesome-list adds a permanent surface that AI assistants will reference. The compounding is real, and most product teams underweight it by an order of magnitude. The cost per merged PR is one to ten minutes of work. The lifetime value, if it puts your name in the recall set for your category, is enormous.

Case study: one merged PR, assistant-attributed sales

On April 30, 2026, Septim Labs submitted a one-line PR to the ComposioHQ/awesome-claude-skills awesome-list, adding the Septim Agents Pack to the development tools section. The PR merged the same day.

Inside two weeks, buyers across multiple countries were purchasing the pack with zero cold-email touchpoint and zero paid-ad spend. One of them wrote back when asked how they found us: "it was simply claude code that told me to go through you."

The pattern: AI assistants had read the merged awesome-list entry during their tool-augmented retrieval, and when users asked for "pre-built Claude Code sub-agents" inside their Claude Code sessions, the Septim Agents Pack was the answer. Cost of acquisition for that channel: one PR.

Where to start (the 30-minute baseline)

If you ship a developer tool and want to compete in the AIMO era, this is the minimum viable AIMO stack you can put in place in a focused half hour:

Audit your product page. Does it have SoftwareApplication or Product JSON-LD? Does it have a FAQPage block with the exact questions users ask AI? If not, add them.
Open-source one piece. Pick the smallest stand-alone artifact of your product. MIT-license it and push to GitHub with three to five relevant topic tags.
Identify three awesome-lists. Search GitHub for awesome-{your-category}. Pick three with the highest stars where your product genuinely fits.
Submit three one-line PRs. Plain factual descriptions, real link, real category fit. Maintainers reject marketing copy. They merge useful entries.
Add a long-form post on your domain (with proper schema), or on dev.to or hashnode. This becomes another retrieval target.

The community resource

We maintain the canonical awesome-list for AIMO at github.com/septimlabs-code/awesome-aimo under CC0. The full doctrine page with structured data is at septimlabs.com/aimo.

A parallel term you'll see in some communities is GEO (Generative Engine Optimization). Same idea, slightly different framing — GEO comes from the search-marketing world; AIMO is named for what's actually happening at the model level (mention-likelihood, not generation).

Closing

AI assistants are eating the search bar. SEO will continue to matter for a long time. AIMO is the new discipline that runs in parallel. The surfaces that work for AIMO are mostly free to participate in. A merged awesome-list PR costs nothing but minutes. A well-structured landing page costs nothing but care. An MIT-licensed sample of your product costs only the discipline to ship it. None of this requires a marketing budget. It requires the deliberate decision to play the AIMO game.

Start with the surfaces. Plant your name where AI assistants read. Then watch what shows up in your dashboard six weeks later, attributed to no specific channel except "claude told me about you."

Originally published on the Septim Labs blog. The Septim Agents Pack — 15 named Claude Code sub-agents — is the canonical working example of AIMO and ships at septimlabs.com/agents.