标签：#tor

Our multi-site maintenance tool fires wp plugin list --format=json against the sites it manages. One day, against a specific shared host (Xserver in Japan), this call started failing — and the failure mode was unusually subtle. Both the SSH connection test and the WP-CLI path test ( wp --version ) came back green. Users saw "all diagnostics pass, but the actual operation fails," a frustrating asymmetry. Tracing it back, the root cause was PHP Deprecated warnings emitted by older WP-CLI (2.x) under PHP 8.2+ leaking into the JSON output. This post walks through the three-layer defense we used to structurally absorb the noise without losing real failures. What was happening — Deprecated warnings on stdout The raw output on a problem host looked like this: PHP Deprecated: Creation of dynamic property WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated in phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/... [ {"name":"akismet","status":"active","update":"none", ...}, ... ] Since PHP 8.2, assigning to a dynamic property on a class without #[\AllowDynamicProperties] emits a Deprecated warning. Xserver's /usr/bin/wp (an older WP-CLI 2.x) leans on dynamic properties internally, so running it on PHP 8.2+ produces a steady stream of those warnings. Note: PHP 8.2's dynamic-property deprecation is a healthy direction for the language. But during the transition, you get many libraries that "warn but still work" — WP-CLI was one of them. The actual problem is the host's php.ini : depending on display_errors , those warnings end up on stdout instead of stderr . Calling wp plugin list --format=json returns stdout containing both the warnings and the JSON, and json_decode() fails on the mixed input. Why diagnostics stayed green but operations failed The frustrating asymmetry came from how each test was checking the output: SSH connection test : runs echo ok — passes as long as ok appears somewhere in stdout, extra lines are fine WP-CLI path test : runs wp --version — passes as lon

If you build apps for jewelers, fintech dashboards, or e-commerce price automation, you eventually need one thing: reliable, low-latency gold and currency prices . Scraping fragile sources breaks constantly. A dedicated price API solves this. In this post I'll show how to consume real-time gold (gram, quarter, coin) and FX rates over both REST and WebSocket (Socket.IO) using the Hasfiyat Gold & Currency API . Why a price API instead of scraping? Stability — a documented contract instead of HTML that changes without notice. Low latency — prices are pushed as the market moves, not on a slow cron. Multiple sources with failover — if one provider drops, the feed keeps flowing. 1. Polling with REST The simplest integration: request the prices you need with your API key. curl -X GET \ 'https://api.hasfiyat.com/api/prices?symbols=HAS,GRAM,CEYREK' \ -H 'Authorization: Bearer YOUR_API_KEY' \ -H 'Accept: application/json' // Node.js const res = await fetch ( " https://api.hasfiyat.com/api/prices?symbols=HAS,GRAM,CEYREK " , { headers : { Authorization : " Bearer YOUR_API_KEY " } } ); const data = await res . json (); console . log ( data ); REST is ideal for periodic reporting, server-side jobs, and updating e-commerce product prices. 2. Live updates with Socket.IO For price screens, signage, and mobile apps where every tick matters, keep a connection open and let the server push changes: import { io } from " socket.io-client " ; const socket = io ( " https://api.hasfiyat.com " , { auth : { token : " YOUR_API_KEY " } }); socket . on ( " gold_prices " , ( data ) => { // { symbol: "HAS", type: "Has Altın", buy: 2450.85, sell: 2455.10, timestamp: "14:32:01.045" } console . log ( data ); }); No polling, no hammering the server — each market move arrives instantly. 3. A minimal live ticker in the browser <div id= "gold" ></div> <script src= "https://cdn.socket.io/4.7.5/socket.io.min.js" ></script> <script> const socket = io ( " https://api.hasfiyat.com " , { auth : { token : " YOUR

Understanding the 550 SPF Check Failed Error The "550 SPF Check Failed" error indicates that a receiving mail server rejected an incoming email. This rejection occurs because the sender's domain failed its Sender Policy Framework (SPF) validation. SPF is an email authentication protocol defined in RFC 7208 . SPF helps prevent email spoofing. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. Receiving mail servers perform an SPF check by querying the sender's DNS for an SPF TXT record. If the sending server's IP address is not listed in the domain's SPF record, the SPF check fails. The receiving server then rejects the email based on its configured policy, often resulting in a 550 error. This error protects recipients from unauthorized emails and enhances email security. Initial Diagnosis: Identifying the Root Cause Diagnosing an SPF failure requires examining the bounce message and the domain's DNS records. The bounce message often provides specific details about the SPF failure. Look for phrases like "SPF validation failed," "unauthorized sender," or "IP address not permitted." Common reasons for a 550 SPF Check Failed error include: Missing SPF Record: No SPF TXT record exists for the sending domain. Incorrect SPF Syntax: The SPF record contains errors, making it unreadable or invalid. Incomplete SPF Record: The SPF record does not list all legitimate sending IP addresses or hostnames. DNS Lookup Limit Exceeded: The SPF record requires more than 10 DNS lookups, violating RFC 7208. DMARC Policy Enforcement: A DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy ( RFC 7489 ) with p=reject or p=quarantine is in place, enforcing strict SPF failure handling. To begin diagnosis, use our SPF checker to verify your domain's SPF record and its validity. This tool quickly identifies syntax errors and lookup issues. Step-by-Step Troubleshooting and Resolution Resolving SPF failures involves

This is my first post here, so I'm going to use it as an introduction. I'm Usman, a software + data engineer who primarily works with data pipelines, backend systems. Not a huge fan of frontend development though. Although I do what I can, projects honestly feel incomplete without them, because at the end of the day you do have to showcase a working end to end system when you build something. I'm here after dozens of incomplete personal projects, and projects that never even got past the design phase, you know the drill. Procrastination and imposter syndrome kept stopping me from taking the next step, but I'm here now, gotta keep myself in check fr. I was scrolling through LinkedIn the past few days, and oh my god, the amount of AI-related brain rot there. Every single post written by AI, telling you how to use AI and how not to use AI. I mean I get it, yeah, the paradigm is shifting and AI is essential to development, but where are your personal anecdotes, stuff you solved, stuff you learned, the challenges you faced, how you overcame them. You know what maybe it's my fault, it's my algorithm after all. Anyway, here I am, looking to interact with like-minded engineers and learn from them. I'm also going to post regularly about my progress and what I am building, even though I have quite a bit of experience, and have built and contributed to large-scale production systems and pipelines, I'm going to start with something small, so I can stay consistent and keep myself in check. Software engineering fascinates me a lot, and there are so many domains that I wish to explore and have explored like game development, data engineering, web/app development. My significant other is graduating in a few days, and I'm thinking of making a small game for her, alongside which I'll be working on a small sales lead enrichment pipeline. Hoping to showcase my work and document it publicly, and hoping to get to know and learn from you all! Also, I'd love to know your thoughts on the am

Introduction to DMARC and the p=quarantine Policy DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489 , is an email authentication protocol. It builds upon SPF and DKIM to provide domain owners with the ability to protect their domain from unauthorized use. DMARC enables senders to specify how receiving mail servers should handle unauthenticated emails originating from their domain. It also provides a mechanism for receiving servers to report back to the domain owner about authentication results. DMARC policies dictate the action receiving mail servers should take when an email fails DMARC authentication. The three primary policies are: p=none : Monitor mode. Receiving servers take no action on failed messages but send reports. This is the initial deployment phase. p=quarantine : Receiving servers should treat failed messages as suspicious. They are typically placed in the recipient's spam folder or flagged for further review. p=reject : Receiving servers should outright reject messages that fail DMARC authentication. This is the strongest enforcement policy. Implementing p=quarantine is a critical step towards full domain protection. It allows domain owners to mitigate spoofing and phishing attempts without immediately blocking legitimate, but misconfigured, email streams. This policy provides a balance between security enforcement and minimizing potential deliverability disruptions. Prerequisites for DMARC p=quarantine Implementation Before deploying a p=quarantine policy, proper configuration of SPF and DKIM is mandatory. DMARC relies on these underlying authentication mechanisms and their alignment with the sending domain. SPF (Sender Policy Framework) SPF, specified in RFC 7208 , allows domain owners to publish a list of authorized sending IP addresses in their DNS. Receiving mail servers check the SPF record to verify if an incoming email originated from an authorized server. An SPF record is a TXT record at the root of

Over the past week, a new fanworks movement has kicked off, with the aim to root out authors using generative AI. But the detection methods being implemented are questionable, and any fanfic writer could be caught in the crossfire. Broad distaste around the use of Claude, ChatGPT, and other AI tools has long been a […]

How to Compress Images in the Browser with Canvas API Every image you upload to a "free" online compressor is sent to a server — often without you knowing what happens to it afterward. For a tool that processes your private photos, that's a terrible design. Here's how to build (or use) an image compressor that runs entirely in the browser using the HTML5 Canvas API. No uploads, no server costs, and unlimited file sizes. The Core Technique: Canvas toBlob() The key API is HTMLCanvasElement.toBlob() : js const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); const img = new Image(); img.onload = () => { canvas.width = img.naturalWidth; canvas.height = img.naturalHeight; ctx.drawImage(img, 0, 0); canvas.toBlob((blob) => { const url = URL.createObjectURL(blob); }, 'image/jpeg', 0.8); }; img.src = 'your-image.jpg'; The second parameter is the MIME type (image/jpeg, image/png, image/webp, image/avif). The third is quality (0–1). Step-Down Resizing for Large Images If you're compressing a 6000×4000 px photo, drawing it at full resolution onto a canvas can eat 70+ MB of memory. Step-down resizing halves the dimensions repeatedly: function stepDownEncode(img, maxDim, quality) { let w = img.naturalWidth; let h = img.naturalHeight; let src = img; while (w > maxDim * 2 || h > maxDim * 2) { w = Math.floor(w / 2); h = Math.floor(h / 2); const temp = document.createElement('canvas'); temp.width = w; temp.height = h; temp.getContext('2d').drawImage(src, 0, 0, w, h); src = temp; } const canvas = document.createElement('canvas'); canvas.width = w; canvas.height = h; canvas.getContext('2d').drawImage(src, 0, 0, w, h); return new Promise((resolve) => { canvas.toBlob((blob) => resolve(blob), 'image/jpeg', quality); }); } This prevents memory crashes and actually produces better quality (step-down preserves more detail than a single jump). Comparing Real-World Results Format Avg Original Avg Compressed Avg Savings JPEG → JPEG (Q80) 3.2 MB 0.8 MB 75% PNG → We

In the field guide I covered what an AGENTS.md is and what belongs in it. This is the hands-on follow-up: we'll build a complete AGENTS.md for a real project, one section at a time, then point an AI coding agent at it and watch the difference it makes. By the end you'll have a working file — and you'll have seen it pay off. New to AGENTS.md? It's a single Markdown file at the root of your repo that tells AI coding agents how to work in it — build steps, tests, conventions, guardrails. The "why" behind each section is in the field guide . The project we'll use We'll write the AGENTS.md for a small but real service: a URL shortener API in Python — FastAPI, SQLite, pytest. A couple of endpoints, a thin data layer, a test suite. Follow along with this, or swap in your own repo — the steps are identical. Its shape: linkshort/ app/ main.py # FastAPI routes db.py # SQLite access models.py # Pydantic models migrations/ # generated SQL — not hand-edited tests/ requirements.txt Step 0 — Start with an empty file At the repo root: touch AGENTS.md That's the whole step. We'll fill it in one section at a time, building toward a file an agent can read in thirty seconds. Step 1 — Orientation: one line Tell the agent what it's looking at. Add: # AGENTS.md A URL shortener API in Python — FastAPI, SQLite, pytest. One sentence sets the agent's priors: it knows the language, framework, and storage before it reads a single line of code. Step 2 — Setup and run The agent can't help if it can't start the project. Add the real, copy-pasteable commands: ## Setup python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt ## Run uvicorn app.main:app --reload # http://localhost:8000 Use the commands that actually work in your repo — no placeholders. Step 3 — Tests: the agent's feedback loop This is the most important section, because tests are how the agent checks its own work. Add: ## Test — all must pass before a change is done pytest ruff check . mypy app Now the agent

How we integrated real-time phrase translation feedback into our AI-powered book translation workflow, and what we learned about latency, context, and prompt engineering. When we launched LectuLibre, our AI-powered book translation platform, users loved the quality of full-chapter translations. But they kept asking for something else: while reading a partially translated book, they'd stumble on an untranslated phrase or an awkward auto-translation and want to quickly get a better version without leaving the page. So we built 即时翻译求助 (Instant Translation Help)—a feature that lets readers highlight any phrase and get a context-aware, human-quality translation within seconds, along with a brief explanation of tricky parts. Here's how we built it, the technical challenges we faced, and the lessons we learned about stitching LLMs into a real-time reading experience. Problem: Real-time, Context-Aware Translation Inside a Book Most web apps offer generic translation via API calls—send a sentence to Google Translate, get a result. But that doesn't work for literary texts. A phrase like "She let the cat out of the bag" needs to be translated idiomatically, and the appropriate rendering depends heavily on the surrounding paragraphs (is the tone formal? sarcastic? part of a metaphor chain?). Our existing translation pipeline processes entire chapters in bulk with carefully crafted prompts, but for instant help, we needed sub-second latency while preserving that same depth of context. Our Approach: Server‑Sent Events and a Smart Prompt Buffer We chose Server-Sent Events (SSE) over WebSockets because the communication is one-directional (server pushes translation tokens) and SSE is simpler to implement with FastAPI. The client (a React app) sends a POST request with: The phrase to translate The book ID and the exact location (chapter/paragraph index) The target language Our backend retrieves the surrounding text from PostgreSQL (we store the original book in chunks), feeds a care

Over the past week, the AI hardware news I've been tracking adds up to more than $610 billion in capital deployed globally — in just seven days. Not valuations. Not market cap. Actual capital expenditure commitments. Korea $550B, Japan $6B, Qualcomm's new accelerator, Kawasaki Heavy Industries' $1B AI infrastructure bond — this round of moves has already surpassed the wildest half-year of the 2000 dot-com bubble in scale. But this time the money isn't flowing into web pages. It's flowing into chips, memory, and power. Watching all of this over the past few days, I've been thinking: for investors and for builders like us making products on top of AI, what does this gamble actually mean? The Real Story Behind AI Training Bottlenecks: From GPU Scarcity → Memory Scarcity → Power Scarcity Honestly, everyone watches AI through the lens of models, but the real bottleneck was never the models — it's been the hardware. From 2023 to 2025, the bottleneck shifted from GPU scarcity to memory scarcity, and is now pushing toward power scarcity. When GPUs were tight, everyone scrambled for H100s and NVIDIA raked it in — but the part that actually throttled the H100 wasn't the GPU core, it was the HBM high-bandwidth memory. On the B200, the HBM3E stacked on top has its capacity locked up entirely by NVIDIA at SK Hynix, while Samsung is chasing hard but its yields can't keep up. That's why South Korea just committed $518B to build 4 memory fabs plus $52B for the central regions, totaling $550B ( TechCrunch ). This isn't just about filling upstream capacity — the key is that Samsung + SK Hynix are trying to flip themselves from being NVIDIA's downstream suppliers into becoming the dominant players in AI hardware. Why did downstream hardware investment kick off so late? Because for the past two years people were still watching and waiting to see if "this AI hype cycle would cool down again." By 2026, GPT-6, Claude 4, and Gemini 3 are all live, inference costs have come down, user numbe

If you've ever wanted an AI that doesn't just chat but actually does things — queries databases, calls APIs, makes decisions, and learns from results — you're in the right place. In this tutorial, I'll show you how to build production-ready AI agents using Solon 4.0's ReActAgent . By the end, you'll have built an agent that can reason through complex problems, use external tools, and adapt its behavior based on real-world feedback. What Makes ReActAgent Different? Traditional LLMs are great at generating text, but they hit a wall when they need to interact with the real world — checking a database, fetching live data, or performing calculations. ReActAgent (Reason + Act) breaks through that wall. It implements a cognitive loop: Thought → Action → Observation → (repeat or finish) The agent thinks about what to do next, acts by calling a tool, observes the result, and decides whether to continue or deliver the final answer. This isn't just theory. Solon's ReActAgent has been used in production for automated customer support, intelligent data analysis, and multi-step workflow automation. 1. Adding the Dependency First, add the solon-ai-agent module to your project: <dependency> <groupId> org.noear </groupId> <artifactId> solon-ai-agent </artifactId> </dependency> Note : If you're using Solon's parent POM, the version is managed automatically. Otherwise, use the latest Solon version. 2. Building a ChatModel (The Agent's Brain) Every agent needs a "brain" — a ChatModel that powers reasoning. Let's build one using the fluent API: import org.noear.solon.ai.chat.ChatModel ; ChatModel chatModel = ChatModel . of ( "https://api.moark.com/v1/chat/completions" ) . apiKey ( "your-api-key-here" ) . model ( "Qwen3-32B" ) . build (); You can also configure it via YAML and inject it: solon.ai.chat : demo : apiUrl : " http://127.0.0.1:11434/api/chat" provider : " ollama" model : " llama3.2" @Inject ( "${solon.ai.chat.demo}" ) ChatConfig chatConfig ; ChatModel chatModel = ChatModel . o

📖 Article original : GitHub Gist Un guide technique par Mohamed ben mallessa Le problème Recevoir un dossier de 500 fichiers HEIC à convertir en WebP pour un site web est une situation courante pour tout développeur. Les solutions traditionnelles ont leurs limites : ImageMagick nécessite des codecs spécifiques, les convertisseurs en ligne sont limités en taille, et le traitement manuel est exclu à cette échelle. La solution Photopea (Photoshop gratuit dans le navigateur) supporte nativement tous les formats d'image courants. En l'utilisant comme moteur de conversion piloté par script, on obtient un pipeline batch rapide et fiable. Formats supportés Entrée Sorties possibles HEIC / HEIF JPG, PNG, WebP JPEG WebP, PNG, PSD PNG JPG, WebP WebP PNG, JPG PSD PNG, JPG, WebP SVG PNG, JPG TIFF PNG, JPG, WebP Pipeline Dossier source (500 HEIC) → Photopea → Dossier sortie (500 WebP) Le script préserve la structure des sous-dossiers, applique le redimensionnement et la qualité configurés, et livre les fichiers organisés. Paramètres typiques --format webp # Format de sortie --quality 80 # Qualité (1-100) --resize 1920 # Redimensionnement (côté long) --output ./web/ # Dossier de destination Avantages Un seul outil pour tous les formats d'entrée Aucun codec à installer (Photopea gère tout nativement) Gratuit et sans abonnement Local — les fichiers ne quittent pas votre machine Structure préservée — l'arborescence est conservée Mohamed ben mallessa — Full-stack developer & solutions B2B 🔗 GitHub · LinkedIn opensource #webp #python #tutorial 💻 Vous avez un projet technique ? Développement full-stack, automatisation IA, solutions B2B sur mesure. 🔗 GitHub 💼 LinkedIn 🎨 Behance Article initialement publié sur GitHub Gist

If you've ever tried integrating a large language model (LLM) into a Java application, you've probably written a lot of boilerplate: HTTP clients, JSON parsing, streaming handling, session management. Solon 4.0's ChatModel abstracts all of that away with a clean, builder-oriented API. In this guide, I'll walk through building real, working AI features using ChatModel — from a simple chat call to a streaming chatbot with conversation memory. 1. What Is ChatModel? ChatModel (package org.noear.solon.ai.chat ) is a unified LLM client in Solon's AI ecosystem. Instead of writing raw HTTP calls for different model providers, you use a single API that supports: Synchronous calls — one-shot request, full response Streaming calls — reactive streaming via Project Reactor ( Flux<ChatResponse> ) Tool/Function Calling — let the LLM invoke your Java methods Chat Sessions — automatic conversation memory Multi-modal messages — text, images, audio Dialect adaptation — works with OpenAI, Ollama, Anthropic, Gemini, DashScope, and more The best part? It uses a dialect pattern — you point it at any compatible LLM endpoint, and it adapts automatically. 2. Setting Up Add the dependency to your pom.xml (no parent POM needed — Solon works standalone): <dependency> <groupId> org.noear </groupId> <artifactId> solon-ai </artifactId> <version> ${solon.version} </version> </dependency> This pulls in all built-in dialects (OpenAI, Ollama, Gemini, Anthropic, DashScope). 3. Configuration 3.1 Via YAML (Recommended) solon.ai.chat : demo : apiUrl : " http://127.0.0.1:11434/api/chat" # Full URL, not baseUrl provider : " ollama" # Dialect identifier model : " llama3.2" # Model name headers : x-demo : " demo1" Then create a @Bean to get a ready-to-use ChatModel : import org.noear.solon.ai.chat.ChatConfig ; import org.noear.solon.ai.chat.ChatModel ; import org.noear.solon.annotation.Bean ; import org.noear.solon.annotation.Configuration ; import org.noear.solon.annotation.Inject ; @Configuration public cla

EDRSR — the Unified State Register of Court Decisions — is effectively all of Ukraine's judicial practice in open access. Today Qdrant holds **44M+ vectors : criminal (19M), civil (14.3M), commercial (5.1M), misdemeanors (5.6M). Vectorization of civil cases (CPC, justice_kind=1) — the largest cohort at 33.7M documents — runs on a dedicated EC2 instance (r6a.xlarge, 32 GB RAM, 2 TB gp3). Here's what's under the hood: models, pipeline, cost, rakes, and current status. Why Vectorize Courts When a lawyer searches "is there case law on recovering bank prepayment fees" — they don't want to open 40 decisions and read them through. They want the system to surface the top 5 most relevant ones, pull out key paragraphs, and show how courts reasoned. Full-text search (FTS) over keywords doesn't give that — it returns every document containing the word "fee", and there are thousands. For this semantic task you need vector representations of text. The model turns a paragraph from a decision into a point in a 1024-dimensional space; semantically similar paragraphs sit near each other. A kNN search in Qdrant returns the top K nearest, and an LLM composes the answer from exactly those relevant fragments. The only problem: the register is big. Very big. Scale Our prod database holds full texts of decisions starting from 2006. Breakdown by procedural type: Civil (CPC) — 33.7M documents. The largest category. Consumer, housing, labor, family. Criminal (CrPC) — 12M+ Administrative (CAS) — 14M+ Commercial (CC) — 6M+ Misdemeanors (CUaP) — 6M+ The Qdrant collection edrsr_decisions on a dedicated EC2 currently holds 44M+ vectors (122 segments, on_disk=true): | Proceeding type | justice_kind | Vectors | |—|—|—| | Criminal (CrPC) | 2 | 19,036,347 | | Civil (CPC) | 1 | 14,328,427 | | Misdemeanors (CUaP) | 5 | 5,579,432 | | Commercial (CC) | 3 | 5,098,662 | | Total | | 44,042,868 | Civil cases processed: 14.3M out of 33.7M — that's 42%. After CPC completes there will be roughly 63M+ vectors in

The current Claude models give you an effort knob with five settings: low , medium , high , xhigh , max . The docs tell you what each is for. I wanted numbers, so I ran the same three real tasks across all five levels and measured tokens, latency, and quality. The results changed how I set effort, and one of them surprised me. Here is the data and what I do with it now. What effort controls Effort is not just "how much the model thinks." It controls overall token spend: how much it thinks and how it acts. Lower effort means fewer, more consolidated tool calls, less preamble, terser output. Higher effort means more exploration before answering. The default is high if you omit it. const response = await client . messages . create ({ model : " claude-opus-4-8 " , max_tokens : 16000 , thinking : { type : " adaptive " }, output_config : { effort : " medium " }, // the knob messages , }); The three tasks I picked tasks that span the range of what I actually do: Classification : label a contract finding as low/medium/high/critical. Short, scoped. Code generation : write a TypeScript function with edge-case handling. Medium difficulty. Multi-step audit : analyze a 200-line contract for vulnerabilities across functions. Hard, agentic. I ran each at all five effort levels, three times, and averaged. I scored quality against a known-correct answer for tasks 1 and 3, and by manual review for task 2. The results Task 1, classification. Quality was flat across every effort level. The right label is the right label, and the model nailed it at low just as well as at max . But token usage climbed steeply: max used roughly 8x the tokens of low for an identical answer. Latency tracked tokens. The lesson: for genuinely simple, scoped tasks, high effort is pure waste. I set classification to low . Task 2, code generation. Quality improved from low to high , then plateaued. At low the model sometimes skipped an edge case. At high it caught them. xhigh and max produced essentially the sam

You wire up the OpenAI SDK, ship the feature, and it works. Three weeks later someone in finance forwards a screenshot of a bill that tripled and asks what happened. You open the provider dashboard, see one big number, and… that's it. No per-feature breakdown, no idea which change caused it, no way to tell whether it's a bug or just growth. I've watched this happen at enough teams that I now treat "we can't explain our AI bill" as a predictable stage every company hits about two months after their first LLM feature ships. Here's how to get ahead of it — starting with plain code, then the tradeoffs, then where a dedicated tool actually earns its keep. Disclosure up front: I work on StackSpend, which does the full version of this. I've kept the first 80% of this post vendor-neutral because most of it you can and should build yourself before you buy anything. The core problem: the bill is a single number, your costs are not Provider dashboards give you total spend over time. What you actually need to make decisions is spend broken down by the dimensions you care about: Per feature — is it the summarizer or the chat assistant that's expensive? Per customer / tenant — which accounts cost more to serve than they pay? Per model — how much are you spending on GPT-4-class vs cheaper models? Per environment — is a runaway staging job quietly burning money? None of those dimensions exist in the raw bill. You have to attach them yourself, at call time, because after the request is gone the context is gone with it. Step 1: capture usage at the call site Every major provider returns token usage in the response. The trick is to log it with your own business context attached — the feature name, the tenant, the environment. Here's the pattern in TypeScript with the OpenAI SDK: import OpenAI from " openai " ; const openai = new OpenAI (); // Prices per 1M tokens — keep these in config, they change often. const PRICING : Record < string , { input : number ; output : number } > = { " g

In the AI slop-loaded, algorithm-powered modern reality, trends come and go - and the tech industry is no different. For the last few years, The Verge staff has compiled a selection of things that are IN for summer and OUT for summer - and each time there are some strong feelings. (Here are the last […]

The Cloud Native Computing Foundation (CNCF) has announced the graduation of OpenTelemetry, elevating the project to the foundation's highest level of maturity and formally recognizing it as production-ready for enterprise use. By Craig Risi

Spanlens is an open-source (MIT) LLM observability platform that lets developers monitor every call their application makes to OpenAI, Anthropic, Gemini, Mistral, OpenRouter, Azure OpenAI, or a local Ollama model. Integration takes one line: swap your client's baseURL to the Spanlens proxy, or run "npx @spanlens /cli init" and the wizard rewrites your code automatically. From that moment, every request is recorded with its model, token counts, latency, cost, and full prompt and response body, with streaming responses reconstructed automatically. The dashboard turns that raw log into operational insight. Cost tracking breaks spend down per request, per model, and per end user, and parses prompt-cache tokens separately so you see real cache savings rather than sticker price. Agent tracing visualizes multi-step workflows as Gantt waterfalls and node-and-edge graphs, highlighting the critical path so you can find the slowest dependency chain in a fan-out. Anomaly detection flags 3-sigma deviations in latency, cost, or error rate against a rolling 7-day baseline with root-cause hints. Alerts on budget, error rate, and p95 latency are delivered to Email, Slack, or Discord. Spanlens goes beyond passive logging. A regex-based PII and prompt-injection scanner inspects request and response bodies and can block injections at the proxy. The savings engine spots calls that match a cheaper model's profile (for example, a gpt-4o call that looks like a classification task) and estimates the monthly saving from switching. Prompt versioning with A/B experiments compares versions on latency, cost, and error rate using Welch's t-test for statistical significance, and an LLM-as-judge evaluation framework (judge with OpenAI, Anthropic, or Gemini) scores outputs against rubric anchors, with human agreement measured by Pearson r or Cohen's kappa. Reusable datasets power offline evals and regression checks.

Terminal-based AI agents have evolved considerably over the past few months, and several changes are significant enough that developers relying on these tools should be aware of them. Most notably, Google has begun retiring Gemini CLI for individual users in favor of Antigravity CLI — a closed-source successor that has drawn some pushback from the community that built out Gemini CLI's open-source ecosystem. Meanwhile, Claude Code has moved to the Opus 4.8 and Fable 5 models with a 1M-token context window, and OpenClaw, the open-source "always-on" agent, has grown into one of the most-starred projects on GitHub — alongside a documented CVE worth knowing about before deployment. I've just published an updated, fact-checked comparison covering: What actually changed with Gemini CLI's retirement, and what it means if you have scripts or CI/CD pipelines depending on it Claude Code's current model lineup, context window, and new Dynamic Workflows feature OpenClaw's architecture, extensibility via ClawHub, and the security considerations that come with deep system access A full feature-comparison table (cost, context window, open-source status, setup complexity) A practical case study walking through how all three tools can work together on a real project Would be curious to hear which of these you're using day-to-day, and whether the Gemini → Antigravity transition has affected your workflow. Full article here: Devlycan - Technology & Programming Insights Devlycan - Technology, programming, AI, lifestyle, and future trends—simple insights for the new digital generation. devlycan.com