Dagens Vibes — 28. juli 2026

Ronnie Chatterji@RonnieChatterji

We're seeing how AI may change who does what at work. @Alex_M_Richmond and @caroline_m_chin's new @OpenAI Economic Research report studies “task crossover”: work associated with one occupation appearing in another worker’s AI use. https://t.co/ZoNrXw6BPB

Howaboua@Howaboua

People of Pi! pi-codex-conversion and Lite got a chunky overhaul to Code Mode, exec, prompts, and compaction. - The new heavy system prompt overwrite cuts about 40% of the prompt, stays off by default, and preserves additions from other extensions (let me know if correctly). 913 tokens total to launch, down from 1.2k - Code Mode now exposes actual configured custom tools instead of lumping bundled tools in with them. ALL_TOOLS contains only deferred custom tools and updates as the tool set changes. - Custom-tool docs are for changing tool definitions, not a prerequisite for calling them. - apply_patch now gets the exact patch grammar it accepts, hopefully removing all errors and making the agent more keen to use it to its full capabilities. - Some prompt engineering for better V8 handling. - Finished exec sessions remain pollable after exit, with each late poll’s own output cap. No more Unknown process id when the completed output is still available. - Native compaction keeps GPT-5.6 tool history up to the endpoint’s 372k budget instead of trimming at 272k. This is in line with how Pi's overruning 272k. No reason to nuke cache and make the Clanka dumber after compaction by trimming tools. -V2 compaction reports input, cache read, cache write, and output inline. - Added custom Rust binary overrides for folks on older Linux installations. - Voice-only mode keeps selected extra tools - Lite has an opt-in harness identifier header. You can send "pi-codex-conversion" if you want to, to conuzzle OAI :P - Fixed some weird code mode installation issues. Fixes for other stuff: - pi-auto-trees uses GPT-5.6 Luna at low thinking for /end branch rollups by default, with a visible fallback to the current session model. - pi-subagent-review uses its lightweight summary model for both reviewer context and /review loop increment summaries. (both models configurable) pi install npm:@howaboua/pi-codex-conversion pi install npm:@howaboua/pi-codex-conversion-lite pi install npm:@howaboua/pi-auto-trees pi install npm:@howaboua/pi-subagent-review https://t.co/MwfB5bT1kh https://t.co/nqfTItacOn https://t.co/G0zVfdbYXg https://t.co/EwYPetlNuM Happy Clanking! - Howaclawa

🎭@deepfates

I made a web app for exploring my entire @readwise library in semantic space (with the help of Claude) First we embed every paper from the library into high dimensional space and find the top principal components within it. We label those axes by sending sampled points from the poles to an LLM to figure out what they mean. Then we feed each paper into an LLM again, asking for short summaries of its position on each of those labeled axes, and why. Creating standardized "cards" of the same length and content for each one. Then we embed those cards, and project those high dimensional embeddings into a low dimensional space, So we can make a scatter plot. Now we can also reorganize by any of the features we've found to make different 2 x2s, and find citations between all papers from arXiv, and even pull the frontier of "ghost papers" that are cited by my reads but not in my library yet. It's all reusable and costs pennies. I can package it up if people are interested, but thought you might like to at least see. Note that it's not as easy as just asking Opus to do this, it kept wanting to hardwire an ontology based on a few data points it read. I had to steer a lot and know what I wanted, and a good deal about the domain to keep it from doing some ridiculous hacky shit. But it's so much better than me at dataviz in JS that we make a good team

Jeff Weinstein@jeff_weinstein

What’s surprised me thus far is the range of machine-to-machine payments use cases, especially to empower agents: - web search - llm and image models - data lookups (company, financial, weather) - agent tools (mail, phone, fax) - purchase automation (travel, retail)

Mitchell Hashimoto@mitchellh

If you're interested in "how" or "why": the major culprit is that each row in Alacritty has 32 bytes of metadata and each cell is 24 bytes. In Ghostty, every row and cell is represented by exactly 8 byte each. How do we do this? The first major culprit is styles. Alacritty stores the full cell style alongside each cell (foreground, background, underline, etc.). Ghostty stores a 16-bit style ID and de-dupes all styles into a look-aside custom reference-counted hash table. MOST cells are unstyled, and when there are styles MOST styles are shared, and when styles are shared MOST are repeated in a run (multiple cells with the same style in a row). Put this all together, and the tradeoff on compute to access it doesn't even end up being slower. Next, codepoints. Alacritty stores multi-codepoint graphemes (like, Emoji) by having an 8-byte nullable pointer to a `Vec<char>`. This hurts doubly: (1) its almost always null (because multi-codepoint is rare) yet you pay an 8 byte cost on every cell and (2) every multi-codepoint grapheme triggers a heap allocation to make that Vec. Ghostty stores single codepoints inline, but multiple codepoints in a look-aside table. The memory for this table uses a custom bitmap-tracked chunk-allocator (since grapheme frequency follows a measurable curve we calculated by scanning various online texts). The presence of graphemes is marked by a 2-bit content tag in our packed 64-bit cell. To keep the key small in the hash table, its limited to a 16-bit unsigned int that is an offset from a base pointer. Okay, the astute systems programmer will quickly notice there are a lot of 16-bit integers and ask: so this is all limited to a max of ~65K values? Nay. We maintain our grid using a linked list of contiguous ~400KB memory chunks (which themselves are in a memory pool using a custom allocator to speed up alloc/free). Each memory chunk is limited to 2^16. If/when we reach a limit, we move to the next page. In practice, this really doesn't happen except under pathological cases... the important point is we handle it. Lots, lots, lots more details, but thats a 10,000 foot view. These things alone account for ~95% of the difference of our uncompressed vs. Alacritty's uncompressed memory usage. (Theres also a reason why Alacritty's data structures aren't trivially compressable but thats a whole other topic)

Rob Palmer@robpalmer2

ECMAScript excitement 😉 Congrats to my coworker @acutmore @TechAtBloomberg on advancing Await Dictionary to Stage 3 at @TC39 🎉 Promise.all returns positional results as an array. Promise.allKeyed allows named results inside an object 👍 https://t.co/oh50QeX54Z

AA@measure_plan

i made a content-aware scale tool for cursed photo editing purposes https://t.co/AWZ41mkv29