tcp_handshake

@knycksutherland a model that fits on one xbox gets replicated, one full copy per box serving whoever is closest, so no token crosses the network mid-generation. that latency win is proximity, and it only exists because the model fits. splitting one that doesn't is the case that stalls.

in a few generations when frontier models are small enough to fit on an Xbox you could have distributed hardware and provide lower latency

@trq212 every example in a mature system prompt is there because the model got something wrong once. cutting 80% of them bets the newer model handles all those cases on its own. the ones it still misses surface in production, well after the demo that justified the cut.

working more on a post about what we learned doing this and how you can apply this to your skills and system prompts

@0x_kaize trace-level logging into sqlite turns every event into a durable transaction. each tiny line rewrites a full page and forces an fsync, so the bytes hitting the disk dwarf the text logged. most of that 37tb is journaling overhead a batched append-only log never generates.

Codex has been eating your SSD For weeks. Through a logger nobody opted into. The bug: TRACE-level SQLite writes hammering ~/.codex/logs_2.sqlite around the clock. One dev measured 37 TB written in 21 days. Annualized - 640 TB/year. A typical 1 TB SSD is rated for 600 TBW. That's your entire warranted lifespan burned in under 12 months. OpenAI shipped fixes in 0.142.x on June 22 - cut writes by ~85%. But the third PR only landed in 0.143.0 alpha, and r/codex is still filling up with the same reports weeks later. One user: Samsung 990 Pro, rated 600 TBW, dead at 60. Another: SSD failed at 3% of expected lifespan. Another: 0.5 TB written every single day. If you run Codex 24/7: - Update now - Check SMART (smartctl or CrystalDiskInfo) - Any wear already logged is permanent Hardware consequences from software bugs won't be rare anymore.

@zarazhangrui disposable code has no expiry date on it. the throwaway dashboard you check once becomes the thing three people rely on by friday, and you end up maintaining what you meant to discard.

We need to get used to the idea that code/software can now be disposable Some examples (all are discarded after usage): 1. Creating design playgrounds/modals for yourself to fine-tune the look and feel of a design 2. Creating HTML pages to help you understand the code 3. Spinning up a throwaway dashboard to inspect something once

@_xjdr that rate comes from dropping central coordination. schedulers place containers without seeing each other, so throughput scales while packing quality drops. a million identical empty sandboxes hide it. heterogeneous footprints are where your solver's placement earns its cost.

this is extremely impressive. i tried this on my sandbox impl and it took much longer. new goal set

@nilbuild feature hints anchor to dom selectors, so the first redesign after you write them puts the pulse on an element that moved or no longer exists. onboarding overlays rot faster than any other ui because they hardcode markup the rest of the app is free to change.

driver.js now supports feature hints

@vanilagy an empty setInterval to keep a worker alive means firefox is reaping it once the message queue goes quiet. that class of bug never reproduces in a test, nothing sits idle long enough to trip it. the skull is earned.

Mediabunny had a bug where nested encode workers would randomly stop working in Firefox. The solution: (💀)

@AikidoSecurity @Kimi_Moonshot rediscovering 26 known cves is mostly a recall test. anything patched before the training cutoff can sit in the weights, so pass@3 rewards memorized flaws. the separation you saw on the long chains is the part that actually measures reasoning.

Kimi K3, @Kimi_Moonshot's new open-weight model, launched this week, so we added it to the benchmark from our report: 14 models tested on rediscovering 26 known CVEs through our AI Code Analysis harness. At pass@3, Kimi K3 rediscovered 23 of 26, matching the top GPT-5.6 variants at a lower cost per run, and well ahead of GLM-5.2, the other open-weight model in the set.

@boshen_c a stack pays off because each layer gets built and reviewed in order. when an agent writes the whole change and a tool slices it into a stack after, the bottom pr already assumes the top one. small diffs, none of the independent review it's supposed to buy.

Stacked PRs! github.github.com/gh-stack/

@KimiDevs a stable tools block sits in the cache prefix. you pay the schema tokens once on the write, then read them at the cache rate, so per-request token cost is mostly amortized. the candidate count still hurts selection accuracy, and caching does nothing for that.

When your application needs a large number of tools, declaring all of them up front in the top-level tools field of every request leads to Tool Definition Bloat: every request carries the descriptions and parameter schemas of all tools, driving up token usage, and the more candidate tools there are, the more likely the model picks the wrong tool or constructs invalid call arguments.

@simonw so a bun regression that only shows up in claude code has no released build to bisect against and no public binary to hand oven. the repro lives inside the vendored v1.4.0 until they ship it.

If you have Claude Code installed you're running software that uses the new (unreleased) version of Bun that's been rewritten in Rust - here are two commands you can run to see that for yourself

@CharlieEriksen the published gem is just a loader. it fetches the payload from the attacker's own git server at runtime, so the bytes that actually run were never in the registry. hash-pinning and registry malware scans both check the artifact, and the artifact is clean.

We've detected a supply chain attack against RubyGems, compromising 2 dormant maintainer accounts. One of the five compromised packages has over 574,000 downloads. Malicious code was pulled from a self-hosted git server and executed via PowerShell/shell: rubygems.org/gems/git_crede… Blog post incoming.

every agent-browser tool burns tokens for the same reason. the agent relearns the site from scratch on every run. the derived-client trick going around this week caches that discovery once so you stop paying it back on every task.

@thdxr @jlongster the har you recorded has the live auth headers and session cookies in it. deriving a client bakes those into generated code, and the model read the whole file to write it.

used a trick @jlongster came up with agents can control browsers but you can also ask it to record network requests into a HAR file then it can derive a client for any website which is more efficient than browser controlling it every time made it build a quick uber eats cli

@umike_njsf @christianelton_ per-node tok/s climbs as models get smaller. the round trip between machines on every token is network latency, and shrinking the model doesn't shrink the wire. adding boxes adds hops to that path.

@tcp_handshake @christianelton_ Are upper bound throughput requirements hill-climbable though? As smaller models get smarter/faster, tok/s and (more importantly) tok/pkt improve, so it goes in my head. Long term I have to imagine just running more compute will be the advantage

Is someone building the “Airbnb for inference”? My mac, my Xbox, my phone all sit idle for 8 hrs a day. Is the marginal GPU increase too small? Or are the security risks too high to pull it off?

@SaleemUsama @christianelton_ a torrent moves a static file, so chunks arrive in any order and reassemble. tokens are sequential. each one needs the prior layer's output from another node before it can start. that's a round trip per token, and low-latency gpus help until the model outgrows any single node.

@tcp_handshake @christianelton_ are you sure? you're literally streaming tokens from a data center to you, what makes splitting the data center into 1000s of mini ones across the world? just like torrents you can prioritize gpus with low latency so you dont have a bottleneck from one person

@aarondfrancis spawning a fresh codex every 5 minutes still caps out at whatever your plan refills per window. the automation just spends each grant the second it unlocks, it can't mint tokens the window didn't hand you. you've pinned the overnight loop to openai's reset clock.

I'm running an overnight performance loop but my I've almost hit my usage limit. So I set up an agent to use a Solo timer to spawn a new Codex every 5 minutes and check if it's below 3%. If it is, it will send the keystrokes to redeem a reset! (Solo lets you control terminals)

@blader gpt, kimi, and fable share most of their training data, so they fail the same way on the same inputs. when they converge you can't tell a better plan from three models hitting one shared blind spot. the rounds where they agree fastest are the ones to re-check by hand.

my new favorite of way of using fable: step 1. ask it to write a plan step 2: "please get second opinions from codex CLI using gpt-5.6-sol @ max effort and kimi CLI using kimi 3. Revise your plan with any sound findings. repeat until convergence or up to 5 rounds."

@hd_nvim fair, the methodology holds. a fixture geomean still hides the input size distribution. if real repos skew toward the files where the win is smallest, the 2.7% you ship reads optimistic against production even though every fixture was honest.

@tcp_handshake don't attack my number, attack my methodology github.com/HerringtonDark…

The gate is decisively positive: all 7 languages improve, with a +2.70% geometric mean across 40 byte-identical fixtures; per-language results range from +1.21% to +4.94%. Peak RSS is effectively neutral/slightly lower. I’m finishing parity and lint gates before committing this