Build or Replaced
Today: Ambient CSS v3 – Blender meets CSS | FBI Probes Service Selling 153M+ Drivers Licenses | My local model setup on an M4 Pro Mac Mini Episode date: 2026-09-02.
Download MP3 →JOSH: It's Wednesday, September 2. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple. Agent costs are falling, local models are getting ridiculous, and identity systems are still held together with duct tape and scanned plastic. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents write the rollback plan before they touch your code. JOSH: [pause] JOSH: First headline. Anthropic launched Claude Fable 5.1 and Claude Mythos 5.1 yesterday. Real release this time? ERIK: Real release. Anthropic's own release notes list September 1, 2026, and the system card is live. Fable 5.1 is generally available. Mythos 5.1 is still restricted to vetted cybersecurity and life-science partners. JOSH: Second. A marketplace is reportedly selling more than 153 million driver's license scans from the U.S. and Canada. What's the short version? ERIK: The short version is ugly. Password leaks are annoying. Driver's license scans are identity infrastructure. Once those are copied, you don't rotate them on Friday afternoon. JOSH: Third. Local AI people are running a 104 gig Qwen model on a 48 gig Mac at about 12 tokens per second. Wait, really? ERIK: Reported by the LocalLLaMA crowd, yeah. It's a community demo, not a lab benchmark, but it's still a signal. Desktop inference is getting weird in the good way. JOSH: [pause] JOSH: Start with Anthropic. Fable 5.1 and Mythos 5.1. Why does this matter beyond another model name? ERIK: Because this release is about agent economics. Not chatbot vibes. Not "write me a poem about BGP." Agent loops. ERIK: One agentic task is not one prompt. It's read the repo, make a plan, edit a file, run tests, fail, inspect logs, edit again, call another tool, ask a review model, write the commit message, and maybe open a PR. ERIK: That's where money goes to die if your routing is lazy. JOSH: Anthropic is saying lower cost for complex agent work. Is that the big piece? ERIK: Yeah. The public reporting says Fable 5.1 keeps the same headline price but cuts cache-read cost hard, from one dollar per million tokens to twenty-five cents per million tokens. That's not a small footnote. ERIK: Cache reads are agent food. If the model can keep chewing through the same repo context cheaper, your whole build system changes. JOSH: How does that show up in a real system? ERIK: PrimeRouter is exactly where this matters. I don't want every request going to the biggest model just because someone got nervous. Priority-tier routing exists because not every task deserves the expensive brain. ERIK: A test failure explanation can use one lane. A production-impacting code change gets another. A security-sensitive review gets the leash and the paperwork. ERIK: If cache reads get cheaper, I can afford more context staying warm. That means fewer dumb mistakes where an agent forgets the shape of the repo halfway through a fix. JOSH: That's the part people miss, right? It's not just cheaper answers. ERIK: Exactly. Cheaper answers are nice. Cheaper memory of the work is the real thing. ERIK: Agent systems don't fail because the model can't write a function. They fail because the model loses context, takes a shortcut, or changes six files when one file was the job. ERIK: Cost pressure creates bad architecture. When loops are expensive, builders cram too much into one call. Giant prompt. Giant instruction stack. Giant diff. Then everyone acts shocked when the model comes back with a confident mess. JOSH: So lower cost means smaller steps? ERIK: That's the move. Small step. Verify. Small step. Verify. Make the agent boring. ERIK: PrimeBus works that way. Events go on the bus. A worker picks up the job. Another worker reviews. A guardrail decides if the action is allowed. That pattern is not flashy, but it beats a magic chatbot with root access. JOSH: What about Mythos being restricted? ERIK: That's the other important signal. Mythos is positioned for cybersecurity and biology research. Anthropic is not handing that to everyone with a credit card and a weekend project. ERIK: That's good. Annoying for builders who want the biggest toy, sure. But capabilities like cyber exploitation and bio workflows need access control, audit logs, and real policy. ERIK: People complain about guardrails until the agent does something expensive. Then suddenly everybody loves change control. JOSH: The naming changed too. Opus, Sonnet, Haiku were music terms. Fable and Mythos are different. ERIK: That tells me Anthropic is separating families by job. Fable feels like the main work model. Mythos feels like the dangerous-knowledge model with a badge scanner. ERIK: Could be branding. Could be product architecture. But you don't break a naming pattern by accident when you're selling to enterprises. JOSH: You sound less interested in the benchmark scores. ERIK: Benchmarks are useful, but they don't run my systems. Repos run my systems. Logs run my systems. Failed tests at 2:00 AM run my systems. ERIK: If Fable 5.1 is better in Claude Code and cheaper on cached context, I'll care. If it writes a better haiku, congrats to the English department. JOSH: That's harsh. ERIK: Accurate. JOSH: [beat] JOSH: What should builders do today because of this release? ERIK: Put a router in front of your models. Stop hardcoding one provider and one model into your tools. You need policy by job type. ERIK: Coding fix? Maybe Claude. Bulk summarization? Maybe a cheaper model. Sensitive repo? Force review. External tool call? Require a plan and a diff. ERIK: The model market is moving too fast to wire your business to one endpoint and call it architecture. JOSH: [pause] JOSH: Let's move to the driver's license story. More than 153 million scans reportedly for sale. Why does that hit different? ERIK: Because it's not just data. It's proof material. ERIK: A password proves you know a secret. A driver's license scan is used to prove you are a person. That is way harder to clean up after. JOSH: You can't reset your face. ERIK: Not without a budget and a very strange weekend. JOSH: Fair. ERIK: The serious part is this. A lot of verification workflows still act like a photo of an ID is magic. Upload the front. Upload the back. Take a selfie. Done. ERIK: That worked better when attackers didn't have huge piles of real scans. If those scans are circulating, the whole workflow needs more skepticism. JOSH: Is this a vendor problem? ERIK: Usually it's a vendor-chain problem. The company asking for your ID might not store it forever. But some identity provider, support tool, fraud vendor, logging system, or S3 bucket might. ERIK: That's where builders get sloppy. They think, "We use a vendor, so the risk moved." No. The risk got a forwarding address. JOSH: What should teams change? ERIK: First, stop storing the raw document unless the law forces you to. Store the verification result. Store the minimum fields. Store the timestamp. Store the vendor reference. Delete the image. ERIK: Second, split permissions. The app should not casually read identity documents. Support should not see full scans by default. Logs should never get document images. That one should not need a podcast episode. JOSH: But it probably does. ERIK: It does, because people still log everything in dev and then copy the same pattern to prod. ERIK: Third, build expiration into the workflow. Identity artifacts should rot on purpose. If you keep them forever, you own the breach forever. JOSH: How would you automate that? ERIK: Event-driven cleanup. Verification completed goes on the bus. Retention policy gets attached. A scheduled worker checks age and legal hold. If nothing blocks deletion, the raw artifact is removed and the audit record stays. ERIK: That's a PrimeBus style workflow. Not complicated. Message in, policy check, action out, log the result. JOSH: Where do AI agents fit in this without making it worse? ERIK: Carefully. The AI should not browse raw IDs because someone wrote a loose prompt. Use AI to classify support cases, detect weird patterns, explain risk, and draft responses. Keep the sensitive artifact behind deterministic access rules. ERIK: Agent can say, "This case needs manual review." It does not need to see every pixel of someone's license to feel involved. JOSH: That sounds like a boring security answer. ERIK: Good security is boring. Exciting security means someone is wearing a headset and saying "confirmed incident" on a bridge call. JOSH: What does this mean for smaller builders? ERIK: Smaller builders need to be more ruthless. Don't copy enterprise KYC patterns just because they look official. If your app doesn't truly need a government ID, don't ask for one. ERIK: Phone verification, payment verification, passkeys, risk scoring, delayed payouts, human review. There are layers before "send me your license and trust my storage bucket." JOSH: And if you already collect IDs? ERIK: Inventory it today. Where are the files? Who can read them? Are they in logs? Are backups encrypted? What's the deletion job? Who gets paged if the job fails? ERIK: If nobody knows, that's the answer. The system is already telling you it was not designed. JOSH: [pause] JOSH: The third story is the fun one. A 104 gig Qwen model on a 48 gig Mac at about 12 tokens per second. What's happening there? ERIK: Community demo, likely using aggressive memory tricks and offloading. The posts mention Qwen3.8-Flash-Next and a custom inference engine called SlotStream. ERIK: The headline is wild because 104 gigs sounds impossible on a 48 gig machine. But memory is not a single bucket anymore. You can map weights, stream parts, quantize, offload, and trade latency for capacity. JOSH: So it runs, but there's an asterisk. ERIK: A huge asterisk wearing a hard hat. ERIK: Tokens per second depends on prompt length, quantization, warm versus cold start, disk speed, memory pressure, runtime, and what else your Mac is doing. A screenshot is not a production benchmark. JOSH: Still, 12 tokens per second sounds usable. ERIK: For tinkering, yes. For local coding help, experiments, offline review, maybe. For a customer-facing agent with a queue backing up, no. ERIK: This is where people confuse "possible" with "deployable." Possible is cool. Deployable has monitoring, retry behavior, capacity math, and a plan for when Spotlight indexing decides to join the meeting. JOSH: Where would you use local models? ERIK: Privacy-sensitive drafts. Cheap classification. Log summarization inside the network. Small code review passes. Anything where latency can be human-speed and the data should stay local. ERIK: I like local models as workers, not kings. Let them handle narrow jobs. Let PrimeRouter choose when local is good enough and when the request needs a hosted model. JOSH: Give me an example. ERIK: ScanBrief can use smaller models to score rough relevance or dedupe obvious repeats before a stronger model writes the final summary. That saves money and keeps the expensive model focused. ERIK: Same with Build or Be Replaced. A local model could cluster story candidates. Then a stronger model helps turn the signal into a script. The human still decides what gets aired, because apparently we still like standards. JOSH: Barely. ERIK: Barely is still above zero. JOSH: How does this compare to running everything in the cloud? ERIK: Cloud wins on reliability and burst capacity. Local wins on control, privacy, and marginal cost once the hardware is sitting there. ERIK: But local inference makes you the platform team. Updates, drivers, heat, memory, weird runtime bugs. Nobody from the cloud provider is coming to save your Mac mini. JOSH: What should builders test before they trust local inference? ERIK: Measure sustained tokens per second, not the best thirty seconds. Test long prompts. Test concurrent jobs. Test restart behavior. Pull the network cable if offline matters. Fill memory with another workload and see if it falls over. ERIK: And log everything. Model name, quantization, context length, runtime, temperature, latency, token counts, failure reason. If you don't log it, you're doing vibes-based infrastructure. JOSH: That's a medical condition. ERIK: Terminal, but common. JOSH: What's the bigger signal here? ERIK: The edge is coming back. We spent years pushing everything to cloud APIs. Now the models are getting good enough that some work comes back to the desk, the lab, the branch office, the factory floor. ERIK: Networking people should pay attention. Local agents near infrastructure will matter. Think NSO dry-run summaries. Config drift explanations. Maintenance-window checks. Ticket enrichment without shipping internal configs to ten vendors. JOSH: That sounds like your world. ERIK: Yeah. Network automation was always about controlled action. AI doesn't change that. It just gives you a more flexible worker inside the same guardrails. ERIK: The mistake is giving the worker the keys before you build the cage. JOSH: [pause] JOSH: Pull these three together. Anthropic lowers agent costs, identity scans leak, local models get stronger. What's the pattern? ERIK: Builders are getting more power at the same time the blast radius is getting bigger. ERIK: Cheaper agent loops mean more automation. Local inference means more places to run models. Identity leaks mean attackers have better raw material. Those are connected. ERIK: The answer is not "stop building." The answer is build systems with receipts. JOSH: Receipts meaning logs? ERIK: Logs, tests, policy decisions, approvals, rollback records, data deletion proof. Show me what the agent did, why it did it, what it touched, and how you know it worked. ERIK: That's the difference between automation and chaos with a nice UI. JOSH: Where does a builder start? ERIK: Pick one workflow. Put it on a queue. Add one agent. Add one reviewer. Add one hard rule the agent cannot override. ERIK: Don't start with "AI runs my company." Start with "AI triages this failure and opens a patch." Then measure it. JOSH: And if it fails? ERIK: Good. Now you found the missing guardrail in the lab instead of in prod. That's the whole point. JOSH: [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com JOSH: [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Before you let an agent edit your repo, make it write three things: intended files, test command, and rollback plan. ERIK: Not a paragraph. A tiny contract. ERIK: Intended files means the agent names what it expects to touch. If the diff changes other files, stop and review. ERIK: Test command means it commits to verification before it starts. No "trust me bro, I inspected it." Run the thing. ERIK: Rollback plan means the agent knows how to undo the change. That can be git revert, feature flag off, config restore, database migration down, whatever fits the system. JOSH: Why before the edit? ERIK: Because after the edit, the model wants to defend its work. Before the edit, it still has clean intent. ERIK: Use this prompt today: "Before making changes, state the exact files you expect to edit, the command you will run to verify, and the rollback plan if verification fails." ERIK: Then enforce it. If the agent touches surprise files, stop the run. That's your tip. Use it. JOSH: [pause] ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com. JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.