标签：#DevOps

GitHub Copilot premium requests are the metered unit that determined how much advanced Copilot usage your plan covered, and if you are searching for how they work in mid-2026, you need two answers, not one. First, the mechanics: a premium request is consumed each time you use an advanced Copilot feature, scaled by a per-model multiplier, against a fixed monthly allowance that came with your plan. Second, the news: as of June 1, 2026, GitHub moved Copilot from request-based billing to usage-based billing , and premium requests are now officially labeled "legacy" throughout GitHub's own documentation. Their replacement is GitHub AI Credits, metered at one cent per credit. Both systems matter today. Annual Copilot Pro and Pro+ subscribers who stayed on their existing plans are still billed in premium requests, and every question about the new credits model (allowances, overages, admin controls) is easier to answer if you understand the system it replaced. Here is the complete picture, with the numbers. What is a premium request? GitHub's definition is simple: a request is any interaction where you ask Copilot to do something, whether that is generating code, answering a question, or reviewing a pull request. Routine interactions, like inline code completions, are unlimited on every paid plan and never touch the meter. Premium requests are the interactions that use more advanced processing, and they draw down a monthly allowance: Copilot Chat : one premium request per user prompt, multiplied by the model's rate (ask, edit, agent, and plan modes all count). Copilot code review : each review consumed one request originally; since June 1, 2026 it carries a 13x multiplier , so a single review deducts 13 premium requests. Copilot coding agent and CLI : one premium request per prompt or session, times the model's rate. Only your prompts count; the autonomous tool calls Copilot makes along the way do not. Spark : a fixed rate of four premium requests per prompt. The critical n

Have you ever stopped to think about the risk of having a pipeline where any merge into the main branch deploys straight to production without a single safety gate? For a long time, our workflow here was that classic setup almost every developer has used at some point: merge on main triggering an SSH script with git pull and pm2 restart It worked for day-to-day tasks, but it gave a false sense of stability lol The reality check hit when I found a critical blind spot in the automation: remote SSH scripts were running without strict error handling. In other words, if a git pull caused a conflict or a database migration failed halfway through, the script simply ignored the failure, ran to the end, and GitHub Actions marked the pipeline as green The absolute worst-case scenario for monitoring: the pipeline reported that everything went smoothly, while production was already completely down On top of that, the execution order was inverted: database migrations were running before the application build. If TypeScript threw a type error right after, the database schema had already advanced while the new code never booted. And since Prisma has no native down migrations, rolling back meant a high-risk manual intervention I decided to stop everything and redesign our delivery pipeline from scratch, starting from one clear premise: a tag is a release, a merge is not Today, nothing touches the production server without an annotated SemVer tag, going through 6 tightly coupled stages: Strict tag validation: only accepts annotated tags matching vX.Y.Z, ensuring author, timestamp, and audit trail for every single release Quality gates across PR and Release: automated tests with Vitest, strict typechecking, builds, and migration validation against a clean database via workflow_call Decoupled backups: an independent daily scheduled routine combined with a mandatory safety snapshot right before touching production Real migration dry-run: the most valuable gate, where the pipeline resto

Most monitoring watches for something bad to appear: a 500, a timeout, an expired certificate, a slow response. A heartbeat monitor does the opposite. It watches for something good to stop appearing . Your cron runs, your backup completes, your embedded device phones home, your queue worker drains — and each of those pings a URL to say "I'm still alive." The monitor's job is to notice when the pings go quiet. That inversion is the entire value. A cron that fails throws an error you can catch. A cron that stops being scheduled — the box got reimaged, the systemd timer got disabled, the container never came back after a deploy, the account got suspended for an unrelated billing issue — throws nothing at all. There is no log line, no exception, no non-zero exit. There is only the absence of the thing that used to happen. You cannot alert on an event that does not fire. You can only alert on the silence. So heartbeat monitoring looks trivial: store a timestamp on every ping, and if now - last_seen > expected_interval , fire an alert. It is about ten lines. And it is exactly those ten lines that will let 43 days of downtime pass without a second word — because the hard part of a dead-man's switch is not detecting the death. It is staying loud after it. I know because it happened to our own. Three states, and why the third one must stay silent Start with the check itself. A naive heartbeat has two states — alive or dead — and both are wrong at the edges. The real answer set has three: alive — a beat arrived within period + grace . Everything is fine. dead — the last beat is older than period + grace . The thing stopped. Page someone. unknown — the monitor exists but has never received a single beat. That third state is where two-state heartbeat monitors self-immolate. A brand-new heartbeat you just created has no last_seen timestamp. If your rule is "alert when last_seen is too old," a null last_seen is infinitely old, so the monitor pages you the instant you create it —

The SPF redirect trap: why -all can make redirect= useless SPF records often look simple until you start combining mechanisms and modifiers. One particularly easy mistake is to write a record like this: v=spf1 include:_spf.google.com -all redirect=_spf.example.com At first glance, it seems reasonable: authorize Google, reject everything else, and use another SPF policy through redirect= . But the redirect= part will never be used. The reason is an important detail of how SPF evaluation works. redirect= is not a fallback after -all An SPF record is evaluated mechanism by mechanism. For example: v=spf1 ip4:192.0.2.10 include:_spf.google.com -all The receiver checks the mechanisms until one matches. The all mechanism is special because it always matches . That means: -all effectively says: If nothing before this matched, return SPF Fail. Now consider this record again: v=spf1 include:_spf.google.com -all redirect=_spf.example.com Once SPF reaches -all , it already has a result. There is no reason to evaluate redirect= . The redirect modifier is only used when none of the mechanisms in the record produce a match. Because all always matches, a record containing all prevents redirect= from being used. What redirect= is actually for The redirect modifier is useful when several domains should share one central SPF policy. Imagine these domains: example.com example.net example.org Instead of maintaining the same SPF configuration independently on every domain, they can redirect to a central policy. For example: example.com TXT "v=spf1 redirect=_spf.example.com" example.net TXT "v=spf1 redirect=_spf.example.com" example.org TXT "v=spf1 redirect=_spf.example.com" And the central record might contain: _spf.example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all" Now the sending policy can be maintained in one place. This is very different from include: . redirect= vs include: These two are easy to confuse. include: Use include: when you want to authorize senders def

Security researchers are warning that thousands of enterprise servers could be exposed to compromise through vulnerabilities in their Baseboard Management Controllers (BMCs) - specialized processors embedded in server motherboards that provide administrators with remote, out-of-band control. By Craig Risi

AI coding agent Cursor has launched Origin, a git based code hosting platform embedded inside its AI-powered editor, positioning it as an alternative to GitHub for teams that already work in Cursor. Origin is rolling out in early beta on Pro, Teams and Enterprise plans, and lives inside a new Codebase tab within the Cursor application. By Matt Saunders

Originally published at ai.bedvibe.studio . I built a real-time tracker in Rust — about two thousand lines — that reads a live ADS-B feed, keeps a Kalman-filtered track per aircraft, and screens every pair for closest approach against separation minima. Roughly 150 aircraft, a full cycle in under a millisecond. It ran clean. Tests passed, the picture looked right, the numbers were plausible. It was refusing about one measurement in nine , and the only reason I ever found out is that the rejections went to a counter instead of a log line. The gate has a sub-second tolerance for clock error The tracker runs an innovation gate: when a position arrives, the filter predicts where the aircraft should be, and if the measurement is too far from that prediction it is rejected as physically impossible rather than believed. Once a track converges the innovation standard deviation settles around 36 m, so a five-sigma gate sits at roughly 180 m. An airliner at 250 m/s covers 180 m in 0.7 seconds . So the gate's entire tolerance for a wrong timestamp is under one second. Any pipeline that mis-times its measurements by more than that will have them rejected — correctly, and invisibly. The feed reports its own staleness. The pipeline dropped it. Every ADS-B record carries a field saying how old that position already was when the response was generated. In the original build it was parsed into the contact struct and never read again — the only other place that field appeared in the entire codebase was as 0.0 in test fixtures. Every measurement was therefore stamped with the tracker's own cycle clock, as though it had been observed at the instant it landed. This is the common case, not an exotic one. A field that is decoded and then unused looks identical to a field that is decoded and used , right up until you go looking for its second reference. Here is what that field actually contains, sampled across two consecutive polls of the live feed: reported age of position median 0.31 s p

The Problem with Most CI/CD Tutorials Most tutorials show you a pipeline that deploys a "hello world" app to a free Heroku instance. They skip the messy parts: secrets, rollbacks, and the moment your pipeline breaks because a dependency changed. I've been there. After years of fighting with over-engineered setups, I settled on a minimal pipeline that's easy to understand, debug, and extend. It's not fancy, but it works. The Core Idea A CI/CD pipeline is just three stages: Test - run automated checks Build - create an artifact Deploy - push the artifact to a server We'll use GitHub Actions because it's free for public repos and integrates with everything. But the same concepts apply to GitLab CI, CircleCI, or Jenkins. The Pipeline File Here's the complete .github/workflows/deploy.yml : name : CI/CD on : push : branches : [ main ] pull_request : branches : [ main ] jobs : test : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-node@v4 with : node-version : ' 20' - run : npm ci - run : npm test build-and-deploy : needs : test runs-on : ubuntu-latest if : github.ref == 'refs/heads/main' && github.event_name == 'push' steps : - uses : actions/checkout@v4 - run : npm ci - run : npm run build - name : Deploy to server uses : appleboy/scp-action@v0.1.7 with : host : ${{ secrets.SERVER_HOST }} username : ${{ secrets.SERVER_USER }} key : ${{ secrets.SSH_PRIVATE_KEY }} source : " dist/*" target : " /var/www/myapp" That's it. Let's break it down. Stage 1: Test The test job runs on every push and pull request. It checks out the code, installs dependencies with npm ci (which respects the lockfile), and runs your test suite. If a PR fails tests, the build-and-deploy job won't run because of the needs: test dependency. Stage 2: Build The build-and-deploy job only runs on pushes to main (not on PRs). It builds your app into a dist folder. For a Node.js app, npm run build might be a bundler like Vite or webpack. For a Python app, you'd replace with

Originally published on the Merlonix blog . There are two different questions about your domain's email authentication, and almost every checker answers only the first. The first is do you have SPF, DKIM, and DMARC records — a presence question, a yes/no lookup. The second is do those records actually stop someone from sending email that looks like it came from you — an enforcement question. You can pass the first and fail the second completely, and the gap between them is the whole game: a domain with all three records published, every free checker showing green, that a spammer can still spoof at will because each record is published in its permissive, do-nothing mode. The permissive modes exist for a good reason — they're how you roll these records out without bouncing your own legitimate mail. The problem is that "published it in monitor mode so I could watch first" and "finished" look identical to a tool that only checks presence, and an enormous number of domains stop at the first and never come back. Here's what actually decides enforcement, record by record, and how to tell which mode yours is in. SPF: only -all actually rejects An SPF record lists which servers are allowed to send mail as your domain, and it ends in an all mechanism that says what a receiver should do with a server that isn't on the list. That final qualifier is the entire enforcement decision, and there are four of them: -all (hardfail) — "reject mail from any server not listed." This is the only one that protects you. ~all (softfail) — "accept it but mark it suspicious." Receivers still deliver it. Softfail is the rollout setting, and it's where most records get stranded. ?all (neutral) — "no opinion." Functionally the same as having no policy on the all term. +all — "any server on the internet may send as this domain." This is actively worse than no SPF at all, and it's usually a copy-paste accident. So an SPF record can be present, syntactically perfect, and end in ~all — and it stops no

AI agent observability means capturing your agent's reasoning cycles, tool calls, and token usage as...

How We Cut AWS Staging Costs by 87% With EventBridge Scheduler No code changes. No Lambda functions. No complex scripts. Just 4 schedulers and a realization that nobody uses staging at 3am. Here's a question every engineering team should ask themselves: "When was the last time someone actually used our staging environment at 2am?" For us? Never. Not once. Yet we were paying for it — EC2 running, ECS Fargate tasks spinning, compute burning money — every single hour of every single day, including weekends, holidays, and the 21 hours per day when nobody on our team was even awake. That's the hidden tax of staging environments. And most teams never fix it because the solution feels complicated. It isn't. This is how we cut our staging compute costs by 87.5% — using AWS EventBridge Scheduler, zero Lambda functions, and zero lines of application code. The Problem: Staging Was Running 24/7 For No Reason Our staging environment had two resources running around the clock: EC2 instance — our staging app server ECS Fargate service — our backend API container Our team actively uses staging for roughly 3 hours a day . That's it. The math was embarrassing: Running: 24 hours/day Used: 3 hours/day Wasted: 21 hours/day = 87.5% of compute going nowhere Monthly cost breakdown: EC2 + ECS Fargate (24x7): ~$19.18/month EC2 + ECS Fargate (3hr/day): ~$2.40/month Monthly saving: $16.78 Yearly saving: $201.35 Reduction: 87.5% $201/year saved on staging compute alone — with 45 minutes of setup and zero application code changes. Multiply that across dev environments, QA clusters, review apps, and load test environments. The savings compound fast. The Solution: AWS EventBridge Scheduler Most engineers reach for Lambda when they need to automate AWS tasks on a schedule. That works — but it means writing code, managing runtimes, setting up CloudWatch Logs, and maintaining a function forever. EventBridge Scheduler is the better tool here. It lets you call any AWS SDK action directly on a cron sche

An SSE stream is an HTTP request that never ends. Every default you did not touch is working against it. TL;DR : your SSE endpoint breaks twice before it reaches your logic. Once because the Connection header is illegal in HTTP/2. Once because your Go server's default timeouts cut the stream at 30 seconds. And if you stay on HTTP/1.1, a permanent stream freezes the rest of your page. In August 2026, Go patched a flaw where a timeout was not applied to HTTP/2 connections. Same lesson: a timeout only protects what it covers. This article is for Go developers shipping streaming to production. SSE, WebSocket, long-poll: anything that stays open. The setup SSE stands for Server-Sent Events. It is a one-way HTTP stream. The server pushes messages, the browser listens. The format is simple. You open a text/event-stream response, you write lines, you flush. The browser receives them as they come. I run two SSE endpoints in production. The first is a Go notification service, on Kubernetes, behind a reverse proxy. The second is an internal cockpit that refreshes its UI without a page reload. Both broke. In different places, with the same symptom. An SSE stream is a request that never ends Here is the key to the whole article. To your server, an SSE stream is not a special case. It is a very slow request. And every guardrail in an HTTP server targets the slow request. Write timeout, context timeout, idle timeout. They exist to kill whatever drags on. Your legitimate stream looks exactly like what they are meant to kill. That is the whole problem. The Connection header is illegal in HTTP/2 First incident. The endpoint answers 200, then the browser shows net::ERR_HTTP2_PROTOCOL_ERROR . The client reconnects in a loop. The cause was one line. My handler set a Connection: keep-alive header. We all copy it from some old SSE tutorial. Connection is a hop-by-hop header. A hop-by-hop header applies to one network hop only, never end to end. HTTP/2 forbids these headers (RFC 9113 §8.2.

We have a web server container running the nginx image. The access and error logs generated by the web server are not critical enough to be placed on a persistent volume. However, Nautilus developers need access to the last 24 hours of logs so that they can trace issues and bugs. Therefore, we need to ship the access and error logs for the web server to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from nginx. Nginx does one thing, and it does it well - serving web pages. The second container also specializes in its task - shipping logs. Since containers are running on the same Pod, we can use a shared emptyDir volume to read and write logs. Create a pod named webserver . Create an emptyDir volume named shared-logs . Create a regular container in the webserver pod from the nginx:latest image named nginx-container , and an init container from the ubuntu:latest image named sidecar-container . Add the following command to the sidecar-container "sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done" Mount the shared-logs volume in both containers at /var/log/nginx . Ensure all containers are in a running state. What is a Sidecar Container? Think of a sidecar like a motorcycle sidecar – it's attached to the main vehicle and extends its capabilities without changing the main vehicle itself. ┌─────────────────────────────────────────────────────────────────────────────┐ │ The Sidecar Analogy │ │ │ │ ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ Motorcycle: The Main Vehicle │ │ │ │ - Does its primary job (serving web pages) │ │ │ │ - Doesn't worry about extra tasks │ │ │ └────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ Sidecar: Adds Extra Functional

We run ~100 LLM agents unattended on local models. Last week we found one document that had been rewritten 245 times in 5 days — every attempt rejected. A sibling document: 225 times. Combined, about 470 wasted generations, all burned on the same two files. Here is the autopsy, with the actual numbers. The loop Our pipeline is simple: a producer agent writes a document, a reviewer agent checks it against a contract (minimum length, required sections, no placeholder junk), and rejected work goes back with fix instructions. The rejected document was a key-management (KMS) implementation spec — 4,452 characters, perfectly on-topic. The reviewer's verdict: "The request was a 3-line email triage response (LOCK / VERDICT / REASON), but the answer is a long KMS spec. Rewrite as 3 lines only ." One problem. We grepped the document: the words "LOCK", "VERDICT", and the name of the triage service appear zero times in it. The reviewer had invented the request. Why the loop never ended Two contracts collided: The reviewer's fix instruction: output 3 lines only The producer's output contract: minimum 600 characters No output can satisfy both. So the producer failed the contract, got re-queued, produced again, failed again — 245 times. Our retry cap counted reviews , but a contract-failed output never reaches review. The give-up mechanism existed; it just watched the wrong counter. Root cause: the reviewer never saw the request Our review prompt contained the artifact body (first 4,000 chars) and the output format. It never contained the original request. We asked a model "does this match the request?" without telling it what the request was. A model asked to judge against information it doesn't have will hallucinate that information. Ours did, confidently, 245 times' worth. Bonus failure: we truncated long documents to 4,000 characters before review without saying so, and reviewers marked them "thin — cut off mid-sentence." The cut was ours, not the producer's. How common was it

.NET 10 NU1015 turns a PackageReference without a version into a restore error. I like the stricter default because an unbounded direct dependency can quietly resolve the lowest package version. The catch is that versionless XML is also the correct shape for NuGet Central Package Management (CPM). A mechanical “add Version everywhere” repair can undo the policy your repository intended to enforce. I use a simple split: first decide who owns the version, then make restore prove the answer. Why .NET 10 NU1015 stops the build Before .NET 10, NuGet reported NU1604 when a direct reference had no inclusive lower bound. Restore could continue and select the lowest version available from the configured sources. Starting with .NET 10, the same mistake produces NU1015 and restore fails. Microsoft documents this as a stable behavioral change in the .NET 10 compatibility guidance . Here is the ambiguous project entry: <ItemGroup> <PackageReference Include= "Demo.Greeting" /> </ItemGroup> If this is a normal direct reference, the project is missing its version. If CPM is active, the project is correct and the version should live elsewhere. The NU1015 diagnostic reference calls out a common failure mode: a project that expected CPM was copied into a location where CPM is disabled or its props file is no longer discovered. That distinction matters more than silencing the error. It tells me whether the project file or the repository-level package policy is broken. The timing can be misleading. An SDK upgrade may expose an old direct reference that had always relied on lowest-version resolution, while a repository move may break a previously valid CPM import. I inspect the failing project's evaluated inputs, nearby props files, and recent path changes before editing package metadata. That keeps a restore migration from turning into an accidental package-management migration. Fix the owner, not only the XML For a direct reference, I add an explicit version: <PackageReference Include=

Building AI Agents with frameworks like CrewAI or LangChain often hits a bottleneck: heavy, slow web scraping that bloats context windows and increases LLM token costs. To solve this, I built Smart Scraper M2M — a lightweight, high-performance web scraper API designed specifically for machine-to-machine (M2M) communication. 🌟 Key Features ⚡ Ultra-fast: Returns clean structured JSON in ~30ms . 🧠 Context-optimized: Strips out useless HTML/CSS junk so your LLMs process only relevant data. 🤖 Agent-friendly: Built to integrate seamlessly into CrewAI, LangChain, or custom Node.js agents. 🚀 Quick Start You can test the API or check the full source code directly on GitHub: 🔗 GitHub Repository: https://github.com/MRIGL/smart-scraper-m2m 💬 Feedback & Community I’m actively improving the API and would love to hear your thoughts, feature requests, or contributions! Feel free to star the repo or leave a comment below.

Security researcher Christopher Domas developed skitter-creek-bath-salts, an open-source hardware security tool that disrupts CPU privilege boundaries by manipulating memory controller translation registers. This allows unprivileged software to access protected memory regions, revealing a vulnerability in modern processor architectures that could affect cloud and confidential computing security. By Olimpiu Pop

Control Plane (Master) & Worker Nodes Control Plane components: API Server Scheduler Control Manager etcd Worker Node components: Container Runtime Kubelet Kube-proxy Node Processes Each node has multiple Pods on it. 3 processes must be installed on every node — used to schedule and manage those Pods. Nodes are cluster services that actually do the work. Container Runtime Examples: Docker, containerd, CRI-O. containerd is used in worker nodes — it's lightweight in nature. This should be installed on every node because application Pods need to run containers inside the node. Kubelet The process which schedules the Pods and containers underneath is Kubelet. Kubelet interacts with both the container and the node. Kubelet starts the Pod with the container inside. Communication between two nodes is because of Services. Creation of Pod: Kubelet insures the Pod is always running — if not, it will inform etcd. Kube-proxy Kube-proxy forwards the request from Pod to Service. Makes use of the communication, with load balancing. Provides networking (container ID, IP address). Load balancing — basically using IP tables. It makes sure to send the request to the same machine instead of sending it to others (from same node communications). So, how do you interact with this cluster? Schedule the Pod Monitor Re-schedule/restart the Pod Join a new node Managing processes are done by master nodes (the control plane). API Server When you, as a user, want to deploy a new application in a Kubernetes cluster, you interact with the API server using some client — could be UI or CLI. It's a cluster gateway — it gets the initial request of any update into the cluster, even the queries from the cluster. It also acts as gatekeeper for authentication. It means when you want to schedule new Pods, deploy new applications, create new services, or any other components — you have to talk to it first. Flow: Some request → API server → Validates request → Other processes → Pods Only one entry point to t

We often focus on what someone says, but in the realm of clinical psychology, how they say it is often more revealing. Subtle changes in speech—a slight tremor (jitter), a slowing tempo, or a flattened pitch—can be early indicators of depression or anxiety long before a user explicitly voices their distress. In this tutorial, we are building Psycho-Acoustic , a high-performance monitoring tool that leverages the HuBERT model , HuggingFace Transformers , and Librosa to quantify emotional states from non-verbal acoustic features. Whether you're interested in speech sentiment analysis , mental health AI , or advanced audio processing , this guide covers the end-to-face-mic implementation. The Architecture of Sound 🏗️ To accurately detect mental health indicators, we can't just look at text. We need a multimodal approach that combines raw signal processing with deep learning representations. graph TD A[Raw Audio Input .wav] --> B[Librosa Preprocessing] B --> C{Feature Extraction} C --> D[Traditional Features: Jitter, Shimmer, Pitch] C --> E[Deep Learning: HuBERT Embeddings] D --> F[Feature Fusion Layer] E --> F F --> G[Classification Head: Anxiety/Depression/Neutral] G --> H[Quantified Mental Health Score] H --> I[Deployment via ONNX Runtime] Prerequisites To follow this advanced guide, you’ll need: Python 3.9+ Tech Stack : transformers , librosa , torch , onnxruntime A basic understanding of digital signal processing (DSP). Step 1: Extracting Non-Verbal Acoustic Features 🌊 Before hitting the neural network, we need to extract "Psycho-Acoustic" features. Depression is often characterized by "speech prosody" changes—specifically reduced pitch range and slower speaking rates. import librosa import numpy as np def extract_prosodic_features ( audio_path ): y , sr = librosa . load ( audio_path , sr = 16000 ) # 1. Fundamental Frequency (F0) - Pitch f0 , voiced_flag , voiced_probs = librosa . pyin ( y , fmin = librosa . note_to_hz ( ' C2 ' ), fmax = librosa . note_to_hz ( ' C7

Free AI tokens are a trap, and teams that treat a free quota as genuinely free pay later in migration and rework. A free allowance only helps when paired with a hard kill switch that stops an experiment the moment it exceeds a budget you chose in advance. This article argues that position, then shows a small gated client that makes free model access and a free server actually safe to use. The concrete example is MonkeyCode's free tier, but the gate works against any OpenAI-compatible endpoint. The trap nobody budgets for Every new model release resets the same argument: the price per token is low, so the cost of trying it must be low too. That reasoning ignores the expensive parts of an experiment, which are the integration, the evaluation, and the cleanup, not the inference itself. A free quota hides those costs behind a zero on the invoice, so teams skip the measurement step and discover the real price only when they migrate. The failure modes repeat across teams: Unbounded loops. A batch job that retries on rate limits can burn a week of free quota in an afternoon, and nobody notices until the allowance is gone. Silent lock-in. Code written against one provider's streaming quirks works fine for a prototype, then becomes a rewrite when the free tier disappears or changes. Shared-budget collisions. One teammate's runaway script consumes the allowance that three other people planned to use, which turns a technical problem into a political one. None of these are solved by choosing a cheaper model. They are solved by treating the free allowance as a finite resource with an explicit ceiling. The gate, not the gift, is the product The fix is a gated client that wraps any OpenAI-compatible chat endpoint with a token budget, a timeout, and an abort path. It is deliberately small, because a cost gate that requires its own deployment will not get used. # cost_gate.py — a hard ceiling for cheap experiments. # Usage: # export LLM_BASE_URL="https://your-endpoint.example/v1" #