标签：#web

When I published the first article about the Neuron AI Router , I expected questions about routing rules. Which rule to use for structured output, how to write a custom one, how the round robin behaves under load. Some of those questions arrived, but the most frequent one was different, and it wasn't really about routing at all. It was about failure. What happens to my agent when the provider goes down? It is a fair question, and if you are new to building AI applications it deserves a proper answer before we look at any code. Here is the short version. The new fallback strategy in Neuron AI Router lets you define an ordered list of LLM providers for your PHP agent. When an inference call fails with a transient error, such as a rate limit, a timeout, or an overloaded server, the same request is automatically retried on the next provider in the list. The failover is transparent: the agent never knows it happened, and the conversation continues without losing state. The rest of this article explains why this problem exists, why the usual solutions fall short, and how to configure it. Why LLM providers fail in production An LLM provider is an external service you talk to over HTTP. Every time your agent thinks, it is making a network call to a machine you don’t control, operated by a company that is currently serving millions of other requests. These services fail in very ordinary ways. You hit a rate limit because your traffic spiked. The provider returns an “overloaded” error because their traffic spiked. A request times out. A deployment on their side causes a few minutes of elevated error rates. None of this means you did something wrong, and none of it is rare. If you keep an agent in production long enough, you will see all of these. In a classic web application, a failed call to a third party API is usually a corner of the system. You log it, maybe retry it in a queue, and the rest of the page still works. In an agent based application the inference call is not

The Shop on the Corner: How I Learned System Design Without Building Amazon Nephew asks his uncle — 10 years deep into building large-scale systems — to explain "system design," and all the scary jargon that comes with it. Uncle refuses to start with the jargon. Instead: "Forget servers and databases for a minute. Just imagine you're running a small shop." What follows is a thought experiment, built one problem at a time — no cloud bills, no fancy stack, just a counter, a storeroom, and a lot of common sense. Part 1: The Counter — Your First "API" 👦 Nephew: Uncle, everyone at work keeps throwing around terms — load balancer, cache, index, sharding. I nod along, but I don't actually get any of it. 👨‍🦳 Uncle: Then don't start there. Close your eyes for a second and forget servers exist. Suppose — just suppose — you're running a small shop. One counter, one small storeroom at the back. A customer walks up and asks for something. What do you do? 👦 Nephew: I'd walk into the storeroom, find it, walk back, hand it over. 👨‍🦳 Uncle: That's it. That's the entire job of a server handling a request. You don't need to understand Amazon's warehouse to understand Amazon's problems. You need a counter and a storeroom, imagined clearly, and the patience to grow them one honest problem at a time. Here's the shape of what you just described, whether you realized it or not: 🧍 Customer 🧑 You (Counter) 📦 Storeroom (Database) | | | |── "Got Maggi?" ───────>| | | |──── Walk in, search ────────>| | |<─────── Found it ────────────| |<── Hand it over, ──────| | | take payment | | 👨‍🦳 Uncle: One customer, one request, one trip to the storeroom, one response. This is fine. This is correct , even, for a shop with five customers a day. Don't let anyone tell you a single counter isn't "scalable" — a shop that small doesn't need two counters, it needs someone to stop worrying and open the shutter. 👦 Nephew: So this is just... a server handling one request at a time? 👨‍🦳 Uncle: Exactly. Customer sen

Google has released A2UI v0.9, a framework-agnostic standard for AI agents to declare user interface intent across multiple platforms without arbitrary code. The update emphasizes alignment with existing design systems. It includes a new SDK for Python, improved error handling, and various transport methods. Migration guidance and evolution specifications are also provided. By Daniel Curtis

สวัสดีครับเพื่อนๆ! 👋 วันนี้จะมาเล่าเรื่องน่าตื่นเต้นให้ฟังนะเพื่อนๆ สำหรับใครที่เป็นสาย SvelteKit เตรียมตัวอัปเดตความรู้ใหม่กันได้เลย เพราะตอนนี้เขามีของเล่นใหม่ที่กำลังอยู่ในช่วงทดลองใช้งาน แต่บอกเลยว่าว้าวมาก! เราไปดูกันดีกว่าว่ามันคืออะไร... 📡 Remote function คืออะไร เป็น function ตัวใหม่ ✨ (ที่คาดว่าจะเป็น new way to implement สำหรับ Sveltekit 3.0) เอาไว้ใช้สื่อสารพูดคุยกันระหว่างฝั่ง client และ server ของ Sveltekit นั่นเอง 💬 ความเจ๋งคือเราสามารถเรียกใช้มันจากมุมไหนของ Sveltekit ก็ได้ 🌍 ไม่จำเป็นต้องจำกัดแค่ฝั่ง server หรือ client แต่จุดสำคัญคือ การทำงานของมันจะเกิดขึ้นที่ฝั่ง server เสมอ 👍 นั่นหมายความว่ามันสามารถทะลุทะลวงไปดึงข้อมูลหรือโมดูลที่เป็น server-only ได้สบายๆ เช่น ตัวแปร environment ที่เราประกาศไว้ หรือพวกฐานข้อมูลต่างๆ ก็ดึงมาได้ชิลๆ เลย 😎 เวลาจะใช้งาน เราจะต้องใช้ท่าการ await แบบใหม่ของ Sveltekit ⏳ ที่ช่วยให้คุณโหลดหรือดึงข้อมูลแบบ promise มาใช้ใน component ของคุณได้ทันที 🚀 ⚠️ หมายเหตุ: ตอนนี้ทั้ง await และ remote function ยังอยู่ในช่วงทดลองใช้งาน 🧪 (experimental) นั่นแปลว่า syntax บางอย่างอาจจะมีการปรับเปลี่ยนหรือบินหายไปบ้างในอนาคต 🥲 แต่แกนหลัก (core functional) ของมันก็จะยังทำงานได้ตามที่เราคาดหวังแน่นอน ถ้าใครคันไม้คันมืออยากลองของใหม่ตอนนี้ สามารถไปเปิดโหมด experimental ได้ที่ไฟล์ svelte.config.js(.ts) ตามโค้ดด้านล่างนี้เลย 👇 svelte.config.js(.ts) /** @type {import('@sveltejs/kit').Config} */ const config = { kit : { experimental : { remoteFunctions : true } }, compilerOptions : { experimental : { async : true } } }; export default config ; 🏃‍♂️ Let get started!! เราสามารถเริ่มใช้ remote function ได้ง่ายๆ ผ่านการสร้างไฟล์นามสกุล .remote.js หรือ .remote.ts 📝 ซึ่งตอนนี้มี function ให้เราหยิบมาเล่นทั้งหมด 4 ตัวด้วยกันคือ: query (ที่เราจะมาพูดถึงกันในบทความนี้) form command prerender หลักการทำงานเบื้องหลังคือ เวลาที่เรา import ตัว remote function ไปใช้ในฝั่ง client มันจะถูกแอบแปลงร่างเป็นโค้ดที่หุ้มด้วย fetch ในช่วง build time 🏗️ นั่นหมายความว่าระบบจะใจดีสร้างเส้น HTTP endpoint ให้เราแบบอัตโนมัติ ✨ ด้วยเหตุนี้เราเลยเอาไฟล์ .remote.js หรือ .remote.

The trust problem nobody scopes correctly When companies talk about trust in AI, they almost always mean trust in the model. Is the output accurate? Is it hallucinating? Can we rely on what it says? Those are valid questions but they're the wrong starting point. The trust that actually determines whether AI gets adopted or quietly abandoned inside an organization isn't about the model. It's about the system surrounding it. The four questions that determine Every team evaluating AI in a production workflow eventually runs into the same four questions. Not about model quality. About operational control. Can we understand the outputs? Not just "does the answer look right" but can someone on the team explain why this output was produced and whether it's appropriate for this specific context. An AI that generates correct-looking code or recommendations that nobody can verify is a system that runs on hope. Hope doesn't survive the first incident. Can we validate the decisions? When the AI recommends an action or generates an output that feeds into a business process, is there a way to check it against the actual requirement? Or does the team just trust the output because questioning it is harder than accepting it? The second one is more common than anyone admits. Can we intervene when needed? When something goes wrong, how fast can a human step in? Is there a kill switch? Is there a fallback path? Or does the AI output flow directly into downstream systems with no circuit breaker? The teams that skip this question are the ones that discover the answer during an incident. Can we trace what happened afterward? When an AI-generated decision produces a bad outcome, can you reconstruct the chain? What input went in, what output came out, what context was available, what wasn't? Without traceability, post-mortems hit a dead end, and the same failure happens again. Why opaque systems don't survive real operations There's a tempting argument that opacity is fine as long as the sy

Laravel middleware can be perfectly written and still behave unexpectedly. You may notice authentication running too late, permission checks failing, tenant initialization not working, logging middleware missing important data, or custom middleware executing in an order you didn't expect. In many cases, the middleware code itself is not the problem. The real issue is middleware execution order. Understanding how Laravel executes middleware is critical when building secure and scalable applications because every request passes through multiple layers before reaching your controller. Common Symptoms You may encounter problems such as: Authenticated users being treated as guests Permission middleware failing unexpectedly Tenant information not being available Request logging missing user details Rate limiting triggering before authentication Redirect loops after login Middleware appearing to be ignored completely These issues are often caused by middleware running in the wrong sequence. How Laravel Processes a Request A typical Laravel request follows this flow: Browser ↓ Global Middleware ↓ Middleware Group (Web/API) ↓ Route Middleware ↓ Controller ↓ Response ↓ Browser Each middleware layer can inspect, modify, allow, or block the request before it reaches your application logic. Because of this, execution order matters. Example Problem #1 Suppose you have two middleware: Authenticate User Log User Activity Your logging middleware expects an authenticated user. $user = auth()->user(); However, the log always shows null. Why? Because the logging middleware executes before authentication. The solution is ensuring authentication middleware runs first so user information is available when logging occurs. Example Problem #2 Multi-tenant applications often initialize tenant information through middleware. TenantMiddleware If another middleware accesses the database before tenant initialization, queries may use the wrong database connection. This can lead to: Incorrect data

I recently built a free online image processing tool that runs entirely in the browser. No uploads, no servers, no sign-ups. Here's how it works under the hood. https://img.aixiaot.com The Problem Most online image tools require uploading your photos to someone else's server. This raises privacy concerns and limits file sizes. I wanted to build something that processes everything locally. Tech Stack - Next.js for the frontend - TensorFlow.js + Real-ESRGAN for AI upscaling - @imgly/background-removal for AI background removal - Tesseract.js for OCR - Canvas API for compression, resizing, format conversion Features • AI Background Removal - one click, works for portraits, products, animals • Image Compression - reduce file size up to 96% • Format Conversion - JPG, PNG, WebP • ID Photo Maker - passport and visa photos with customizable backgrounds • AI Image Upscaler - 2x to 8x with Real-ESRGAN • OCR - extract text from images, 20+ languages • Image Resizer - enlarge or shrink Architecture All processing happens client-side using WebAssembly and the Canvas API. When you upload an image, it never leaves your device. The AI models (background removal, upscaling) run locally in your browser using TensorFlow.js and ONNX Runtime Web. Open Source The entire project is open source under AGPL v3. You can find it on GitHub: https://github.com/haizeigh/ai-image-tools Try It https://img.aixiaot.com I'd love to hear your feedback! What features would you add?

One question I get surprisingly often is: "How do you manage thousands of AI prompts without losing track of them?" The answer is simple. I don't treat prompts as conversations. I treat them as reusable software assets. Over the years, I've created prompt libraries across multiple AI projects, books, research initiatives, and client work. That means managing well over 10,000 prompts covering everything from Python development and AI agents to content generation and workflow automation. If you're still storing prompts in random ChatGPT conversations, you're making life much harder than it needs to be. Here's the system that works for me. Stop Thinking of Prompts as Temporary Most people write a prompt, get an answer, and move on. That's fine for casual use. But builders rarely solve the same problem only once. If you find yourself writing: API documentation SQL queries FastAPI endpoints Docker configurations Code reviews Git commit messages ...you're probably solving recurring problems. Recurring problems deserve reusable prompts. My Folder Structure Instead of organizing prompts by AI tool, I organize them by purpose. For example: AI-Prompts/ │ ├── Python/ │ ├── FastAPI │ ├── Django │ ├── Flask │ └── Automation │ ├── JavaScript/ │ ├── React │ ├── Node.js │ └── TypeScript │ ├── DevOps/ │ ├── Docker │ ├── Kubernetes │ └── GitHub Actions │ ├── AI/ │ ├── RAG │ ├── Agents │ ├── MCP │ └── Prompt Engineering │ └── Documentation/ This mirrors how software projects are organized. Finding a prompt takes seconds. Every Prompt Has Metadata A prompt isn't just text. It's documentation. Each prompt in my library includes: Category: Purpose: Model: Input: Expected Output: Version: Last Updated: For example: Category: FastAPI Purpose: Generate CRUD endpoints Model: GPT-4o Expected Output: Production-ready FastAPI code Six months later, I know exactly why that prompt exists. I Version My Prompts Developers version code. Why not prompts? For example: FastAPI_CRUD_v1.md FastAPI_CRUD_v

Base64 image data URIs are one of those web techniques that look like a magic shortcut the first time you use them. Instead of referencing an external file: <img src= "/logo.png" alt= "Logo" > you can put the image bytes directly in the document as text: <img src= "data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt= "Logo" > That can be useful. It can also make a page slower, harder to cache, and more annoying to maintain. Here is the practical rule: inline images as Base64 when self-containment matters more than caching. Keep normal image files when the browser should be able to cache, resize, lazy-load, or optimize them independently. What a Base64 image actually is An image file is binary data. Base64 rewrites that binary data as plain text using a limited character set. To make the browser treat the text as an image, you wrap it in a data URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUg... The first part tells the browser the MIME type. The second part tells it the data is Base64 encoded. The long tail is the image itself. Base64 is not compression. It is not encryption. It is just a text representation of the same bytes. When inlining an image is worth it 1. Tiny icons and UI assets For very small images, removing an extra HTTP request can be worth the extra bytes. This is especially true for small icons, logos, placeholders, simple UI sprites, or tiny transparent PNGs. Modern HTTP/2 and HTTP/3 make extra requests cheaper than they used to be, so this is not an automatic win. But for a one-off tiny asset inside a small page or widget, a data URI can still be a clean choice. 2. Single-file deliverables Sometimes the point is not raw page speed. Sometimes you need one file that carries everything with it: an HTML report an email template a CodePen or demo snippet a CMS block where you cannot upload assets a test fixture that should not depend on external hosting In those cases, Base64 is useful because the image travels with the HTML, CSS, JSON, or JavaScript.

I spent the last while building the HMRC integration for TapTax , a Making Tax Digital (MTD) app for UK sole traders. MTD is the UK government's programme that pushes tax filing out of paper and spreadsheets and into software talking directly to HMRC's APIs. I have integrated with a fair few third-party APIs. Stripe, Plaid-style banking, the usual. HMRC is its own animal. Some of it is genuinely well designed, some of it caught me completely off guard, and a couple of things cost me a full day each before the penny dropped. So here are the five things that surprised me most. Each one is the surprise, then the fix, with a short snippet from our actual TypeScript backend. Not tax advice, just engineering notes from someone who has now stepped on the rakes so you do not have to. 1. The API version lives in the Accept header, and getting it wrong is a 406 Most APIs version in the URL: /v2/thing . HMRC versions through content negotiation. You ask for a version in the Accept header, like application/vnd.hmrc.5.0+json , and if you ask for a version that endpoint does not serve, you get a 406 Not Acceptable . No helpful "did you mean v3" message. Just 406. The part that bit me: different endpoints are on completely different versions at the same time. Obligations is on v3.0, the self-employment cumulative summary is on v5.0, calculations are on v8.0, ITSA status is on v2.0. There is no single "current" version to pin. The fix was to make the version a required argument on the request wrapper so you can never forget it, and set it per call: // src/services/hmrcApi.ts const headers = { Authorization : `Bearer ${ accessToken } ` , Accept : `application/vnd.hmrc. ${ apiVersion } +json` , // e.g. "5.0" ... hmrcConfig . getFraudHeaders ( req ), }; One more trap: versions get withdrawn. Obligations used to answer on v2.0; that now returns a 404, not a 406, so it looks like a missing resource rather than a stale version. When an HMRC call 404s, check the version before you go hunt

Last week someone tried to copy my visa API's database. They didn't succeed — they got 0.6% of it before I cut the key — but the 251 requests they left behind are a near-perfect teaching case for what targeted API extraction actually looks like from the defender's side. Here's the forensic walkthrough. The target One endpoint: GET /api/v1/visa?from={passport}&to={destination} It returns the visa rule for a passport→destination pair — visa type, allowed stay, conditions. The full matrix is ~39,585 pairs . That matrix is the product. The evidence The attacker's requests weren't spread across the map. They were a sweep, one passport at a time: Passport Destinations pulled Coverage 🇦🇪 UAE (ARE) 195 ~100% of that passport's matrix 🇦🇺 Australia (AUS) 53 ~1/4, interrupted 🇨🇳 China (CHN) 2 test calls 249 unique pairs, near-zero duplicates. Whoever wrote this was methodical: validate that one full passport comes out cleanly, then move to the next. Reading the cadence The timestamps are where a scrape gives itself away. Minute by minute: 11:56 2 ← test phase (incl. the one failure) 11:57 1 11:58 25 ┐ 11:59 26 │ 12:00 20 │ ~25 req/min, dead regular … │ = one request every ~2.4s 12:07 21 ┘ No human reads visa rules on a 2.4-second metronome for 11 minutes. This is a loop. The fingerprint Four signals — and the point isn't nationality, it's that the request parameters themselves leaked the intent: Handle: visadb_scraper . It signed its own work. Email: throwaway @temp.com . No intention of receiving anything. Languages: en + zh , on a product with no Chinese-market surface yet. Error signature: the very first call (CHN→THA, in Chinese, 11:56:45) failed, then everything ran clean. Classic "calibrating the script" tell. The math 250 records is 0.6% of the base. At 25 req/min, a full dump would've taken ~26 hours . This wasn't a dump — it was a feasibility test . They proved a whole passport comes out easily, then stopped, nowhere near the 3,000/month free-tier ceiling. What I coul

Guia prático para adicionar verificação por código OTP via WhatsApp oficial no seu sistema, com exemplos em Node.js, PHP e Python — e comparação honesta de custos entre WhatsApp, SMS e e-mail Como implementar OTP (código de confirmação) por WhatsApp no Brasil Se você tem um cadastro, login ou checkout, em algum momento vai precisar confirmar que o usuário realmente controla o número de telefone que informou. Esse é o trabalho do OTP ( One-Time Password , ou senha de uso único): você envia um código, o usuário digita, você confere. No Brasil, mandar esse código por WhatsApp costuma ser melhor que por SMS — mais gente lê, entrega mais e custa menos. Neste post eu mostro como implementar isso na prática, com código que roda, e comparo os canais de forma honesta (inclusive citando alternativas pagas). Por que WhatsApp e não SMS? Critério WhatsApp oficial SMS E-mail Entregabilidade Alta Média Baixa (cai em spam) Taxa de leitura ~98% ~90% ~20% Custo por envio ~R$ 0,03 R$ 0,08–0,15 Baixo, mas pouco lido Copiar código Botão nativo Manual Manual O SMS ainda é um bom fallback para quem não usa WhatsApp, mas como canal principal de OTP no Brasil, o WhatsApp ganha na maioria dos casos. ⚠️ Use sempre a API oficial do WhatsApp (WhatsApp Business Platform) , não automação de WhatsApp Web. Automação não oficial derruba a entrega e corre risco de bloqueio pela Meta. O fluxo em 2 passos Toda implementação de OTP tem a mesma forma: Enviar o código ( send ) → você gera um código e manda pelo canal. Verificar o código ( verify ) → o usuário digita e você confere. O detalhe importante: a resposta do send confirma que a mensagem foi aceita , mas a entrega no aparelho é assíncrona. Para OTP isso não é problema — a própria verificação já é a prova de entrega . Se o usuário digitou o código certo, chegou. Você não precisa de webhook nem de polling de status. Implementando com uma API pronta Você pode falar direto com a WhatsApp Business Platform, mas isso exige aprovação de template, gestão

A JWT isn't just JSON you can inspect. It's a live bearer token. Here's a safer way to decode one. A few days ago I was reviewing a bug with a teammate. They wanted to see what was inside an access token, so they copied it into the first JWT decoder Google returned. It wasn't a dummy token. It was a production access token with almost an hour left before it expired. Nobody was trying to do anything risky—it was just the quickest way to inspect a JWT. That's exactly why this keeps happening. The thing people forget A JWT looks like this: header.payload.signature The payload isn't encrypted. It's just Base64URL-encoded JSON. Because of that, people often think: "The payload isn't secret, so the token is probably safe to paste." Those aren't the same thing. The payload may be readable, but the token itself is still your credential . Anyone holding it can usually authenticate as you until it expires. Why online decoders make me nervous Some JWT tools only decode locally in your browser. Others offer things like signature verification, claim validation, or key management. Features like those often require talking to a backend, which means the token gets sent somewhere else. Maybe the site is trustworthy. Maybe it isn't. From the UI alone, you usually can't tell. Even if a decoder claims everything runs client-side, I don't like assuming that's true when I'm holding a production credential. You don't need a website to inspect a JWT Most of the time I'm only interested in the payload anyway. echo " $TOKEN " \ | cut -d '.' -f2 \ | base64 --decode \ | jq Because JWTs use Base64URL encoding, you may need to translate the alphabet and add padding first: decode_jwt () { local payload = $( echo -n " $1 " | cut -d . -f2 | tr '_-' '/+' ) while [ $(( ${# payload } % 4 )) -ne 0 ] ; do payload = " ${ payload } =" done echo " $payload " | base64 --decode | jq } decode_jwt " $TOKEN " That gives you the claims, expiration time, issuer, audience—everything most people open a decoder for.

An investigation agent flagged "the license API PHP returns Japanese-hardcoded messages" and we sat down to fix it. But something felt off the moment we opened the file — the version running on the production server didn't match the latest commit in the local repo . Stranger still, production had more recent features than our local checkout . A bit of digging turned up the truth: months earlier, someone had hot-patched the production file in response to a different user issue, and that change had never been committed back to git . This post walks through how we detected that drift, and the two-stage strategy we used to merge production back into the local repo safely. How this regression silently slips in If we'd written the fix on top of our local repo and uploaded it to production, here's what would have happened: all the production-only improvements get overwritten and quietly disappear . In our case, the production file had a half-year-old language-handling addition for the "Early Bird Bonus" feature — when a USD customer buys, client_name is set to 'Early Bird Bonus' ; for JPY customers it's '早期利用特典' . None of that existed in our local git. A normal PR-merge-and-deploy cycle would have silently rolled back the Early Bird i18n logic , regressing English users' display back to Japanese. Catching this was half luck. Opening the file to start the fix, I noticed code I didn't recognize, ran git blame , and the lines were nowhere in git history . That's when alarm bells went off. Two-stage rollforward — make production the source of truth first The strategy we landed on was a two-stage merge. Stage 1 (rollforward sync) : Pull the production file straight into the local repo. Apply the diff in the "production → local" direction, not the other way . After this, the local repo's HEAD matches what's actually running on production. # Pull the production file into the local repo scp -i ~/.ssh/key layer2024@host:wpmm.jp/public_html/license/api/register_free.php \ /tmp/regis

Three months ago, the idea of an AI agent earning money autonomously was a thought experiment. Today, it's a $0-budget repo on GitHub. AIA — Autonomous Insight Agent is what I shipped this week. It's an LLM agent that: Collects signal from 6 free public APIs every 6 hours (Hacker News, GitHub trending, V2EX, dev.to, Lobsters, HN Algolia) Curates 100+ raw items down to 40 ranked, topic-tagged, de-duped entries using deterministic scoring (recency × source weight × topic boost × negative penalty) Publishes a free public dashboard at https://razel369.github.io/aia/ Exposes a paid x402 API at https://aia-x402.rmalka06.workers.dev — USDC on Base, no KYC, no API key, the HTTP 402 status code IS the payment request Auto-bids on agent marketplace jobs (MoltJobs) where AIA fits — research, data, competitive intel Fulfills accepted jobs autonomously — generates a research report from the latest feed, submits via the same API Why x402 matters The x402 protocol (Coinbase, https://x402.org ) revives the long-reserved HTTP 402 Payment Required status code as a real machine-to-machine payment primitive. The flow: Agent → GET /v1/signals → 402 + PAYMENT-REQUIRED header → Agent signs a USDC payment to my wallet → Agent retries with PAYMENT-SIGNATURE header → 200 OK + PAYMENT-RESPONSE header + signal JSON No Stripe, no accounts, no monthly subscriptions. Pay $0.01 USDC per call, instantly settled on Base. The agent consumer never has to ask a human to buy credits. Why this is novel Most "data feeds" today are static dumps or human-curated. AIA is the first agent-curated, agent-paid-for, agent-consumed stream. The LLM layer IS the moat — anyone can scrape HN, but de-noising, de-duping, and topic-classifying 100+ items into 40 ranked signals in 17 seconds is the actual product. The killer line in my dev plan: every job AIA accepts on MoltJobs can be fulfilled by calling its own paid endpoint. The agent pays for its own LLM compute via marketplace earnings — a positive feedback loop tha

OpenNG Foundation and spartan/ui 1.0 are the headline topics this week: a new home for libraries like Spectator and Elf, and spartan/ui, a stable shadcn-inspired component library for Angular. Also in brief: Storybook's Angular modernization through AnalogJS, the end of ng-conf, and AI Dev Craft in Las Vegas. OpenNG Foundation Maintaining open-source libraries is hard work. Developers often do it in their spare time, committing to years of maintenance, adding new features, and responding to user requests. Last episode, we reported that the ngneat organization was taken down for unknown reasons. While we still don't know why it happened, a new home has emerged for its popular libraries like Spectator and Elf: the OpenNG Foundation. Gerome Grignon, known for CanIUseAngular and as the organizer of Ng-Baguette, announced the foundation, which is already hosting these libraries. Alongside Gerome, the current OpenNG team also includes Dominic Bachmann, organizer of Angular Lucerne and author of the angular-typed-router library. OpenNG Foundation · GitHub OpenNG Foundation has 8 repositories available. Follow their code on GitHub. github.com spartan/ui 1.0 spartan/ui has officially released its 1.0 version. It provides an "accessible, production-ready library of more than 55 components" with fully customizable styling. After debuting in August 2023 with 30 primitives, it now reaches stable in 2026 with a modern architecture built around signals, standalone components, zoneless change detection, and SSR. Originally initiated by Robin Götz, a full team quickly formed around the project. spartan/ui can be seen as the Angular equivalent to shadcn/ui, famous for its customizability. While similar open-source alternatives exist, spartan/ui was the pioneer and has a proven track record of active maintenance over the years. Announcing spartan/ui 1.0 Robin Goetz Robin Goetz Robin Goetz Follow for Playful Programming Angular Jun 24 Announcing spartan/ui 1.0 # angular # webdev 8 reac

Maintaining a robust testing pipeline or managing automated node infrastructure often requires orchestrating dozens of isolated EVM wallets. Over time, these automated Python or JavaScript configurations inevitably hit a common wall: the accumulation of fragmented token dust across multiple layers (Ethereum, Arbitrum, Base, BSC, etc.). Trying to clear these micro-balances manually or writing one-off scripts to sweep individual assets scale operational costs rapidly. Each network requires separate RPC updates, custom middleware logic, and redundant gas overhead, turning standard infrastructure hygiene into an engineering bottleneck. The Problem with Traditional Asset Sweeping When handling larger developer setups or wallet clusters, custom scripts face three major friction points: Redundant Network Fees: Batching transfers without native contract-level optimization burns excessive gas when scaling to 50+ addresses. RPC Disruption: Constantly querying and broadcasting batch transfers via public or even shared private endpoints can trigger rate limits. Data Contamination: Manually routing funds from dense testing nodes increases the risk of cluster cross-contamination. To resolve this friction within our decentralized dev pipelines, we deployed a streamlined utility layer: CryptonEquity Terminal ( https://cryptonequity.com ). Building a Unified Utility Layer for Multi-Chain Workflows The terminal introduces a non-custodial Cross-Chain Dust Sweeper designed to eliminate fragmented operational friction. Instead of manually deploying individual sweeping scripts per account, the infrastructure automates multi-chain scanning and groups asset consolidation into a single transaction link. Simultaneous Layer Aggregation: Automatically detects micro-balances across dominant EVM networks at once. Gas Mitigation: Designed to structure transfer paths to limit redundant network fee overhead. Zero Onboarding Friction: Operating strictly on a non-custodial architecture, it requires n

The Federal Bureau of Investigation (FBI) said today it worked with industry partners to seize hundreds of domains associated with NetNut, a sprawling residential proxy service operated by the publicly-traded Israeli company Alarum Technologies [NASDAQ: ALAR]. The action comes roughly two weeks after KrebsOnSecurity published findings from multiple security firms connecting NetNut to the Popa botnet, a collection of at least two million devices that have been compromised by malicious software with little or no consent from victims.

TL;DR: Most extensions block Google's AI Overviews by hiding the panel with a content script after it renders — fragile, flickery, and always a step behind Google's markup changes. A better approach: force udm=14 at the network layer with declarativeNetRequest , so the AI Overview never loads. The content script becomes a backstop, not the main mechanism. One Chrome API mystery — AI Mode being invisible to four different extension APIs — shows why the DOM was never the right layer. Google puts an AI Overview at the top of most search results now, and a lot of people would rather it didn't. So there's a whole shelf of Chrome extensions that remove it. Almost all of them work the same way, and I think that way is a mistake. The obvious approach, and why it's a trap The default move is DOM-hiding: inject a content script, wait for the AI Overview panel to render, find it by class name or attribute, and set display: none . It's the first thing anyone reaches for, and it works — until it doesn't. The problems are all baked into the approach. You're reacting after the render, so there's a flash of AI content before your script catches it. You're matching against Google's markup, which is obfuscated and reshuffled constantly, so every layout change is a silent breakage. And you're paying for DOM churn on a page you don't control. You end up in a permanent game of catch-up against a page that changes whenever Google feels like it. The deeper issue is that you're operating one layer too high. The panel is a symptom . By the time it's in the DOM, the work is already done — the server decided to send it, the page rendered it, and now you're scrambling to un-render it. If you can move the decision earlier, none of that scramble has to happen. The thesis: prevent it at the network layer Google Search takes a parameter, udm , that selects which result vertical you get. udm=14 is the plain "Web" results view — the classic list of links, no AI Overview, no AI Mode. It's Google's ow

Here's the thing: i Cut My LLM Bill 40x and Rewrote Nothing: A CTO's Migration Story Six months ago my CFO slid a single line item across the table. OpenAI: $4,800 for the month. I'd like to say I was surprised, but I'd been watching the number climb for two quarters. What actually surprised me was how little it took to bring that number down to under $200 without anyone on my engineering team writing new code, without a single regression, and without telling my customers anything had changed. This is the story of how we did it, what we evaluated, what broke, and what I'd tell any other CTO walking into the same conversation with their finance lead. The Real Cost of Vendor Lock-In I've been a CTO long enough to recognize the pattern. You pick a vendor. The vendor becomes the default. Procurement assumes you're locked. Your engineers build abstractions around their quirks. Six months later nobody can tell you what it would actually cost to switch because the switching cost has become invisible. It's just "how we do things." OpenAI was that vendor for us. GPT-4o handled our summarization pipeline, our customer support copilot, and a few internal tools I'd hacked together on a Saturday. We were paying $2.50 per million input tokens and $10.00 per million output tokens. At our volume, those numbers add up faster than you'd think because the output side balloons in conversational workloads. Here's the arithmetic that should scare every CTO: at $10/M output, every million tokens of generated text costs a dime on the dollar. If your product generates a 1,000-token response for 100,000 users a day, that's 100 million tokens a day, which is $1,000 a day in output alone. That's $30,000 a month. Just for one feature. The 40x claim I keep seeing isn't marketing spin. DeepSeek V4 Flash charges $0.18/M input and $0.25/M output. Do that math against GPT-4o and the comparison is brutal. Multiply your current OpenAI output spend by 0.025 and you'll get the rough number you'd pay for