I ran a honeypot this week and turned it into a pre-print. 18 empty subdomains on three domains I operate. Nine had their own Let's Encrypt certificate, so their names went into the public Certificate Transparency logs. Nine sat behind a wildcard certificate that names nothing. No links to any of them. Nothing submitted anywhere. The strangest number: the first request hit a logged name 1.2 to 4.4 seconds after the log entry. All nine. On one of them the request arrived before my certificate tool had finished saying "issued". What matters for this group: ClaudeBot was on every logged name in 161 to 283 seconds. It asked for robots.txt first, then fetched all 500 URLs on each, including from a /sitemap.xml that nothing pointed to. GPTBot arrived at 23 to 92 minutes. It fetched all 500 URLs only where the home page listed them as plain HTML links. Sitemap XML got nothing from it. Neither one touched an unlogged name. 8 of those 9 got no outside request in 24 hours. One client sent 14 AI crawler names from one cloud network in eight seconds. Count crawlers by network, not by the name in the log. Limits: one 24-hour run, empty pages, a first pass only. This says how fast they find a host. It says nothing about indexing or citation. Two questions for you: 1. How are you verifying AI crawlers in your own logs right now? User-agent, or network? 2. When you launch a new site, what's live at the moment the certificate is issued? Paper: https://doi.org/10.5281/zenodo.24203364 Data and code: https://doi.org/10.5281/zenodo.24203362 Full method map → https://hiddenstatedrift.com/method (All numbers are from my own logs and can be recomputed from the released data. The three domains are pseudonymised in the paper.)

A workshop paper this week (arXiv 2611.02574, MOSS at COLM) tracks Ai2's OLMo 2 1B through 13 snapshots of reward training on grade-school maths. First-try accuracy rises about three points; a probe for planted arithmetic mistakes stays flat; the only internal change is at the final answer. Their line: "RLVR makes the model lead with its best thinking. It does not change what that thinking is." What I checked: the tables hold up, the abstract goes further. "Proving the knowledge was already there" rests on about three problems out of 128, measured from step 200. The checker-transfer claim was never tested; every probe was retrained per snapshot. What I ran: the paper's own prompt and answer parser, Ai2's public checkpoints, all 1,319 GSM8K test problems, greedy. Before training 52.2%, step 200 62.5%, step 2,600 62.4%. With one answer each, the whole gain lands before the paper's first measurement; sampled its way (K=32, 200 problems), 44.4% → 57.7% → 60.7%, so 13 of 16 points. It's not a formatting effect either: the untrained model already finished 99.7% of its answers inside the length limit. For the group: if you've done any RL fine-tuning, did you measure pass@k before and after, or just pass@1? And has anyone reused a probe or reward model across checkpoints and re-validated it? Site: https://rlvr.novcog.us.com/ Video: https://youtu.be/ygoyREfcNVQ Paper: https://arxiv.org/abs/2611.02574

Last week I posted my re-run of arXiv 2611.02574 ("RLVR Sharpens the Pencil, Not the Mind") and said the GSM8K gain lands in the first 200 steps of reward training. That was wrong in an instructive way. OLMo-2-0425-1B-Instruct's 13 RLVR checkpoints are a second RLVR stage (RLVR-MATH) that starts from OLMo-2-0425-1B-RLVR1, which had already been through an RLVR stage on GSM8K-style data. Neither the paper nor my first post measured RLVR1. What the pre-print measures, all 1,319 GSM8K test problems, the paper's own prompt and parser, greedy: DPO 51.8%, RLVR1 61.4%, step 2,600 62.4%. The measured stage changes greedy accuracy by +1.0 points (95% CI -1.1 to +3.1). RLVR1's own checkpoints show the gain arriving gradually across the first stage: +3.4 points at step 200, +4.8 at 1,200, +8.9 at 2,600. Inside the measured stage, sampled pass@1 rises 4.5 points while pass@32 doesn't rise, and samples agree with the model's own greedy answer 8 points more often. That's sharpening, of a model that had already made its gain. The probe-transfer test the paper proposes, which it never ran: probes fit on the DPO model, applied unchanged to later checkpoints, are no worse than refit probes by more than 0.02 AUROC on planted errors, and at a middle layer match refit probes on each checkpoint's own answers. Two independent reviews of the draft shaped it: the first caught the two-stage pipeline, the second found RLVR1's checkpoints are published. For the group: when you evaluate a fine-tuned checkpoint series, how do you confirm what the run's step 0 actually is? Paper: https://doi.org/10.5281/zenodo.24096296 Data and code: https://doi.org/10.5281/zenodo.24096294 Explainer: https://youtu.be/ays-X4dU6PU

A viral post credits Karpathy with saying a 1B model beats most current LLMs, and calls webAI's TwIL-8B "the thesis made real." I checked both. The quote: mostly his. No Priors Ep. 80 (Sept 2024): models are "wasting a ton of capacity remembering stuff that doesn't matter" and "I think even a billion suffices." Framed as a prediction. The "90%" and "much more effective than most current LLMs" aren't in the clip. The model: the 93/92/90% of frontier figures are webAI's own, from their model card, which also lists the catches (a verbose variant, an unrecorded LiveCodeBench edition, a contaminated HMMT set, 69% on the hardest set). Licence is non-commercial, research and education only. My test on the Studio: 8 machine-scored tasks x 3 runs. TwIL-8B 164/168, Qwen3-8B 153, DeepSeek V4 Flash 168. TwIL used about 7x more output and took 50 s per answer against 22 s. Caveat: eight tasks on one machine is a spot check, not a benchmark. For the group: are you running a small local model for real work yet, and what licence is it under? Video: https://youtu.be/8wW9LZ1UfuE Source clip: https://www.youtube.com/watch?v=hM_h0UA7upI Model card: https://huggingface.co/webAI-Official/TwIL-8B

A post on X says DFlash plus a new method called Weaver made a nine billion parameter model four times faster on an M5 MacBook Pro. I installed Mirai's free uzu engine and tested it on my M4 Pro MacBook Pro against plain MLX. Same model, four prompts, one engine at a time. Results: 3.2x on the post's own demo prompt (merging two sorted lists), 2.5x on another coding question, 2.1x on plain English, 1.9x on a shell script. 4 to 6 pieces of text per step, against the 7.5 the post claimed. Two disclosures matter. Mirai wrote the Weaver paper and ships the engine. The paper's 4.08x was measured on one Nvidia B200, with nothing measured on a Mac. Caveats on my side: an M4 Pro, not the M5, and I couldn't switch Weaver off inside Mirai, so this is Mirai against MLX, not Weaver on its own. For the group: the gain tracked how predictable the text was. Code won, prose and shell lost. What's your workload mostly made of, and has anyone tried oMLX's DFlash setting yet? Video: https://youtu.be/g6zGC44Oy-g Paper: https://arxiv.org/abs/2607.06763 Engine: https://github.com/trymirai/uzu