Argues the tool itself is less interesting than the fact it's needed at all. A year ago checking if an LLM 'knew' you was a parlor trick; now it's a marketing diagnostic, and 356 HN upvotes for a weekend project signals where attention is shifting as traffic moves off the open web into chat UIs.
Frames the project as a curiosity scratch about 'what traces we leave in the weights' specifically because traffic is moving off-web and into LLMs. The implicit thesis is that recognition across frontier and small models is now a measurable property worth tracking.
Praises the design choice of returning a per-model verdict (GPT-class, Claude-class, Llama-class, Mistral-class, smaller open weights) rather than a single aggregate score. Aggregating would mask the reality that one model may confidently nail your bio while another confidently invents one.
Built the system to query many models in parallel and cluster responses, explicitly distinguishing recognition strength per model rather than collapsing to one number. The clustering step is what lets the tool separate confident truth from confident hallucination.
Contrasts SEO's tight feedback loop — readable user agents, Search Console, A/B testable title tags with days-long feedback — against the recognition-in-weights regime, which is dictated by a training cut happening once inside a frontier lab. The old loop was adversarial but legible; the new one is fundamentally asymmetric and offers no comparable visibility or control.
A Show HN post titled *Are You in the Weights?* climbed to 356 points on Hacker News this week. The pitch is simple: enter a name, brand, or domain and the site at intheweights.com fans the query out to a battery of frontier and small language models in parallel, clusters the responses, and returns a recognition score per model. The author, posting alongside a design partner, framed it as a side project built in a few weeks — a curiosity scratch about "what traces we leave in the weights" as traffic migrates off the open web and into chat UIs.
The mechanic is unglamorous and that's the point. It asks each model some variant of "who/what is X?" and inspects the answer for hallucination, confidence, factual density, and consistency across siblings. Clustering responses lets the tool distinguish between a model that confidently nails your bio and one that confidently invents one. The output is a per-model verdict — GPT-class, Claude-class, Llama-class, Mistral-class, smaller open weights — rather than a single aggregate number, which is the right call. Recognition is not uniform across the frontier.
The interesting move isn't the tool itself; it's that the tool is necessary at all. A year ago, asking "does an LLM know about me?" was a parlor trick. Today it's a marketing diagnostic, and the fact that 356 HN users upvoted a weekend project to answer it is a leading indicator of where attention is going.
For twenty-five years, the entire discipline of being-found-on-the-internet was indexed against one substrate: a crawler that visits your URL, parses your HTML, and decides where to rank you. SEO was adversarial but legible. You could read the Googlebot user agent in your logs, watch Search Console, A/B test a title tag, and observe the consequence in days.
Recognition in model weights is the opposite of that loop: it is slow, opaque, and asymmetric. A training cut happens once, somewhere inside a frontier lab, and whatever you'd published by then is what the model knows about you until the next major refresh — which might be six months out, might be never for older snapshots that keep getting deployed in cheap tiers. There is no robots.txt for "please re-train," no Search Console for "why did Claude forget my company." Tools like intheweights.com are doing the only thing currently possible: probing the black box from the outside and reporting back what it saw.
The second-order effect is more interesting than the tool. If you accept that a growing share of high-intent traffic — developers asking "what's the best library for X," buyers asking "who are the top vendors for Y" — now terminates inside a chat window without ever loading a web page, then the relevant question for your product is no longer "do we rank on Google for that query" but "does GPT-5 mention us when asked, and is what it says accurate." Those are different optimization problems with different inputs. Google rewards backlinks, freshness, and on-page signals. Weights reward whatever was statistically over-represented in CommonCrawl, GitHub, arXiv, Stack Overflow, Wikipedia, and the licensed corpora during the months your model's snapshot was being assembled.
That's a profoundly different game. It privileges content that was scraped repeatedly across many domains (so syndication matters more, not less), content that lived on high-authority sources the labs license directly (Wikipedia, major publications, GitHub README files), and content that was structured enough for tokenization without garbling (markdown beats JavaScript-rendered SPAs). It penalizes recency — your three-week-old launch is invisible to a model with an October 2024 cutoff — and it penalizes anything gated behind a login wall, a Cloudflare challenge, or a JS framework that never serves HTML to a scraper.
The HN comment thread on the launch reflected this dawning awareness. Several users posted screenshots of their own results, often surprised in both directions: indie hackers with strong GitHub presence scoring higher than expected on open-weight models, mid-sized B2B companies with polished marketing sites scoring near-zero because their content lived inside React shells the crawlers never executed.
The pragmatic implications for engineering and product teams compound quickly. If your documentation is rendered client-side, you are choosing to be invisible to the next decade of how developers discover tools. This is the same lesson SEO learned in 2015 about JavaScript SPAs, but the stakes are higher because there's no equivalent of Googlebot's headless Chrome rendering pass for training pipelines — the corpora are largely static HTML dumps, code repos, and licensed APIs. Server-side render your docs. Publish a /llms.txt. Maintain a clean sitemap. Make sure your README has prose, not just badges.
Second, audit your own recognition footprint deliberately. Run your company, your top three products, and your founder's name through a tool like intheweights.com — or roll your own with a handful of API calls — and look at the *variance* across models, not the average. A high score on GPT-class models and zero on open weights tells you the OpenAI licensing deals are working for you; the inverse tells you GitHub and CommonCrawl are doing the work. Each pattern implies a different content strategy.
Third, treat "what does the model say when asked about us" as a monitorable metric, not a vibe. The same way you alert on a Lighthouse regression, you should alert when a new Claude release suddenly mis-attributes your product to a competitor. The tooling for this is embryonic but it's coming, and the teams that build the muscle now will look prescient in eighteen months.
The broader trajectory is uncomfortable for anyone who liked the rough meritocracy of search. Training data is a moat that can't be backfilled in a sprint, and the labs are not going to publish their corpora composition. What we get instead are probe tools like this one — a kind of empirical reverse-engineering of which voices made it inside the model and which didn't. Expect a wave of these, expect them to get acquired or commoditized within a year, and expect a new category of consultancy to emerge selling "weight-share optimization" the way the 2005 cohort sold SEO. The names will be cringeworthy. The work will be real.
With more traffic moving off-web and into LLMs, I got curious about what traces we leave "in the weights". My design partner and I built a site in the past few weeks that checks recognition
→ read on Hacker NewsTop 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.