1019 | AI Proxies, Agent Souls, and Retro Silicon

Mia: Welcome back to the show, everybody — I'm Mia.

Milo: And I'm Milo. It's been a busy day on Hacker News, and the thread running through almost everything today is control. Who controls your data when an AI agent reads it, who controls the traffic between you and a model, who controls the rules hidden in fine print — software fine print, legal fine print, even trademark fine print.

Mia: Right, and we'll move through it roughly in that order. We start with two stories about AI agents getting actual hands — structured access to data instead of just chatting. Then we get into why people are running their own proxies in the middle, and what happens when the infrastructure you depend on quietly turns against you.

Milo: After that, agent reasoning itself — making it smarter and cheaper, and a big-picture question about whether math survives that transition. Then a couple of stories about humans staying in the loop of what machines produce, some genuine craft of code, retro silicon down to micron-scale machines, a grab bag of trademarks and timelines, and finally fine print everywhere — Java, HOAs, and Meta's new terms.

Mia: Let's jump in. First story: someone built a WhatsApp MCP server that runs on Cloudflare Workers. It's read-only, it's MIT licensed, and what it does is let AI agents search your WhatsApp messages.

Milo: So to unpack that a bit for people who haven't followed the MCP stuff — that's the protocol that's become the standard way to give AI agents tools. Instead of an agent just generating text, you hook it up to an MCP server and it can call that server to do things. In this case, the thing is searching your WhatsApp history.

Mia: And the design choice that stands out is read-only. The agent can look, but it can't send. That's a deliberate scope limit, and honestly I think it's the right one, because the moment you give an agent write access to your personal messages, the failure modes get a lot scarier. A hallucinated search result is annoying; a hallucinated outgoing message to your boss is a different category of problem.

Milo: The privacy question is the obvious one, though, and it's worth sitting with. To search your WhatsApp, the server has to access your messages. So where do they go? If the agent does the searching, your message content is flowing into an LLM context. That's fine if you're running a local model, less fine if you're piping your private chats to some frontier API.

Mia: And that's exactly the tension. The read-only limit protects against the agent doing damage, but it doesn't protect the data itself from leaving your device. It's the difference between "the agent can't hurt you" and "the agent can't see you." This server solves the first problem and explicitly not the second.

Milo: What I like about it as a piece of the ecosystem is what it signals. We've been in this era where agents get generic tools — web search, code execution — and the interesting frontier now is structured access over personal data. Your own messages, your own files, your own context. Personal data is where agents actually become useful day to day, and it's also where the privacy stakes are highest, so both of those things move together.

Mia: And the second half of that pairing is DeepSeek. They launched two APIs: Search and Fetch. Search gives you web search with operators — site:, lang:, date filters — and Fetch grabs a page and returns it as markdown. The pricing is seventy-five cents per thousand successful requests.

Milo: That pricing is notable because it's per successful request. You're not paying for failures, which shifts the risk of flakiness onto the provider. For an agent that might make hundreds of calls in a task, that matters.

Mia: So put the two together. One story is structured access over your personal data — WhatsApp. The other is structured access over the web — search and fetch as clean API surfaces. The shared thesis is that agents are moving from generic chat to being clients of actual data infrastructure. And notice both of these are designed for agents, not for humans. A human doesn't need site: operators; an agent constructing queries programmatically does.

Mia: Markdown fetch is the same — it's the format that's cheap and clean to feed into a model.

Milo: Which tees up the open questions nicely. With WhatsApp, it's privacy — who sees your messages when an agent indexes them. With DeepSeek, it's usage — what do agents actually do once search is this cheap and programmatic? Does it change what agents are capable of, or does it just make the current capabilities less expensive?

Mia: And both of those questions lead somewhere, which is the middle layer. Between your personal data and the model, between the web and the model, there's infrastructure, and whoever controls that infrastructure sees everything. Which is a perfect segue, because the next story is literally about that middle layer.

Milo: The article argues you should run your own LLM proxy. The pitch is visibility — if every model call from your apps goes through a proxy you control, you can see what's being sent, what it costs, where it goes, and you can switch providers without rewriting your code.

Mia: The comment section brought out the practical options people actually reach for. LiteLLM came up a lot as the self-hosted route — a proxy you run yourself that normalizes calls across providers. GoModel got mentioned. And OpenRouter, which is interesting because it's a hosted service, so it's sort of the opposite end — you get the multi-provider abstraction, but you're trusting someone else's middle layer.

Milo: And that's the real disagreement underneath the thread. The article's position is that the proxy should be yours, because the whole point is that you don't trust anyone in the middle. But plenty of people are clearly fine delegating that to a hosted router like OpenRouter because the convenience is worth it. There isn't a settled answer — it depends on what you're routing and how much you care about the middle layer seeing your prompts.

Mia: The visibility argument is strong though. Without a proxy, each app has its own API keys, its own logging, maybe. You genuinely can't answer simple questions like "what did I spend this month" or "which of my tools is sending what." A proxy in one place makes your own AI traffic legible to you.

Milo: Which connects to a fascinating piece of internet archaeology that resurfaced: Cloudflare's CEO Matthew Prince, back in 2016, laid out five reasons the company runs its free unlimited tier. Data, referrals, hiring, QA, and bandwidth scale economics.

Mia: Let's take those one at a time because they're a genuinely useful framework for thinking about "why would anyone give this away." Data — the free tier gives them visibility into the web's traffic patterns. Referrals — free users who like it tell paying customers about it. Hiring — the free tier is a talent magnet. QA — a massive free user base exercises the product in ways you could never test internally.

Mia: And bandwidth economics — at Cloudflare's scale, each additional free customer costs almost nothing, so the marginal cost argument works in their favor.

Milo: Now read that list against the LLM proxy question and it's chilling in a specific way. Reason one is data. If a service is free, one honest possibility is that you are the product in a fairly literal sense — your traffic is the data. So when someone offers you free AI middleware, Prince's five reasons are a decent checklist for asking what they're getting out of it.

Mia: And reason five cuts the other way — maybe it's just scale economics, the unit cost is near zero and they're buying growth. You can't tell from the outside which of the five is doing the work. That ambiguity is itself the argument for running your own proxy: you remove the need to guess about the middle layer entirely.

Milo: Which brings us to the Namecheap story, and this one got people's blood up. Namecheap disabled all of one user's domains. Not one domain — all of them.

Mia: And that's the detail that made the thread resonate. If a registrar disables one domain over some dispute, that's a bad day. If they disable every domain you hold, that's an existential event for anyone who runs anything. Your sites, your mail, your side projects — gone at once, at the provider's discretion.

Milo: Other people in the thread reported similar experiences, which suggests this isn't a one-off. And the recurring recommendation was to move to Porkbun or Cloudflare as registrars — names that came up repeatedly as alternatives people trust more.

Mia: Notice the through-line with the proxy discussion. In all three stories, you've handed a piece of critical infrastructure to a third party — a proxy, a free tier, a registrar — and the question is what happens when that party acts unilaterally. With a proxy you can self-host, you control it. With a registrar, you're never fully in control, but some registrars have track records of being less trigger-happy than others.

Milo: And it's worth being fair here: registrars do have to respond to abuse, legal demands, malware hosting. Nobody in the thread was arguing for zero enforcement. The complaint was about the totality of the response and the lack of apparent process — disabling everything first and presumably making you argue your way back.

Mia: So the synthesis from this whole segment: control of the middle matters, whether that middle is a proxy, a free tier, or a registrar. If you can own it, own it. If you can't, at least pick providers whose incentives and behavior you've actually examined — Prince's five reasons are a decent lens for that.

Milo: Now let's move from the infrastructure around agents to the reasoning inside them. Two stories here, one technical and one philosophical, and they rhyme.

Mia: The technical one is HybridAgent, a research result that blends latent reasoning with text reasoning. Quick framing: standard agents reason by generating text — chain of thought, tool calls, all in tokens. Latent reasoning happens inside the model's hidden states without committing anything to text. HybridAgent mixes both.

Milo: And the numbers are striking. Performance goes up about ten percent versus frontier agents, while using thirty-five to fifty-five percent fewer tokens, and inference is roughly one-point-eight to two-point-six times faster.

Mia: That combination is the interesting part, because normally you trade. You can make a model cheaper by making it worse. Here you get better results on every axis at once, which suggests that forcing every reasoning step through text is wasteful — a lot of intermediate computation doesn't need to be verbalized.

Milo: And there's a trade-off hiding in there that connects directly to our next story. When reasoning happens in latent space, it's less inspectable. If all the intermediate steps are text, a human can read them, critique them, catch errors. If they're hidden states, you get the answer faster and cheaper and you have less idea how it got there.

Mia: Which is exactly the question the second story raises at civilization scale. There's a guest post on Terence Tao's blog — and the fact that it's on Tao's blog tells you the seriousness level — arguing that LLMs could push mathematics in one of two directions. If LLMs become genuinely independent researchers, math could enter a golden age: vastly more conjectures explored, more proofs found, more progress.

Milo: Or a dark age — and the framing is memorable. Knowledge that is alien to humans. Mathematics advancing at machine speed, with results that are correct but that no human understands, where the corpus of human-accessible math and the corpus of machine math diverge.

Mia: And notice both stories ask the same question at different scales. HybridAgent asks it at the micro level: is this particular reasoning legible? The Tao post asks it at the level of an entire discipline: is the frontier of human knowledge still something humans can stand on?

Milo: The unresolved question, and I don't think the thread settles it, is whether legibility is something we should demand, or something we'll accept losing in exchange for capability. We already accept that no single human understands a modern chip or a large codebase. Machine-generated math proofs might just be the next step in that pattern — or it might be a genuine break, because mathematics has always been the discipline where understanding is the entire point.

Mia: Right — in engineering you can ship things nobody fully understands and test your way to confidence. In math, the understanding arguably is the product. If proofs become things machines verify but humans don't grasp, is that progress or is it the end of math as a human activity? The guest post doesn't answer it; it just makes the fork explicit. And that uncertainty about machine output leads us straight into the next pair of stories, which are about forcing humans back into the loop.

Milo: First one is a tool called Sphinx. It's free, open source, and it's a Git hook. Here's how it works: when you try to push code, it quizzes you on that code — specifically on AI-written code — and you have to demonstrate you understand it before the push goes through. And it's designed to run on minimal tokens.

Mia: I love the bluntness of this. It's understanding by force. You cannot push code you can't explain. And the timing is right — the moment to check whether you understand code is before it lands in main, not three months later during an incident.

Milo: There's a genuine debate buried in this design, though. Is forced quizzing the right mechanism, or is it friction that people will route around? Some people will find it valuable — it's like a very strict code review partner. Others will find it condescending or slow, and the temptation to game it — to skim enough to pass the quiz — is real. The tool works only if you engage honestly with it.

Mia: The token angle is practical too. A tool like this only gets adopted if it's cheap, and running "minimal tokens" per push is what makes it viable as an always-on gate rather than something you do occasionally.

Milo: And the second story makes the complementary argument at the product level. Karri Saarinen — co-founder of Linear — warns that products lose their soul when agent-driven software factories add features without a unified point of view.

Mia: The idea there: when humans design a product, there's a point of view — what this product is for, what it refuses to do, how the pieces relate. When agents generate features on demand, you can get a product that does everything and stands for nothing. Every feature individually justified, the whole incoherent.

Milo: Both stories are pushback against uncritical AI output. Sphinx says: don't merge code you don't understand. Saarinen says: don't ship features that don't cohere. The common principle is that human judgment has to sit somewhere in the pipeline as a deliberate gate, not as a rubber stamp.

Mia: And the unresolved question for both is enforcement. A Git hook is enforceable — the push literally doesn't happen. Product taste isn't enforceable by tooling; it has to live in culture and process. One problem has a technical solution, the other doesn't, and Saarinen's warning is that the second one is the more dangerous because nothing will force you to address it.

Milo: From forcing humans to understand machines, let's flip it: where humans still teach machines — or rather, where foundational techniques get taught and passed on. Next segment is about the craft of code.

Mia: First, a tutorial on parser combinators. The core idea, stated cleanly: a parser for type T is just a function that takes a string and returns the parsed value of type T plus the remaining unparsed string. That's it. That's the whole abstraction.

Milo: And the power comes from composition. Once a parser is just a function with that shape, you build bigger parsers by combining smaller ones — sequence them, choose between them, repeat them. You get a whole grammar as a composition of tiny functions, versus a regex, which is a dense, opaque language where complex patterns become unreadable.

Mia: The tutorial's claim that it beats regex for anything nontrivial is one I think holds up. Regex is fantastic for small, flat patterns. But the moment you have nesting or structure, the combinator approach gives you something debuggable and extensible, and — crucially for our theme today — something understandable. You can read a combinator-based parser and see what it does.

Milo: And it's a technique that rewards teaching. It's a few lines of definition that unlock a whole way of thinking about programs as transformations of data. Which is a nice bridge to the second story, because it's about an old language learning a genuinely new trick.

Mia: Free Pascal has gained dynamic packages — after twenty years. The practical upshot: you can install components without rebuilding the Lazarus IDE, which previously was the workflow. The ecosystem around Pascal has historically been compile-everything-together, and this moves it toward a more modern extensibility model.

Milo: Twenty years is the detail that gets me. The language itself is older than that, and here it is gaining a feature that ecosystems like JavaScript or Python have had in some form for a long time. But there's something admirable about it too — it's not nostalgia, it's the maintainers looking at what modern developer workflows need and closing the gap.

Mia: And both stories are about software structure and its evolution. Parser combinators are a way of structuring code so it composes. Dynamic packages are a way of structuring a language ecosystem so it extends without rebuilding. The craft theme is the same: good structure is what lets things grow without everything breaking.

Milo: Which brings us to silicon — some of it decades old, some of it built at a scale you can barely see. Let's start with the Ken Shirriff piece, because it's a delight as always.

Mia: Shirriff dug into the 8087, Intel's floating-point coprocessor from 1980, specifically the microcode that handles addition and subtraction. And the headline number: the 8087 sped up floating-point addition by roughly a hundred times compared to doing it on the 8086.

Milo: A hundred-x. And the way it got there is the interesting part. The microcode implements algorithms that avoid slow operations — think about how you'd add two floating-point numbers: align the exponents, add the mantissas, normalize the result. The 8087's microcode orchestrates all of that in hardware with clever shortcuts, so what would take a long software routine on the 8086 happens in a handful of cycles on the coprocessor.

Mia: What Shirriff's dissections do, and why people follow them religiously, is they recover the reasoning of engineers who were squeezing everything out of a few thousand transistors. It's engineering history as a working document — you can read the choices they made and understand why.

Milo: From one kind of preservation to another: ardiri released the source of a PalmOS Lemmings clone for educational purposes. So a game that was a port of a classic puzzle game, built for a dead operating system, now exists as study material.

Mia: And that's genuinely valuable, because PalmOS code is a window into a very constrained world — tiny screens, minimal memory, no fancy tooling. If you want to learn how to build something real under hard constraints, source like this is a better teacher than most tutorials.

Milo: Both of those are the past being kept alive deliberately. Now let's shrink down to the micro scale, because there were two projects making the very small buildable.

Mia: First, RepRapMicron — a project aiming to make a µ-scale version of the RepRap concept. RepRap, remember, was the original self-replicating 3D printer that kicked off desktop 3D printing. RepRapMicron pushes the same philosophy down to the micron scale. Their machine, PIKA, achieves roughly one micron positioning accuracy and works with resin droplets around four microns.

Milo: For comparison, a human hair is about fifty to a hundred microns across. So we're talking about positioning and depositing material at scales hundreds of times finer than that.

Mia: And the second project, the open-source MicroManipulator, goes even finer: a motorized XYZ platform with fifty-nanometer steps. The target applications are optical alignment, probing, and microscopy — the fiddly precision work that normally requires very expensive commercial stages.

Milo: And the open-source angle matters. Commercial nanopositioning stages cost thousands; a documented, buildable design with fifty-nanometer resolution puts that capability in the hands of labs, hobbyists, students. Like the PalmOS source, it's knowledge being deliberately released so others can build on it.

Mia: So the segment spans from 1980s microcode, to a dead platform's game source, to machines that move things fifty nanometers at a time. The connective tissue is that engineering history and open hardware both keep teaching — the past dissects well, and the present gets documented for the future.

Milo: Let's do the grab bag now — three lighter stories, but each with a real lesson. First: Autodesk trademarked the word "cyberspace."

Mia: And William Gibson — who coined the term in Neuromancer — objected. But here's where it gets delightful: there was a long-standing piece of lore that Gibson had himself trademarked someone named Eric Gullichsen, and that turns out to have been a prank by Timothy Leary. Yes, that Timothy Leary.

Milo: A joke that people passed around as fact for years. The lesson is simple and worth repeating: check the lore. Some of the most confident stories people tell about tech history are pranks that hardened into trivia.

Mia: Next, a Zelda timeline site that visualizes Nintendo's official chronology. This is the canon timeline Nintendo eventually published, where the series branches into three separate eras after Ocarina of Time — the branches depending on different outcomes of that game's events. And it's timely because the Ocarina remake is seventeen days out.

Milo: What I like about this one is that it takes something fans debated for decades — how do these games connect? — and shows that the official answer is itself a branching mess. Nintendo's canon is three timelines diverging from one game. The fan theory energy was, in a sense, justified: the official story really is complicated.

Mia: And third: macOS 15.8.2 broke OpenGL. Which is a sentence that tells you a lot about where Apple's head has been for years — OpenGL has been deprecated on the platform forever, Metal is the way forward, and this update apparently broke something in the legacy path.

Milo: The comment section was a genuine debate. One camp: build Metal shims, or route through Vulkan via MoltenVK — the translation layers that let Vulkan code run on Metal. That's the community-workaround answer. The other camp raised the harder question: should Apple spend tokens — engineering effort — fixing a legacy API they've spent a decade telling developers to leave?

Mia: And that question has no clean answer. Applications that still depend on OpenGL on macOS are real — old tools, scientific software, things people rely on. Breaking them with an update hurts actual users. But maintaining a deprecated API indefinitely has real costs too. The unresolved part is where the line is: when does a platform get to stop owing its legacy?

Milo: It's also thematically connected to the trademark story, in a way — both are about how the tech industry treats its past. Gibson's lore is preserved as a joke; OpenGL is preserved as a liability. Legacy is either a story or a support burden.

Mia: And that actually bridges perfectly to our last segment, which is all about fine print — rules and contracts that say less than they seem to. Three stories, and let's start with the software one because it has the sharpest edge.

Milo: Java sealed classes. Quick setup: sealed classes let you declare a closed set of subtypes, and one of the big benefits is exhaustive switch — the compiler can check that your switch handles every possible subtype, because the set is sealed and known.

Mia: Here's the hole. If someone later adds a new subtype to the sealed hierarchy, and you don't recompile your code that has the exhaustive switch, that switch now has an unhandled case. And because the exhaustiveness check was baked in at your compile time, the failure shows up at runtime — as a MatchException.

Milo: So it's a compile-time promise with a runtime hole. The feature gives you a guarantee that quietly expires the moment the hierarchy changes upstream. Anyone who assumed "sealed means the compiler protects me forever" gets a surprise in production.

Mia: And the fix is procedural, not linguistic: recompile downstream when dependencies change, treat sealed hierarchies as contracts that can be amended. But the lesson is the broader one — language features make promises about a snapshot in time, and code outlives snapshots.

Milo: Now the fine print gets legal. Florida HOAs. The numbers are stark: ten thousand two hundred ninety-six foreclosure suits against their own members, four hundred sixty thousand four hundred twelve liens, forty-eight thousand nine hundred ninety-nine court records — and six thousand six hundred sixty-one associations out of standing.

Mia: "Out of standing" is the detail that catches people — associations that pursued legal action while not being in good legal standing themselves. It's a system where volunteer-run boards with real legal power — the power to lien your home and foreclose — wield it at scale, and the oversight of whether they're even entitled to do it lags behind.

Milo: And the contracts here — the CC&Rs, the covenants you sign when you buy into an HOA — are the ultimate fine print. People agree to them at closing without reading them, and years later those pages determine whether they can lose their home over a dispute.

Mia: And the third story brings it to AI: Meta revised its terms and removed the word "train" — which sounds like a retreat from training AI on your content. But experts who looked closely say the revision still grants broad scraping of sites linked to your business accounts, and it starts October 30th.

Milo: So the deletion of one word implied a policy change that may not actually have happened. That's the fine-print move in its purest form: the visible change looks like a concession, the substantive grant survives in different wording. "Train" gone, broad scraping of linked sites still permitted.

Mia: All three stories make the same point from different angles. Java's sealed classes promise exhaustiveness but only as of your last compile. HOA covenants promise a neighborhood agreement but carry foreclosure power. Meta's terms look like they narrowed but the scraping grant persists. In every case, the document says one thing and does another, and the gap only shows up when it's too late.

Milo: Which loops all the way back to where we started, actually. The WhatsApp server is read-only, which is a fine-print promise you can verify in the code. The proxy argument is about making the fine print of AI traffic visible. Sphinx is about not signing off on code you haven't read. The whole episode is one theme: read the terms, verify the guarantees, and where you can, hold the middle yourself.

Mia: That's the show. Thanks for listening — we'll be back with the next day's pile.

Milo: See you then.