DEV Community: ServBay

I Ran a Real Internal Tool Through Cursor Live Apps. Here Is the Part That Actually Helped

ServBay — Mon, 09 Nov 2026 14:25:41 +0000

The last few side projects I gave up on did not die because I could not write the code. They died somewhere between a working local build and a link I could hand to another person.

That gap costs time in a very specific way. A database to pay for, an instance to provision, authentication to wire up, environment variables that drift between my laptop and the cloud runtime, then previews, acceptance testing and the release itself. Each step is small on its own. Together they are the reason a lot of my ideas never got a URL.

So when Cursor shipped Live Apps, I paid attention. It gives the Cloud Agent a hosted full stack delivery environment. Before this, the Agent stopped at helping me write code. Now it can use a built-in PostgreSQL database, Cursor based authentication and a cloud runtime to turn that code into a web application with an online preview link.

My assessment after running a real internal tool through it is narrow. Live Apps closes the distance between generated code and a shareable preview. I would not treat it as a production operations platform at this stage.

What This Cloud Workflow Requires

Who can use it, and what it connects to

Live Apps is a cloud workflow for paying Cursor Cloud Agent users. It runs entirely in the cloud and is not available in local Agent mode. I can build an application from scratch, or connect an existing Cursor Origin or GitHub repository. GitLab is not supported right now.

What the Agent handles after handoff

Once I hand over a project, the Agent works through delivery in the background. It creates or pulls the code, configures the cloud runtime, connects PostgreSQL, sets up Cursor based authentication, hosts the application and provides an interactive preview environment. After I finish testing in the preview, I click Publish myself and get a public link to share.

What the documentation does not settle

The official documentation does not yet give a complete list of supported frameworks, and it does not clearly specify hosting resource quotas or billing limits. My working rule is to use it only for small, early-stage projects that do not need a specially customised runtime.

A Real Internal Tool, Five Stages

To see how it behaves, I took a common requirement through the full delivery process. An internal team tool with user login, task list management and PostgreSQL storage. Even with the Agent doing the implementation, each of these five stages still needed my own review.

Stage one, project generation

I describe what I need to Cloud Agent in natural language, and it builds the application structure and basic pages quickly. I do not start with the interface. I first check whether the project starts correctly and whether I am comfortable with the frontend and backend frameworks it picked and the way it accesses the database. If I am going to maintain this later, I need to know the stack. I also check that the core task-status transition logic is complete.

Stage two, environment configuration

Once the project runs, I go through the dependency installation scripts, startup commands and environment variables it generated. When something works in the cloud but breaks locally, inconsistent environments are usually the reason. I look at whether dependency versions are pinned, whether environment variables are documented and traceable, and whether there is a way to configure third-party service keys manually. My acceptance question is simple. Could someone new take this over tomorrow and reproduce it locally by following the documentation.

Stage three, data integration

In earlier AI-generated prototypes, data lived in frontend memory and disappeared on refresh. This time the Agent configured PostgreSQL for me, including the table schema, database migration scripts and basic create, read, update and delete operations. I tested connection stability and whether rerunning migrations caused errors. I also deleted tasks, updated their status and entered invalid characters, to confirm that data was really persisted and that invalid operations were handled.

Stage four, cloud preview and testing

With the preview link in hand, I tested login, data reads and writes, page refreshes and error handling over a real network connection, then compared the results against the local build. My focus here was access control. Would an unauthenticated user be blocked if they typed a protected URL directly. Were two different users' task records kept apart. If the database connection dropped, did the page show a useful message or dump a stack trace onto the screen.

Stage five, publishing

A working preview does not mean the application is safe to share. Before clicking Publish, I check four things manually. The application points to the production database. Authentication has no test backdoors left on. Leftover test data is cleared. Neither the frontend code nor the API responses expose secrets or administrative endpoints. After publishing I record the version, the live URL and the rollback procedure. Only then do I call the delivery finished.

What Happens to My Existing PHP and Node Projects

The part I genuinely value

As someone who works mainly in PHP and Node, I have accumulated plenty of existing projects that still need maintenance. Rather than moving everything into Live Apps, I weighed the convenience of cloud automation against the control of a local environment.

The part I appreciate is that Live Apps removes the initial database and cloud environment setup, and puts authentication, hosting and code into one workflow. For a small internal tool, a product prototype, or helping a friend who has never deployed anything get a first version online, it removes most of the friction around the first launch.

The part that stays on my machine

Complex business logic is a different story. I still need my local development environment when I have to step through intricate logic, use my established PHP and Node toolchains, or manage private packages and local services. The same applies to reproducing an intermittent production bug, fine-tuning database settings, or handling SSL certificates and deployment details myself. For the foundations of long-term maintenance I want that control, and this side of my work still runs through ServBay, an AI development management tool I use to keep services, databases, domains and SSL on my own machine.

The three tests I apply before choosing

The first measures time to launch for a new project. I record how long it takes to set the environment up locally, provision a server and deploy the way I normally would, then compare that against the Live Apps workflow. I count the manual steps in database setup, authentication and environment configuration. If the cloud route substantially shortens the time to a usable link, I use it for early validation.

The second sets the migration limits for an existing project. I connected an existing Node project I already run, to see whether its system dependencies, custom startup commands, historical database migrations and third-party services moved across intact. When a required system dependency is missing or a migration fails, I stop instead of forcing it, and the project stays on its current local plus cloud server setup.

The third measures how much manual security work is left. In the preview environment I test for authentication bypasses, access to other users' data, unexpected API parameters and exposed sensitive configuration. I note which problems the Agent already prevented and which ones I have to patch in code myself. One pass gives me a realistic estimate of the time I need to set aside for manual checks before launch.

Where I Land

For my next prototype, internal tool or MVP meant to test demand quickly, I would use Live Apps to skip the initial cloud setup and get a link into users' hands sooner, provided the code is already on GitHub or Cursor Origin.

I would not currently put messy legacy PHP or Node codebases on it. Nor projects that need tight control over the runtime or the underlying database, nor cases where I need predictable long-term operating costs and clear resource limits, nor production systems with strict compliance, audit or data-location requirements.

The value I get from Cursor Live Apps is a connected workflow across code generation, PostgreSQL, authentication, previews and hosting. What I judge is not how elegant the generated code looks. I ask whether it shortens the time from a new idea to its first launch, whether it cuts environment configuration errors, whether it makes my projects easier to hand over for feedback, and whether it gives me enough visibility to validate the result before I click Publish.

The split that suits me right now is straightforward. Core business logic, deep debugging and reproducing difficult issues stay local. Cloud Agent handles the initial cloud configuration, the previews and the basic delivery checks. Final quality acceptance, and the decision to click Publish, stays with me.

What Cursor Live Apps Handles and Where a Local Setup Still Wins

ServBay — Mon, 09 Nov 2026 14:25:28 +0000

Most of my side projects did not die from a lack of code. They died somewhere between a working editor session and a URL a user could open. A first version from an AI tool takes seconds now. Turning that version into something running with a database, a login screen and a host takes an evening of provisioning, environment variables and runtime settings. Two of my own projects stalled exactly there.

That gap is what Cursor Live Apps targets. It adds a cloud-based full-stack hosting and delivery environment to Cursor's Cloud Agent. Before this, the Agent stopped at producing code. With Live Apps, it can use the built-in PostgreSQL database, user authentication and a cloud runtime, then hand back an online preview link.

I took a real requirement through the whole flow to see where the product holds and where it does not. Short version. Live Apps closes the distance between generated code and a shareable preview. For lightweight applications it is a reasonable default. As a production operations platform it is not there yet.

What Live Apps Adds to the Cloud Agent

Access requirements and current limits

Live Apps is a cloud workflow aimed at paying Cursor Cloud Agent users. It runs entirely in the cloud and is not available in local Agent mode, so nothing here replaces a local setup. A project can start from scratch inside the tool, or be connected from an existing Cursor Origin or GitHub repository. GitLab is not supported at the time of writing.

Once a project is handed over, the Cloud Agent walks the delivery pipeline in the background. It creates or pulls the code, configures the cloud runtime, connects PostgreSQL, sets up Cursor-based authentication, hosts the application and opens an interactive preview environment. Testing happens in that preview. Publishing is a manual click that produces a public link.

The documentation gap worth planning around

The official documentation does not yet give a complete list of supported frameworks, and it does not spell out hosting resource quotas or billing limits. That shapes how the tool should be used. My own rule is to keep it for small, early-stage projects that do not need a specially customised runtime, and to keep runtime-sensitive work elsewhere until those limits are documented.

Five Checks I Run Before Sharing a Link

I used a single requirement to walk the whole pipeline, an internal team tool with user login, task-list management and PostgreSQL storage. The Agent wrote the implementation, and each stage still needed review.

Stage one, project generation

Describe the tool in natural language and the Agent produces the application structure and basic pages. The interface is the least interesting part of the result. What I check first is whether the project starts cleanly, which frontend and backend frameworks were chosen, how database access is handled, and whether the core task-status transition logic is complete. If the code is going to be maintained later, the stack has to be legible on day one.

Stage two, environment configuration

Dependency installation scripts, startup commands and generated environment variables all get read at this point. A project that runs in the cloud and breaks locally usually does so because the two environments drifted apart. I look for pinned dependency versions, environment variables that are documented and traceable, and a documented path for adding third-party service keys by hand. The acceptance question is blunt. Could someone new take this over tomorrow and reproduce it locally from the documentation alone.

Local drift is a different problem from delivery, and it sits on the side of the workflow that an all-in-one AI development management tool such as ServBay covers, with services, databases, domains and SSL running on the developer's own machine.

Stage three, data integration

Earlier AI-generated prototypes kept data in frontend memory and lost it on refresh. This time the Agent configured PostgreSQL with a table schema, migration scripts and basic create, read, update and delete operations. Testing covers connection stability, whether re-running migrations throws errors, and the awkward inputs. I deleted tasks, changed statuses and typed invalid characters into fields to confirm that writes actually persisted and that bad input was rejected rather than stored.

Stage four, cloud preview and testing

With a preview link in hand, the work moves onto a real network. Login, reads and writes, page refreshes and error handling get exercised and compared against the local build. Access control takes most of the attention. An unauthenticated request straight to a protected URL should be blocked. Two different users' task records should stay separated. A dropped database connection should produce a readable message instead of a stack trace on screen.

Stage five, publishing

A working preview is not a finished application. Before clicking Publish, four things get checked by hand. The application points at the production database. Authentication has no test backdoors left enabled. Test data has been cleared. Neither the frontend code nor the API responses expose secrets or administrative endpoints. After publishing, the version, live URL and rollback procedure are recorded. That is the point where delivery counts as done.

Existing PHP and Node Projects

Most of my maintenance work sits in PHP and Node repositories that predate all of this. Moving them wholesale into Live Apps is not the plan. The trade is convenience against control, and the balance depends on the project.

What the cloud workflow removes

The initial setup of a database and a cloud runtime disappears, and authentication, hosting and code land in one workflow. For a small internal tool, a product prototype, or a friend who needs a first version online without learning cloud deployment, that removes a good part of the friction around a first launch.

What still belongs on a local setup

Complex business logic does. Stepping through intricate code, using an established PHP or Node toolchain, managing private packages and local services, reproducing an intermittent production bug, tuning database settings, handling SSL certificates and deployment details, all of that still runs better where I can see it. The foundations of long-term maintenance still want a local environment.

Three tests for sorting projects

Time to launch for a new project. I record how long the usual path takes, local setup, a provisioned server, a deploy, then compare it with the Live Apps flow. The manual steps around database, authentication and configuration are the ones that matter. If the cloud path cuts the time to a usable link substantially, early validation goes there.

Migration limits for an existing project. I connected a running Node project to see whether its system dependencies, custom startup commands, historical database migrations and third-party services came across intact. A missing system dependency or a failed migration is a stop signal. The project stays on its current local plus server arrangement.

Remaining manual security work. Inside the preview, authentication bypasses, other users' data, unexpected API parameters and exposed configuration all get probed. The useful output is the split between what the Agent already prevented and what needs a manual patch. One pass gives a realistic estimate of the review time a launch needs.

Where This Leaves the Workflow

What goes to Live Apps

For the next prototype, internal tool or MVP that needs to test market demand quickly, I would use Live Apps to skip the initial cloud setup, as long as the code already lives on GitHub or Cursor Origin. That answers a question I care about, which is how fast an idea reaches a link someone can click.

What stays away

Messy legacy PHP or Node codebases do not go there, and neither do projects that need close control over the runtime or the underlying database. The same applies to work that needs predictable long-term operating costs and clear resource limits, or production systems under strict compliance, audit or data-location requirements.

The question I actually evaluate

Judged on its own terms, the value of Live Apps is that generation, PostgreSQL, authentication, previews and hosting sit in one workflow. The question I ask when evaluating it is not whether the generated code looks elegant. It is whether the path from idea to first launch got shorter, whether environment configuration mistakes dropped, whether a project is easier to share for feedback, and whether there is enough visibility to validate the result before Publish gets clicked.

The split that works for me now keeps core business logic, deep debugging and hard-to-reproduce issues in my local environment, while the Cloud Agent handles first cloud configuration, sets up previews and runs the basic delivery checks. Final quality acceptance, and the decision to publish, stays manual.

The Northflank AI Key Notice Sent Me Auditing My Own Setup. Here Is the Order That Worked

ServBay — Fri, 06 Nov 2026 16:21:08 +0000

I read the Northflank status page post twice before touching anything. On October 31, 2026 the cloud development platform said users had reported unauthorized use of AI API keys hosted on it, and that audit logs were now available to all customers, free tier included.

Nothing I run lives on Northflank. What kept me reading was that my own key layout has the same shape as the one being described. Provider credentials spread across environment variables, a couple of local tool configs, and a scheduled job I had not opened in months. So I spent an evening on the inventory and rotation I had been postponing. Below is the order I worked in, including the parts that turned out to be less obvious than they look.

What Northflank Is, and Why So Many Keys Sat There

A Kubernetes PaaS with a BYOC option

Northflank is a cloud-native platform-as-a-service provider built on Kubernetes. It builds and deploys microservices, managed databases, scheduled background jobs, and GPU workloads straight from a Git repository. Alongside the managed cloud it offers a Bring Your Own Cloud mode, where a company connects the control plane to its own AWS, Google Cloud, or Azure account, which removes the operational work of writing Kubernetes configuration files by hand.

Why LLM teams ended up storing credentials there

Teams running AI agents, backend API services, sandboxes, and automated data-processing scripts on Northflank need those containers to call external model APIs such as OpenAI and Anthropic. The usual place for the keys is workload environment variables, Secret Groups, or global secrets, next to database connection strings and third-party service tokens. Keeping credentials in one managed place is convenient, and it also means a platform-side problem puts every hosted model credential into the same exposure path.

What the Notice Said, and When

Three updates, three timestamps

13:58 UTC on October 30. Northflank told users to treat all environment variables as if they had been decrypted, and to disable or rotate keys. Later updates clarified that rotation should cover credentials in workloads, Secret Groups, and global secrets, and recommended turning off public access for any add-ons that had it enabled.
23:38 UTC on October 30. The platform said it had received user reports of unauthorized AI API key usage. It asked users to revoke existing credentials with the issuer, generate replacements, update the affected configuration and workloads, review usage and billing records with their AI providers, and report suspicious usage to both the platform and the providers involved.
01:04 UTC on October 31. Audit logs became available to all customers.

The company later confirmed that some users' AI API keys hosted on the platform had been used without authorization by outside parties.

Two misreadings I had to correct

The first is that asking users to act as if their environment variables had leaked is a baseline precaution in incident response, meant to contain risk quickly. It is not confirmation that every user's variables were stolen. The second is that reports from some users do not mean every customer on the platform saw unauthorized usage.

The Hacker News discussion drew a lot of attention and plenty of practical advice on checking credentials, mixed with speculation about the attack method, the platform's architecture, and related incidents. Community threads are not evidence of how the breach happened. The official notice mentions similar attack activity, but attacker identity and the full intrusion path stay open until the final investigation report lands. For a development team, the urgent question is not how the platform was compromised. It is where credentials are stored, what they connect to, and whether the old ones are actually dead.

Where the Blast Radius Actually Is

The inventory order I used

The real blast radius of a key depends on how many places it is deployed, not on what it was originally created for. A key made for testing models locally gets copied into production. A demo project goes away and its scheduled jobs keep running. Several agents share one key under the same provider account to skip setup work. Updating only the core production services leaves the peripheral environments untouched.

Platform configuration, both obvious and hidden. Following the official guidance, start with workload environment variables, Secret Groups, and global secrets. Then walk CI/CD build scripts, automated deployment pipelines, preview environments, and third-party webhook integrations to confirm none of them hardcode or cache the same key.
Match configuration to the instances actually running. One environment variable may be inherited by several microservices or hand-copied into different projects. Updating a frontend web service does not refresh background queue workers or cron jobs. Old containers nobody maintains but that are still running belong on the checklist.
Keep a redacted tracking sheet. Record each key's name, the prefix or ID the provider shows, the project it belongs to, where it is stored, which services use it, and its current status. Never paste a full key in plain text into the sheet, team chats, or ticketing systems. That creates new leak sources inside the collaboration tools.
Check permissions on the provider side. Log in to the console for OpenAI or Anthropic, confirm which organization and project the key belongs to, then look at which model endpoints it can call and whether it can read or write fine-tuning data or upload files. Permission granularity varies widely between providers. An API key is not automatically limited to text generation, and it is not automatically full admin either.
Sweep the other infrastructure credentials in the same environment. Database connection strings, object storage keys such as AWS S3 or Google Cloud Storage, and payment API tokens all rotate alongside the model keys if they lived in the affected runtime.

Rotation, and Why Deleting the Variable Does Nothing

Revoke, generate, deploy, verify both directions

Deleting an environment variable removes a string from the platform's database. If the key was already copied to an outside server, whether it can still call the model depends on the provider. The same holds for deleting a local .env file or scrubbing old code from Git history.

Revoke the old credential in the provider console. Find the key, revoke or delete it, and confirm its status shows it is no longer active. If suspicious calls are coming in right now, cut the credential immediately to limit the charges, while weighing a brief service interruption and preparing a recovery plan.
Generate the replacement from a trusted device. Reach the console through the official domain, check the team member list and role permissions for unfamiliar changes, then generate the new key under least privilege. If the cloud platform has not finished its isolation, remediation, or migration work, hold off putting new production keys back into the high-risk environment.
Update every configuration and restart the instances. Backend services and long-lived processes read environment variables once, at container start. Saving a change in the web console does not change the process already in memory, which keeps sending requests with the old key until it is restarted or redeployed.
Verify both directions. The old key must be fully rejected by the provider, and the services must be making calls successfully with the new one. Never print the new key into application logs, and do not paste a curl test command containing the full key onto a shared server where shell history captures it.

Keep watching for a while afterwards. Occasional 401 Unauthorized errors in the logs mean some old instance or scheduled job has not picked up the new configuration. Unexplained usage on the bill usually means the account has other backup keys nobody dealt with.

Reading Audit Logs Against Provider Bills

Four steps that produce a usable timeline

Audit logs open a view inside the platform. Platform logs and model provider logs verify different things, so the two have to be pieced together. If a key is exfiltrated and used from machines outside the platform, the original application's service logs show nothing at all, and an empty audit log does not rule out abuse. Confirm first how far back the logs go and which fields are retained. From a forensics standpoint, a record that does not appear is not the same as an event that never happened.

Step 1, put everything on one time zone. Convert platform audit logs, application logs, and provider billing timestamps to a single zone such as UTC, and mark the window where the charges started to spike.

Step 2, compare workloads with call patterns. When the bill jumps, check whether the team shipped a release, ran a batch job, or changed a scheduled script in the same period. Then compare the models being charged with the models the code uses. A service that normally calls only lightweight models suddenly hammering expensive flagship models at 3 a.m., or a provider still billing after the containers were shut down, points to someone outside.

Step 3, rule out cost spikes from internal code. An agent stuck in an infinite loop, aggressive retries after API timeouts, misconfigured concurrency, or a batch document-parsing job without rate limiting can burn through quota in minutes. Overlay job execution records on the provider's token consumption chart so an internal bug is not mistaken for an external breach.

Step 4, break the bill down by key or project and preserve evidence. Where the provider allows filtering usage by API key or project, filter down to the affected credentials. Where only an account-level summary exists, narrow it by release times and application logs. Once unauthorized usage is confirmed, export the abnormal time window, Project ID, Request ID, models called, token usage details, and the exact revocation time. A structured timeline moves a ticket forward far more effectively than reporting that the balance was drained. Redact business data from screenshots before submitting, and never attach full old or new keys in plain text.

Keep reviewing bills for the next two or three days. Some providers' usage dashboards lag final billing by several hours or a day or more, and for charges that show up later, check whether the underlying requests happened before or after the revocation. Whether a credit or refund is available for leak-caused charges depends entirely on each provider's risk policies and how they assess the incident, so plan on absorbing losses that already happened.

What I Changed So the Next Notice Is Cheaper

Split credentials by boundary

Development, testing, and production keys stay strictly isolated. Each microservice and each standalone agent gets its own project and key. Where the provider supports scoped keys, enable only the model endpoints the service needs and turn off fine-tuning, file upload, and organization management. Every key gets a named owner. Idle keys are revoked when a temporary project retires, console access is removed when people leave or change roles, and old containers get shut down after a migration so stale credentials stop piling up.

Put virtual keys in front of local projects

Moving debugging back to a laptop does not make credentials safe. Real OpenAI or Anthropic keys written in plain text into several .env files, or into the configs of different CLI tools, get committed when a .gitignore entry is missing, and get picked up by debug logs and cloud backups.

This is where ServBay, an AI development management tool, fits into my setup. Real provider keys stay inside its AI Gateway, and each project or tool, Claude Code, Codex, or an in-house script, gets a separate virtual key pointing at the gateway endpoint. Application configs hold only virtual keys, so the upstream credential never sits in a project directory or a terminal environment variable. A virtual key can be revoked on its own without touching the real key in the provider console, and usage and cost per project are visible on the gateway side.

A local gateway still needs its own boundary check. Run the full workflow with a disposable test credential, then search local log files, build output directories, and test deployment configs for spots where request headers get printed in plain text.

Know where spending controls stop

A budget number in a provider console reads like a guarantee and is not one. Different spending controls trigger in different ways and follow different billing rules, so a team can believe it has a limit it never actually had. Worth checking before the next incident rather than during it.

The Checklist I Keep in a Note

Four steps, in the order I run them

Cut off access first. On confirmed or strongly suspected exposure, revoke the old key in the provider console. Deleting the cloud environment variable or the local config file is not revocation.
Inventory every location. Trace the key through environment variables, Secret Groups, CI/CD pipelines, scheduled background jobs, and peripheral test containers. Generate the new key from a trusted device and restart every running instance.
Cross-check the bills. Put platform audit logs, application job records, and the provider console on one time zone, separate internal loops from external abuse, export request details for the abnormal window, and keep checking for delayed charges.
Isolate environments and real credentials. Separate keys for development, testing, and production, turn off unnecessary auto-recharge in the provider console, and for local development keep real keys behind virtual ones with per-project assignment, revocation, and separate usage tracking.

Leaked AI API keys after a cloud platform incident: blast radius, rotation, and bill forensics

ServBay — Fri, 06 Nov 2026 16:21:00 +0000

Leaked AI API keys after a cloud platform incident: blast radius, rotation, and bill forensics
A cloud platform security notice about AI API keys does not interrupt anything visible. Containers keep serving, model calls keep returning results, and the meter keeps running. The order of operations after such a notice matters more than the speed of any single step.

Revoke the old credentials in each model provider's console first. Then map where the key was deployed, which instances are still running with it, and what model access it grants. Rotate to new keys, and reconcile the platform's audit logs against provider bills for charges nobody on the team can explain.

Applications may keep responding normally and model APIs may return no errors. That is not evidence the credentials are safe. External model services bill by usage, so a key carried off the platform and used somewhere else still lands on your account.

The Northflank incident, in the order the notices were published

What Northflank runs, and why model keys end up there

Northflank is a Kubernetes-based platform as a service. Teams build and deploy microservices, managed databases, scheduled background jobs, and GPU workloads directly from a Git repository. It also offers a bring-your-own-cloud mode that connects the control plane to an AWS, Google Cloud, or Azure account, which removes the work of hand-writing Kubernetes configuration files.

Many teams run AI agents, backend API services, sandboxes, and automated data-processing scripts on that kind of platform. To reach model APIs such as OpenAI and Anthropic, those containers need credentials, and the usual storage spot is workload environment variables, Secret Groups, or global secrets. A large share of a company's model credentials sits in one place, so a platform-side security problem puts them at risk of exposure and abuse at the same time.

Three updates, three different asks

On October 31, 2026, Northflank said on its official status page that users had reported unauthorized use of AI API keys hosted on the platform, and that audit logs were available to all customers, including those on the free tier. The detailed sequence came in three steps.

Time (UTC)	What Northflank asked for
13:58, Oct 30	Treat all environment variables as if they had been decrypted, and disable or rotate keys
23:38, Oct 30	Users had reported unauthorized AI API key usage. Revoke credentials with the issuer, generate replacements, update the affected configuration and workloads, review usage and billing records with each provider, and report suspicious usage to the platform and the providers
01:04, Oct 31	Audit logs were now available to all customers

Later updates clarified two things. Rotation should cover credentials in workloads, Secret Groups, and global secrets, and any add-on with public access enabled should have it turned off.

What the notices do not establish

Two misreadings are common. Asking users to act as if their environment variables had leaked is a baseline precaution in incident response, meant to contain risk quickly. It does not confirm that every user's variables were stolen. Reports from some users that their keys were abused do not mean every customer on the platform saw unauthorized usage either.

The Hacker News discussion drew heavy attention and produced useful advice on checking credentials, along with speculation about the attack method and the platform's architecture. Community discussion is not evidence of how the breach happened. The official notice mentions similar attack activity, but the attacker's identity and the full intrusion path cannot be pinned down until the final investigation report is published.

For a development team, the urgent task is not reconstructing the intrusion. It is establishing where credentials are stored, which external services they reach, and whether the old ones are actually dead.

Mapping the blast radius of a leaked AI API key

The real blast radius depends on how many places a key is deployed today, not on what it was originally created for. A key meant for local testing gets copied into production. A demo project is retired, but its scheduled jobs keep running. Several agents share one key under the same provider account to skip setup. Update only the core production service and the peripheral environments stay exposed.

1. Inventory platform configuration, including the parts nobody maintains

Start with workload environment variables, Secret Groups, and global secrets, as the official guidance says. Then work through CI/CD build scripts, automated deployment pipelines, preview environments, and third-party webhook integrations to check whether any of them hardcodes or caches the same key.

2. Match the configuration to instances that are actually running

One environment variable can be inherited by several microservices, or copied by hand into different projects. Updating a frontend web service does not refresh a background queue worker or a cron job. Old containers that nobody owns but that still run belong on the list too.

3. Keep the tracking sheet redacted

Record each key's name, the key prefix or ID the provider shows, the project it belongs to, where it is stored, which services use it, and its current status. Never paste a full key in plain text into the sheet, team chat, or a ticket. That creates a fresh leak inside your own collaboration tools.

4. Check what the key can do at the provider

Once the usage map is clear, log in to each provider console and confirm which organization and project the key belongs to. Look at which model endpoints it can call, and whether it can read or write fine-tuning data or upload files. Permission granularity varies widely between providers. An API key is not necessarily limited to text generation, and it is not necessarily an account-wide admin credential either.

5. Clean up the other credentials in the same environment

Do not stop at model APIs. If the affected runtime also holds database connection strings, object storage keys such as AWS S3 or Google Cloud Storage, or payment API tokens, rotate those as well, following the official security guidance.

Rotating keys so the old ones actually stop working

The most common mistake in a rotation is updating application configuration and forgetting to revoke the old credential with the issuer.

Deleting an environment variable from a cloud platform removes a string from that platform's database. If an attacker already copied the key to an outside server, whether it still works depends entirely on the provider's revocation state. Deleting a local .env file or scrubbing old code from Git history does the same amount of nothing against a key that has already been exfiltrated.

A rotation that closes the loop has four moves.

Revoke at the issuer

Log in to the provider's official console, find the key you suspect, revoke or delete it, and confirm its status shows it is no longer active. If suspicious calls are arriving in real time, cut the old credential immediately to cap the charges, while weighing the impact of a short service interruption and preparing a recovery plan.

Generate the replacement from a trusted device

Confirm the machine you are working on is secure and reach the console through the provider's official domain. Check the account's team member list and role permissions for unfamiliar changes. Generate the new key under the principle of least privilege. If the cloud platform has not finished isolating, remediating, or migrating, hold the new production key back from the high-risk environment to avoid a second exposure.

Redeploy, because running processes keep the old value

Many backend services and long-lived processes read environment variables once, at container start. Saving a new value in a web console does not touch the process already in memory, which keeps sending requests with the old key. Restart or redeploy before assuming the change is live.

Verify in both directions

At the end of the rotation, confirm two facts. The old key is rejected by the provider. The services make successful model calls with the new key. Do not print the new key into application logs, and do not paste a curl command containing the full key onto a shared server where shell history captures it.

Keep watching for a while afterwards. Occasional 401 Unauthorized errors in the logs point to an instance or scheduled job that never picked up the new configuration. Unexplained usage on the bill sends you back to the account for backup keys you have not dealt with yet.

Reconciling platform audit logs against provider bills

Audit logs open to all customers give a starting point for reviewing activity inside the platform. During reconciliation, platform logs and provider logs verify different things, so they have to be combined and cross-checked.

A key exfiltrated and used from a machine outside the platform leaves no trace in the original application's service logs. An audit log with nothing unusual does not rule out abuse. Before relying on it, confirm how far back the log retention goes and which fields are kept. From a forensics standpoint, an event missing from the logs is not the same as an event that never happened.

Step 1. Put every log on one time zone

Convert platform audit logs, application-internal logs, and provider billing timestamps to a single time zone such as UTC, and mark the window where unusual charges started climbing.

Step 2. Compare workload history with call patterns

When the bill spikes, check first whether the team shipped a release, ran a batch data-processing job, or changed a scheduled script in the same period. Then check whether the models billed in the provider console match the ones the code calls. A service that normally uses lightweight models and suddenly bursts on expensive flagship models at 3 a.m., or a provider that keeps billing after the application containers were shut down, points to someone outside using the key.

Step 3. Rule out your own code

A jump in charges is not proof of theft on its own. An agent stuck in an infinite loop, aggressive retries after API timeouts, misconfigured concurrency, or a batch document-parsing job without rate limiting can burn a quota in minutes. Overlay job execution records on the provider's token consumption chart so an internal bug is not mistaken for an external breach.

Step 4. Break the bill down by key and preserve evidence

If the provider lets you filter usage by individual API key or project, filter down to the affected credentials. If the console only gives an account-level summary, narrow it by elimination using release times and application logs. After confirming unauthorized usage, capture the abnormal window, Project ID, Request ID, models called, token usage, and the exact time the old key was revoked. A structured timeline moves a ticket forward far more effectively than a complaint about a drained balance. Redact business data from screenshots before submitting anything, and never attach old or new keys in plain text.

Watch for delayed charges after the rotation

Keep reviewing bills for the next two or three days. Some provider dashboards lag behind final billing by several hours or a day or more. For later charges, check whether the underlying requests landed before or after revocation. Whether a leak-related charge can be credited depends on each provider's risk policies and how they assess the incident, so budget for absorbing what has already happened.

Once the immediate response is closed, one engineering question remains. Why did a single leaked key reach so many services?

Early in a project, pointing local development, integration testing, demos, and production at one API key saves configuration work. It also leaves the team exposed. Revoke that shared key and production goes down together with testing. Keep it alive to protect production and the suspicious traffic keeps draining the balance. With every environment billed to one line, tracing the source afterwards becomes nearly impossible.

Reducing the blast radius of the next incident

Split credentials by service boundary and environment

Keep development, testing, and production credentials strictly separate. Each microservice and each standalone agent gets its own project and key. Where the provider supports scoped keys, enable only the endpoints the service uses and turn off fine-tuning, file upload, or organization management permissions it does not need. Assign an owner to each key. Revoke idle keys when temporary projects retire, remove console access when people leave or change roles, and shut down old containers after a migration so stale credentials stop accumulating in code and configuration.

Virtual keys for local projects and CLI tools

After a platform incident, many developers move debugging back to their own machines or set up several AI coding tools and agents on one laptop. Running code locally does not make credentials safe. Real keys written in plain text into several .env files or into different CLI configs get committed when a .gitignore entry is missing, or picked up by debug logs and cloud backups.

ServBay, an AI development management tool, handles this with virtual keys in its AI Gateway. The real API keys for each provider stay encrypted inside the gateway, and the team issues separate virtual keys for each project or tool, such as Claude Code, Codex, or an in-house script. A switcher tool decides which provider you point at. A gateway decides how the traffic moves and which credential each project holds.

Three things follow from that split.

Real keys stop spreading. Project configs and third-party tools hold only virtual keys that point at the gateway endpoint, so provider keys never appear in project directories or terminal environment variables.
Access and rate limits get granular. Each virtual key can be restricted to specific model channels, given an expiration time, and capped with per-minute or per-day request and token limits (RPM/TPM/RPD/TPD).
Rotation happens independently. A test project whose config may have leaked can have its virtual key revoked or reset in the gateway, without touching the real credentials at the upstream provider. Per-project usage and spending are visible on the gateway side.

A local gateway still needs its environment checked. Run the full workflow with a disposable test credential you are willing to throw away, then search local log files, build output directories, and test deployment configs for spots that print request headers in plain text. Production keys stay out of that exercise.

Know where provider spending controls stop

A budget line in a provider console is not blanket coverage. Spending controls trigger in different ways and follow different billing rules, and knowing which one a team actually relies on belongs in the post-incident review. Unnecessary auto-recharge is worth turning off at the same time.

A short checklist

Four steps that close the loop

Cut access first. Once a credential is confirmed or strongly suspected exposed, revoke it in the provider's official console. Deleting a cloud environment variable or a local config file is not revocation.
Inventory every location. Follow the key through environment variables, Secret Groups, CI/CD pipelines, scheduled jobs, and leftover test containers. Generate the replacement from a trusted device, then restart every running instance so the change takes effect.
Cross-check the bills. Put platform audit logs, application job records, and the provider console on one time zone, separate internal loops from external abuse, export request details for the abnormal window, and keep checking for delayed charges.
Isolate environments and real credentials. Separate development, testing, and production keys, and turn off unnecessary auto-recharge. For local work, the virtual key feature in ServBay AI Gateway keeps real keys inside the gateway, with per-project access control, rate limiting, and separate usage tracking.

The root cause of a platform breach can take weeks to establish. Credential cleanup and bill reconciliation cannot wait for that report.

Copilot Fusion's Local Model Preview: Only One of Three Stages Runs on Your Machine

ServBay — Mon, 02 Nov 2026 16:28:07 +0000

GitHub shipped an experimental preview on October 28, 2026 that lets Copilot Fusion add eligible local models to its smart routing, splitting tasks between local and cloud models. I went through the announcement expecting the other half of the story to be an offline coding agent. It is not. GitHub says plainly that routing decisions are still made in the cloud.

Copilot Fusion is the model routing and task coordination layer inside GitHub Copilot. It looks at a request and the models available, picks one, and feeds that model's output back into the coding workflow. It answers which model handles a task. It does not move the workflow onto your hardware.

A model running on your machine and a coding task that survives a pulled network cable are two different claims. The first one is confirmed. The second depends on your specific setup. Three questions separate them. Who chooses the model. Which model runs the inference. What the tools touch when they execute. Once those three are untangled, it becomes possible to say which steps keep working offline, what code data may leave the machine, and whether adding a local model actually lowers development cost.

The Local Model Support Is Real, the Offline Agent Is Not

A reachable endpoint is not a routing decision

The update lands in Copilot CLI first. On Windows, macOS and Linux, Copilot CLI supports configuring local models. You prepare the model files and the inference runtime yourself, then connect through a local OpenAI-compatible endpoint. After that, experimental local routing has to be turned on in settings and Standard mode selected in Copilot Fusion. Only then do eligible local models get considered for automatic assignment.

Three things get conflated at this point. A local service that answers means the network endpoint works. A model Copilot can discover means it shows up in the config file or the model list. Whether it ends up in Fusion's automatic routing depends on the product surface, the model allowlist (GitHub names MAI Code 1.1 Flash and Qwen3.8 Flash Next), and feature access on your account. Exposing an OpenAI-compatible endpoint does not mean Fusion will call that model automatically.

The desktop app follows a different set of rules

The Copilot app connects to and manually selects compatible local models through bring-your-own-key (BYOK). Smart routing there currently only supports models hosted by Windows ML. Being able to pick a local model by hand in the desktop app does not mean Fusion will choose it during automatic routing.

Dimension	Copilot CLI	Copilot app (desktop)
OS support	Windows, macOS, Linux	Depends on the desktop OS version and settings
How local models connect	Developers deploy the model and an OpenAI-compatible service themselves	Connect compatible models directly via BYOK
Fusion auto-routing requirements	Turn on experimental local routing, choose Standard mode, and use an officially eligible model	Smart routing currently only supports models hosted by Windows ML
Limits	A working endpoint is not automatic routing	Manually selectable is not automatic routing

Both clients sit on an experimental preview. Before depending on this for real work, check client version, subscription tier, operating system, region, and the current support list in the official docs.

A Coding Task Has Three Stages and Only One Is Local

Take a normal request. Change the date-formatting function in the project, add unit tests, run the test command. The UI shows one input box, but behind it the request loops through routing, inference and tool execution several times.

Routing picks the model

Copilot Fusion weighs eligible local models against cloud models using its own evaluation logic. This update adds local models to the candidate pool. It does not move the router onto your computer. GitHub has confirmed that routing decisions are still made on its cloud servers.

Inference generates the code and the answer

If cloud routing sends the request to a local model, code generation runs on your hardware. If it goes to a cloud model, the compute happens in the cloud. Local inference tells you where the model computes. It does not tell you the whole interaction stays on your machine.

Tool execution changes the project

Reading local files, writing code changes, launching a terminal to run tests. All of that depends on specific tools. The model suggesting "run the tests" in text and the system actually launching the test command are two separate actions. When tools run, they may only read and write local files. They may also connect to a remote repository, pull third-party packages, or call external network APIs.

The real path of an AI coding task is cloud routing picks a model, a local or cloud model does the inference, and tools carry out the changes. This is where most evaluations of local AI coding tools go wrong. Where the model runs only tells you where inference happens. Who picks the model and what the tools reach have to be checked separately.

Where the Network Dependency Actually Sits

Whether a task keeps going offline depends on how you use the local model. Three paths behave differently.

Direct endpoint, manual pick, automatic routing

If you skip the client and send requests straight to the local inference service, you can check whether that service handles input without internet access. That only proves the underlying model service runs offline. If you manually choose a local model in the Copilot client, watch whether account authentication, session state and other supporting services need the network. If you rely on Copilot Fusion's automatic routing, cloud routing is a gate you cannot route around. GitHub has confirmed that even when a local model handles inference, the Fusion session does not become fully offline.

Four behaviours worth testing before concluding anything

Whether requests already in flight when the connection drops can finish.
Whether the terminal returns a clear error code or triggers a fallback when the cloud routing request fails.
Whether the local toolchain can continue unfinished steps while the local inference service is still alive.
Whether an interrupted task resumes where it stopped once the network is back, or has to start over.

Every one of these depends on client version, configuration, task complexity and tool dependencies. Testing beats guessing here.

A three-state comparison on a throwaway project

Set up a small isolated project with made-up data and a fixed prompt, then run the same instruction through three states.

Internet connected, local inference service on.
Internet connected, local inference service manually turned off.
Internet physically disconnected, local inference service kept on.

Where the errors show up across those three runs tells you whether the network dependency sits in routing, inference or tool execution. Keep "local service off" and "internet off" separate. The first tests how the client handles a missing local inference service. The second tests how much cloud routing and supporting tools depend on the network.

Privacy and Cost Are Two Separate Audits

What the routing request actually carries

Many teams adopt local models for compliance and privacy reasons. The privacy boundary is not about whether model weights sit on your disk. A complete coding task involves prompts, project context, code file contents, tool output and diagnostic logs. Check item by item which fields get packed into cloud routing requests, which content is handled purely by the local model, and which telemetry gets written to cloud logs.

What is confirmed is that Copilot Fusion makes routing decisions in the cloud. GitHub's announcement has not fully disclosed the payload of each routing request, so neither claim holds up. Teams cannot say full code is definitely uploaded, and they cannot assume the cloud only receives metadata with no code. The tool execution stage sends data out too, through dependency installs, external APIs used in testing, and reads or writes against remote Git repositories. For projects with strict confidentiality requirements, do not treat a local model as a complete privacy shield until three things are confirmed. What input goes to the cloud. What the routing logs keep. Whether tools reach external services.

Three line items in the bill

Adding local compute does not cut cost in a straight line. A team's total cost has at least three parts. The base Copilot subscription. The cloud model quota consumed. The hardware depreciation, VRAM usage and maintenance effort of running a large model locally.

If a local model takes a task, whether it still counts against some Copilot chat quota depends on GitHub's actual billing rules. If a task gets switched back to a cloud model midway through a multi-turn conversation, those cloud calls need checking too. Local model efficiency is also not just raw generation speed. Cold-start model loading, long-context prefill, tool call time and rework from bad code changes all stretch out delivery time.

Without same-condition tests and billing records, track end-to-end metrics per task from start to delivery. Time to first response, code change accuracy, unit test pass rate, number of model switches, cloud quota used, and how often a human had to step in. That is the only way to measure real return on investment.

Running the Boundary Test on an Isolated Setup

Where ServBay fits in the workflow

ServBay, a one-stop AI development management tool, is what I would put underneath this kind of test. It stands up the local endpoint, the model runtime and an isolated test project before Copilot CLI ever points at them, and it keeps those pieces separate from the editor and the client. Building on that, the test results can turn into a local agent data-flow checklist recording model status, routing responses, tool calls and network errors.

The five checkpoints

No real business repository is needed. Create a small project with only made-up data, and lock down the Copilot CLI version, the local model (MAI Code 1.1 Flash or Qwen3.8 Flash Next, for example) and the inference service configuration. Then give the AI a standard instruction. Change the project's date-handling function, add unit tests, run the test command automatically.

During testing, switch between the online and offline states and record five checkpoints. Whether the local model server logs the request. Whether cloud routing lets it through. Whether tools can read and write local files. Whether the test script actually launches. And at which stage the error shows up.

Never use real API keys, private business code or production data during testing. Scrub account tokens and local absolute paths before publishing any test logs or screenshots.

How I'd Judge Any Tool Claiming Local Model Support

This Copilot Fusion update officially brings local models into smart routing, and the technical change is clear. Copilot CLI can configure local models and connect compatible services on major operating systems. The Copilot app can connect to and select some local models. The limits are just as clear. Routing decisions stay in the cloud, local inference does not turn a coding session into an offline agent, and a model discovered through BYOK is not automatically eligible for routing.

When evaluating any AI coding tool that advertises local model support, do not stop at whether the weights run on your computer. Follow the task chain and track who picks the model behind the scenes, which steps need the network, what the tools reach in the background, and how quotas and costs get counted. Run the whole chain once in an isolated environment and the relationship between local inference, cloud routing and tool execution stops being a matter of assumption.

Copilot Fusion Takes Local Models, and the Offline Boundary Is Somewhere Else

ServBay — Mon, 02 Nov 2026 16:27:56 +0000

GitHub published an experimental preview on October 28, 2026 that lets Copilot Fusion add eligible local models to its smart routing and split tasks between local and cloud models. The same announcement states that routing decisions are still made in the cloud. A model running on a developer's machine and a coding session that needs no network at all are two separate things. The first is confirmed. The second has to be checked against a specific setup.

Copilot Fusion is GitHub Copilot's model routing and task coordination layer. Based on the request and the models available, it picks a model and feeds that model's output into the rest of the coding workflow. It answers which model handles a task. It does not move the whole workflow onto local hardware.

For anyone evaluating this feature, three questions carry the weight. Who chooses the model, which model performs inference, and what resources the tools touch while they run. Keep those three apart and the offline boundary, the data exposure and the real cost all become measurable.

What Copilot Fusion Changes and What It Leaves Alone

Routing remains a cloud-side decision

The update adds local models to the candidate pool. It does not relocate the router. GitHub has confirmed that routing decisions continue to run on its cloud servers, so the selection step stays a network dependency no matter which model ends up generating code.

Local support differs between the CLI and the desktop app

The update lands first in Copilot CLI. On Windows, macOS and Linux, Copilot CLI supports configuring local models. Developers prepare the model files and an inference runtime themselves, then connect through a local OpenAI-compatible endpoint. After that they turn on experimental local routing in settings and choose Standard mode in Copilot Fusion. Only then can an eligible local model be considered for automatic assignment.

The Copilot desktop app works differently. It supports connecting to and manually picking compatible local models through bring-your-own-key (BYOK), but smart routing currently only supports models hosted by Windows ML. A local model that can be picked by hand in the desktop app is not automatically a model that Fusion will choose during routing.

Dimension	Copilot CLI	Copilot app (desktop)
OS support	Windows, macOS, Linux	Depends on the desktop OS version and settings
How local models connect	Developers deploy the model and an OpenAI-compatible service themselves	Connect compatible models directly via BYOK
Fusion auto-routing requirements	Turn on experimental local routing, choose Standard mode, and use an officially eligible model	Smart routing currently only supports models hosted by Windows ML
Limits	A working endpoint is not automatic routing	Manually selectable is not automatic routing

The feature is still an experimental preview. Before depending on it for production work, check the client version, subscription tier, operating system, region and the latest support list in the official documentation.

Why a Reachable Endpoint Is Not Automatic Routing

Three states that get confused

A reachable local service only proves the network endpoint responds. A model Copilot can discover only proves it appears in the config file or the model list. Whether it reaches Copilot Fusion's automatic routing depends on the product surface, the model allowlist and the feature access attached to the account. GitHub names MAI Code 1.1 Flash and Qwen3.8 Flash Next as eligible examples. Exposing an OpenAI-compatible endpoint is not the same as Fusion calling that model on its own.

What to check before assuming anything

Confirm the routing mode actually selected in settings, confirm that the model appears on the official eligibility list rather than only in a local config, and confirm that the account and region have access to the preview. When any of the three is missing, the request stays on cloud models even though a local service is running and healthy.

Following a Single Task Through Three Stages

Take a request that asks the AI to change a date-formatting function, add unit tests and run the test command. The interface shows one input box. Behind it, the request loops through routing, inference and tool execution repeatedly.

Cloud routing selects the model

Copilot Fusion weighs eligible local models against cloud models using its own evaluation logic. This update enlarges the candidate pool on the local side. The router itself stays in GitHub's cloud.

Model inference produces the code

If routing sends the request to a local model, code generation runs on local hardware. If it goes to a cloud model, the compute happens in the cloud. Local inference tells you where the model computes. It says nothing about where the rest of the interaction happens.

Tool execution changes the project

Reading local files, writing code changes and launching a terminal to run tests all depend on specific tools. A model that suggests running the tests in plain text and a system that actually launches the test command are two different actions. Tools may only read and write local files, or they may reach a remote repository, pull third-party packages or call external network APIs.

The real path of an AI coding task therefore runs from cloud routing to local or cloud inference to tool execution. Most confusion about local AI coding tools starts here. Where the model runs only describes the inference stage. Who picks the model and what the tools reach have to be checked separately.

Where a Task Stops When the Connection Drops

Three ways to invoke a local model

If requests go straight to the local inference service without the client, you can check whether that service handles input without internet access. That only proves the underlying model service runs offline. If a local model is chosen manually inside the Copilot client, account authentication, session state and other supporting services still need checking. If Copilot Fusion's automatic routing is in play, cloud routing is a gate that cannot be routed around. GitHub has confirmed that even with a local model handling inference, the Fusion session does not become fully offline.

A three-run test matrix

Build a small isolated project with made-up data, fix the prompt and run the same flow three times.

Internet connected, local inference service running.
Internet connected, local inference service manually stopped.
Internet physically disconnected, local inference service kept running.

Comparing where errors surface across the three runs shows whether the network dependency sits in routing, inference or tool execution. Keep the second and third runs separate. The second mainly tests how the client behaves when the local inference service is missing. The third tests how much cloud routing and the supporting tools depend on the network.

Five checkpoints to record

Whether the local model server logs the request, whether cloud routing lets it through, whether tools can read and write local files, whether the test script actually launches, and at which stage the error appears. Until targeted tests are done, leave room for verification on a few concrete behaviors rather than drawing conclusions. Whether in-flight requests finish after the connection drops, whether the terminal returns a clear error code or triggers a fallback when the cloud routing request fails, whether the local toolchain continues unfinished steps while the local inference service stays alive, and whether an interrupted task resumes after reconnection or restarts from zero. All of these depend on client version, configuration, task complexity and tool dependencies.

Code Privacy and Cost Are Separate Questions

What may leave the machine

Many teams adopt local models for compliance and privacy. The privacy boundary is not only about where the model weights sit. A complete coding task involves prompts, project context, code file contents, tool output and diagnostic logs. Each field needs checking against what gets packed into cloud routing requests, what stays with the local model and what telemetry reaches cloud logs.

What is known is that Copilot Fusion makes routing decisions in the cloud. GitHub's announcement has not fully disclosed the payload of each routing request, so a team can neither claim that full code is definitely uploaded nor assume the cloud receives only metadata. Tool execution adds its own outbound traffic through dependency installation, external API calls for testing, and reads and writes against remote Git repositories. For projects with strict confidentiality requirements, a local model is not a privacy shield until three things are confirmed. What input goes to the cloud, what the routing logs retain, and whether tools reach external services.

Adding up the total cost

Local compute does not cut costs in a straight line. A team's total has at least three parts. The base Copilot subscription, the cloud model quota consumed, and the hardware depreciation, VRAM usage and maintenance effort of running a large model locally. If a local model takes a task, whether it still counts against a Copilot chat quota depends on GitHub's billing rules. If a multi-turn conversation switches back to a cloud model midway, those cloud calls need their own accounting.

Local model efficiency is not only raw generation speed either. Cold-start model loading, long-context prefill, tool call time and rework caused by bad code changes all extend the time to a finished task. Without same-condition tests and billing records, track end-to-end metrics per task. Time to first response, code change accuracy, unit test pass rate, number of model switches, cloud quota used, and how often a human had to step in.

Running the Boundary Test with an Isolated Project and ServBay

Set up the sandbox

No real business repository is needed. Create a small project containing only fictional data, then lock three variables in place. The Copilot CLI version, the local model (MAI Code 1.1 Flash or Qwen3.8 Flash Next), and the inference service configuration. Give the AI one standard instruction. Change the project's date-handling function, add unit tests and run the test command automatically.

Record the five checkpoints during both the online and offline states. Never use real API keys, private business code or production data during testing, and scrub account tokens and local absolute paths before publishing any log or screenshot.

Where ServBay fits

ServBay is an AI development management tool that can host the environment side of this test. Its AI Gateway puts every model and key behind one endpoint, accepting official provider APIs, subscription accounts and third-party relay services, and it converts between the OpenAI, Anthropic and Gemini protocols so a client speaking one protocol can reach a model that speaks another. Ollama models run through the same endpoint.

Two details matter for the verification work above. Virtual keys are issued per project while the real upstream keys stay encrypted locally and are never uploaded, which keeps test credentials away from the actual production keys. Usage and cost are tracked per project in real time, so the quota and cost numbers collected during the three runs have a place to land next to the model status, routing response, tool call and network error records.

A switcher answers which provider to use. A gateway answers how traffic moves. That distinction is what separates a routing layer from an access layer, and it is worth keeping in mind when a vendor describes either one.

How to Evaluate Any Tool That Claims Local Model Support

This Copilot Fusion update brings local models into smart routing in an official capacity. The technical change is specific. Copilot CLI can configure local models and connect compatible services across major operating systems, and the desktop app can connect to and select some local models. The limits are just as specific. Routing decisions stay in the cloud, local inference does not turn a coding session into an offline agent, and a model discovered through BYOK is not automatically eligible for routing.

When assessing any AI coding tool that advertises local model support, the question is not whether the weights run on a local disk. Follow the task chain instead. Who chooses the model, which steps require the network, what the tools touch in the background, and how quota and cost are counted. Run the chain once in an isolated environment and the relationship between local inference, cloud routing and tool execution stops being a marketing claim.

Half the Token Price, 13 the Bill: How I Measure Model Cost Per Accepted Task

ServBay — Thu, 29 Oct 2026 14:58:36 +0000

I Started With the Price, Then Did the Arithmetic

OpenAI cut the headline rate again. GPT-6.1 Terra's standard API price is $1 per million input tokens and $5 per million output tokens, about 50% lower than the previous generation.

My first reaction was the same as most people's. If the list price halves, does fixing a bug cost half as much?

No. A cheaper unit price does not make a cheaper completed task. I now compare models on cost per accepted task, which is model spend plus human cleanup, divided by the number of tasks that pass acceptance. A cheap model with a low pass rate and a lot of retries can still cost more overall. This post walks through the arithmetic I use and the numbers OpenAI published at launch.

What Terra Is

GPT-6.1 Terra is OpenAI's fast, efficient model. OpenAI positions it as a new balance of speed, capability, and cost. The announcement's typical scenario is high-volume automation, such as reading incoming invoices and entering details into accounting software.

What It Costs

The API model name is gpt-6.1-terra.

Item	Price
Input	$1 per million tokens
Cached input	$0.05 per million tokens
Output	$5 per million tokens

That standard API price is 50% lower than GPT-5.6 Terra and GPT-6.1 Sol.

Plus, Pro, Enterprise, and Edu users can use it in ChatGPT Work and Codex. Developers can call it through the OpenAI API. OpenAI also notes that with the same usage quota in ChatGPT Work and Codex, you can finish more tasks than with GPT-5.6 Terra.

The Benchmark Numbers, and What They Leave Out

Everything below is from OpenAI's published benchmarks.

Computer Use

On Agents' Last Exam at medium reasoning effort, scores are about 15 percentage points higher than GPT-5.6 Terra at roughly one-third the cost. On OSWorld 2.1, medium reasoning already beats GPT-5.6 Terra's best result.

Visual Reasoning

On MMMU-Pro, it beats GPT-5.6 Terra at every reasoning setting.

Factual Accuracy

On OpenAI's internal test built from prompts that tend to trigger errors, the error rate at low reasoning effort fell from 53.6% to 16.7%, and to 4.3% at maximum reasoning effort.

Software Engineering

On Terminal-Bench 4.0, the command-line coding benchmark, it solved 50.3% of tasks at maximum reasoning effort. GPT-5.6 Terra's published score was 21.5%.

Speed

Task completion is more than 3× faster than GPT-6 Astra and GPT-6.1 Sol.

The Boundary OpenAI Draws

OpenAI states that for the most complex coding work, GPT-6.1 Sol and GPT-6 Astra remain better choices. That sentence matters more than the leaderboard lines, because it sets the task-selection rule I use further down.

Safety Notes

OpenAI says Terra's cybersecurity capability reaches the Critical risk level in its Preparedness Framework, and it keeps the protections built for GPT-6 Astra. In alignment evaluations, Terra is more likely than GPT-5.6 Terra to stay within the task scope and to state its own limits accurately. In prompt-injection tests it also shows strong resistance to malicious instructions. Details are in the official system card.

The "One-Tenth" Claim Compares Two Different Things

The most common claim in circulation is one-tenth. The announcement has two nearby statements with different comparison targets.

The Astra Comparison

On Agents' Last Exam, Terra's performance is comparable to GPT-6 Astra while each token costs about one-tenth as much. That compares token unit price, against Astra, on computer-use tasks.

The Opus 5.5 Comparison

At maximum reasoning effort, Terra's token efficiency is more than 3× Claude Opus 5.5's, and each token costs about one-fourth as much, so cost per task is roughly one-ninth.

Neither claim says fixing one bug costs one-tenth as much. The second one already uses a per-task framing, and OpenAI itself does not equate unit price with total cost.

Three Costs the Price Per Million Hides

Comparing price per million tokens alone misses three things.

A Task Is Rarely One Attempt

If the first fix fails tests, the retry carries the error log with it. Every extra round bills input and output again.

Failed Attempts Still Bill

A wrong patch still spends tokens. That spend is not refunded.

Failures Need Human Cleanup

Fifteen minutes of engineer time debugging a bad model change can cost more than dozens of API calls.

So a low unit price is a necessary condition, not a sufficient one. A cheaper model with a clearly lower pass rate can still cost more overall. When pass rates are similar, the low unit price turns into real savings.

About the One-Dollar Demo Stories

Some public discussions use a single case to argue the cheaper model is the better deal, for example finishing a small game in a few minutes for a dollar or two. Those stories are vivid. Without a shared acceptance bar, and without saying whether the deliverable passed tests or needed rework, they are hard to convert into cost per accepted task. Case studies retold here were not independently verified, so I treat them as background only.

What Is Actually on the Bill

At the official rates, one call's cost is the sum of three parts.

Input and Cached Input

Input covers code files, error logs, and the prompt, billed at $1 per million tokens. Cached input is context that repeats across retries, billed at $0.05 per million tokens, one-twentieth of ordinary input.

Output

Output covers patches, explanations, and reasoning tokens, billed at $5 per million tokens, 5× the input unit price. Raising reasoning effort increases per-call cost as output grows.

Why Cache Matters Most on Retries

Code and prior context show up round after round. When cache hits, the marginal cost of another round drops sharply. Whether cache hits depends on prefix consistency and other conditions. The exact rules and TTL follow OpenAI's docs. When designing prompts, I put stable project notes and file contents first and this round's error text last, so cache is more likely to hit.

Five Steps from Unit Price to a Comparable Number

Step 1 to Step 4

Unit price. Look up official rates for input, cached input, and output.
Attempts. Record how many rounds each task took and how many tokens each round used.
Acceptance. Write the pass criteria up front. Named tests all pass, no regression on existing tests, no editing test files to force a pass.
Human cleanup. Record minutes of human intervention after model failure, converted at a single hourly rate.

Step 5 and the Formula

Cost per accepted task = (total model spend + human cleanup cost) / number of accepted tasks

Accepted here includes tasks that passed only after human cleanup. Otherwise the formula hides the cost of failure. To judge the model alone, also track the share that passed with no human help.

Worked Example: Half the Unit Price, 13× the Bill

This is a calculation example. All parameters are assumed. They do not represent real pass rates for Terra or any other model.

Assumptions

Each attempt uses 10,000 uncached input tokens, 30,000 cached input tokens, and 8,000 output tokens.
At most 3 attempts per task, stopping on success.
If all 3 fail, human cleanup takes 15 minutes at $60/hour, which is $15.
Model A uses Terra rates with a 40% per-attempt pass probability.
Model B costs 2× Terra's unit price with an 80% per-attempt pass probability.
At Terra rates, one attempt costs $0.01 input + $0.0015 cached + $0.04 output = $0.0515.

The Code

def cost_per_accepted_task(p, price_mult, cap=3, manual_fix=15.0):
    # Per-attempt cost (USD) at the example Terra standard rates
    per_attempt = (10_000 * 1 + 30_000 * 0.05 + 8_000 * 5) / 1_000_000 * price_mult
    fail_all = (1 - p) ** cap                                   # probability all attempts fail
    expected_attempts = sum((1 - p) ** i for i in range(cap))   # expected number of attempts
    model_cost = expected_attempts * per_attempt
    manual_cost = fail_all * manual_fix                         # expected human cleanup after total failure
    return per_attempt, expected_attempts, fail_all, model_cost, manual_cost, model_cost + manual_cost

print(cost_per_accepted_task(0.4, 1))  # Model A: Terra rates
print(cost_per_accepted_task(0.8, 2))  # Model B: 2× unit price

Results

Item	Model A (1× price, 40% pass)	Model B (2× price, 80% pass)
Cost per attempt	$0.0515	$0.103
Expected attempts	1.96	1.24
Model spend	$0.101	$0.128
Probability all fail	21.6%	0.8%
Expected human cleanup	$3.24	$0.12
Cost per accepted task	~$3.34	~$0.25

Reading the Table

Under these assumptions, Model A at half the unit price has about 13× Model B's total cost, and human cleanup dominates. Looking only at model spend, A is $0.101 per task and B is $0.128, so A is slightly cheaper. That single column is where a lot of the price debate stops.

The reverse also holds. If A's pass rate rises toward B's, human cleanup shrinks quickly and the price edge shows up. The hinge is not unit price. It is pass rate, plus how much human time a failure costs.

Running This on My Own Repo

Task Choice

Pick a stably reproducible bug with a failing test, a public repo, and a fixed commit. Medium difficulty works best, meaning not one-shot solvable and not hopeless.

Acceptance

Named tests all pass, no regression on existing tests, no editing test files to force a pass.

Controls

Same prompt, same code snapshot, same retry cap. Keep billing channels consistent, and do not mix API numbers with subscription quotas. Run each model several times, because a single run is noisy.

Fields to Record

Log the same fields each attempt and take token counts from the API usage fields, not from estimates. The table above is the shape I keep.

Where Terra Fits in My Task Split

OpenAI also says the most complex coding work still favors GPT-6.1 Sol or GPT-6 Astra. Combined with the ledger above, a rough split is a reasonable starting point, corrected later with your own data.

Start With Terra

Scoped fixes with test coverage are a good place to try Terra first. Pass rates are usually higher, retries fewer, and the low unit price shows up more clearly. High-volume, repetitive jobs also fit, because at scale the unit-price gap gets amplified.

Start With a Stronger Model

Cross-module refactors or tangled dependency changes are better evaluated on a stronger model first. When those fail, human cleanup is expensive, and the money saved on a single call will not cover it.

Fix the Tests First

If requirements are fuzzy and tests are missing, add tests before picking a model. Without acceptance criteria there is no way to compute cost per accepted task, and any model choice is a gut call.

Fixing the Acceptance Environment

When comparing cost, environment drift muddies results. The same bug can behave differently across language or database versions. A model's first failure might be bad code, or it might be mismatched dependencies. Those two failures should not sit in the same ledger.

Pinning the Runtime

ServBay, an AI development management tool I use for this, can pin PHP, Node.js, Python, and other runtimes on the same machine, along with database and site config. Once the acceptance environment is fixed, every model attempt runs under the same conditions, so attempt counts and pass rates become comparable.

One Endpoint for Model Calls

The ServBay AI Gateway also works as a single entry point. Calls go out with virtual keys while the real upstream keys stay encrypted and isolated from the project configs, and virtual keys can be revoked. Usage, cost, and latency roll up in one place, and Claude Code, Codex, and similar tools can point at the same endpoint. OpenAI, Anthropic, and Gemini compatible paths are available.

FAQ

Does a lower model unit price always save money?

Not necessarily. Unit price is only one part of total cost. With low pass rates, many retries, and heavy human cleanup, a cheap model can still cost more. The right metric is cost per accepted task.

How do you compute cost per accepted task?

Add total model spend to human cleanup cost, then divide by the number of accepted tasks. Model spend must include both successful and failed attempts.

What is GPT-6.1 Terra's API price?

Per the launch announcement, standard API pricing is $1 per million input tokens, $0.05 per million cached input tokens, and $5 per million output tokens. Prices can change, so use OpenAI's official pricing page.

Is Terra a fit for complex coding tasks?

On Terminal-Bench 4.0 at maximum reasoning effort, Terra solved 50.3% of tasks, a clear jump over the previous generation. OpenAI also says the most complex coding work is still a better fit for GPT-6.1 Sol and GPT-6 Astra.

Can cache hits distort a cost comparison?

Yes. Tasks with high cache hit rates cost less than estimates that assume ordinary input prices. In comparison runs, record each model's cached token counts and keep prompt structure consistent.

Is Copilot billed the same as the API?

No. The launch announcement does not spell out Copilot billing, so check GitHub's official billing docs. Do not apply API token unit prices directly.

What I Am Changing

Terra pushes price, speed, and coding ability forward together, and OpenAI's numbers make that clear. Those numbers come from specific benchmarks. Whether a given codebase gets cheaper still depends on its acceptance criteria.

The comparison is shifting away from leaderboard scores and toward how much money and time one finished task takes, and whether delivery stays reliable. The practical move is small. Take one reproducible bug, log tokens and human minutes per attempt, compute cost per accepted task, and then pick the model. Most of that judgment does not need a model to make it.

Why GPT-6.1 Terra's half-price API does not halve your bug-fixing bill

ServBay — Thu, 29 Oct 2026 14:58:27 +0000

OpenAI cut the standard API price of GPT-6.1 Terra to $1 per million input tokens and $5 per million output tokens, roughly 50% lower than the previous generation. That number travels well. It also answers a narrower question than the one engineering teams actually ask, which is whether a finished, accepted bug fix now costs less.

The two questions are not the same. A per-token price is an input to a task, not the price of one. Everything below works through the gap between them, with the arithmetic spelled out.

Cost per accepted task as the unit of comparison

Why the token price decides nothing on its own

Three costs sit outside a per-million-token figure, and each one shows up on the same bill.

A task is rarely a single attempt. When the first patch fails the test suite, the retry carries the error log with it, and every extra round bills input and output again.
Failed attempts still bill. A wrong patch spends tokens like a right one, and the spend is not refunded.
Failures need a person. Fifteen minutes of engineer time spent unwinding a bad model change can cost more than dozens of API calls.

A low unit price is a necessary condition for a cheaper task, not a sufficient one. When two models have similar pass rates, the cheaper unit price turns into real savings. When pass rates diverge, the saving can invert.

The formula

Cost per accepted task = (total model spend + human cleanup cost) / number of accepted tasks

Model spend here counts successful and failed attempts together. Accepted tasks include the ones that only passed after a person stepped in. Otherwise the formula quietly hides the cost of failure. Teams that want to judge the model in isolation should also track the share of tasks that passed with no human help at all.

What public case studies leave out

Discussion threads like to settle the argument with one anecdote, such as a small game finished in a few minutes for a dollar or two. Those stories are vivid and thin. Without a shared acceptance bar, and without saying whether the deliverable passed tests or needed rework, they cannot be converted into cost per accepted task. Case studies retold in this article were not independently verified and serve only as background.

What GPT-6.1 Terra is, and what it costs

Positioning

OpenAI describes GPT-6.1 Terra as a fast, efficient model and positions it as a new balance of speed, capability and cost. The scenario highlighted in the launch material is high-volume automation, such as reading incoming invoices and entering the details into accounting software.

Pricing and availability

The API model name is gpt-6.1-terra. Standard API pricing runs at $1 per million input tokens, $0.05 per million cached input tokens and $5 per million output tokens. That standard API price is 50% lower than GPT-5.6 Terra and GPT-6.1 Sol.

Plus, Pro, Enterprise and Edu users can reach it inside ChatGPT Work and Codex. Developers can call it through the OpenAI API. OpenAI also notes that within the same usage quota in ChatGPT Work and Codex, more tasks can be completed than with GPT-5.6 Terra.

Published benchmark results

The figures below are OpenAI's own published numbers, not independent measurements.

Computer use. On Agents' Last Exam at medium reasoning effort, scores land about 15 percentage points above GPT-5.6 Terra at roughly one-third the cost. On OSWorld 2.1, medium reasoning already beats GPT-5.6 Terra's best result.
Visual reasoning. On MMMU-Pro it beats GPT-5.6 Terra at every reasoning setting.
Factual accuracy. On an internal OpenAI test built from prompts that tend to trigger errors, the error rate at low reasoning effort fell from 53.6% to 16.7%, and to 4.3% at maximum reasoning effort.
Software engineering. On Terminal-Bench 4.0, a command-line coding benchmark, it solved 50.3% of tasks at maximum reasoning effort. GPT-5.6 Terra's published score was 21.5%.
Speed. Task completion is more than 3× faster than GPT-6 Astra and GPT-6.1 Sol.

OpenAI also states that for the most complex coding work, GPT-6.1 Sol and GPT-6 Astra remain the better choices. That boundary drives the task-splitting rules further down.

Safety and alignment notes

OpenAI says Terra's cybersecurity capability reaches the Critical risk level in its Preparedness Framework, and that it keeps the protections built for GPT-6 Astra. In alignment evaluations Terra is more likely than GPT-5.6 Terra to stay inside the task scope and to state its own limits accurately. Prompt-injection tests show strong resistance to malicious instructions. The official system card carries the detail.

Reading the one-tenth and one-ninth claims

Two statements, two different comparison targets

The claim circulating most widely is one-tenth. The launch material contains two statements that sit close together but measure different things.

The first compares Terra with GPT-6 Astra on Agents' Last Exam, where performance is comparable while each token costs about one-tenth as much. That is a token unit price comparison, against Astra, on computer-use tasks.

The second runs at maximum reasoning effort, where Terra's token efficiency is more than 3× Claude Opus 5.5's while each token costs about one-fourth as much, putting cost per task at roughly one-ninth.

What neither statement covers

Neither claim says a bug fix costs one-tenth as much. The second at least frames the comparison per task, and OpenAI itself does not equate unit price with total cost. Anyone quoting the headline figure as a fix-your-backlog discount is stretching it past what was published.

Anatomy of one billed call

The three components

At the official rates, the cost of a single call is the sum of three parts.

Input covers code files, error logs and the prompt, billed at $1 per million tokens. Cached input covers context that repeats across retries, billed at $0.05 per million tokens, one-twentieth of ordinary input. Output covers patches, explanations and reasoning tokens, billed at $5 per million tokens, five times the input unit price.

Cache is the lever on retries

Cache matters most during retries. Code and prior context reappear round after round, and when the cache hits, the marginal cost of another round drops sharply. Whether it hits depends on prefix consistency and other conditions. Exact rules and TTL follow OpenAI's documentation.

Prompt structure decides a lot here. Put stable project notes and file contents first, and place this round's error text last, so the repeated prefix stays stable across attempts.

Output is the expensive component, so raising reasoning effort pushes up per-call cost as output grows.

Five steps from unit price to total bill

Unit price. Look up the official rates for input, cached input and output.
Attempts. Record how many rounds each task took and how many tokens each round consumed.
Acceptance. Write the pass criteria before the run. Named tests all pass, no regression on existing tests, no editing test files to force a pass.
Human cleanup. Record the minutes of human intervention after a model failure, converted at a single hourly rate.
Total. Apply the formula above.

Step three is the one teams skip. Without written criteria, there is no denominator, and the whole ledger collapses back into a feeling about which model writes nicer code.

A worked example where half the unit price costs about 13 times more

Assumptions

Every parameter below is assumed. None of it represents real pass rates for Terra or for any other model.

Each attempt uses 10,000 uncached input tokens, 30,000 cached input tokens and 8,000 output tokens.
At most 3 attempts per task, stopping on success.
If all 3 attempts fail, human cleanup takes 15 minutes at $60 per hour, so $15.
Model A uses Terra rates with a 40% per-attempt pass probability.
Model B costs twice Terra's unit price with an 80% per-attempt pass probability.
At Terra rates, one attempt costs $0.01 input + $0.0015 cached + $0.04 output = $0.0515.

Python that reproduces every figure

def cost_per_accepted_task(p, price_mult, cap=3, manual_fix=15.0):
    # Per-attempt cost (USD) at the example Terra standard rates
    per_attempt = (10_000 * 1 + 30_000 * 0.05 + 8_000 * 5) / 1_000_000 * price_mult
    fail_all = (1 - p) ** cap                                   # probability all attempts fail
    expected_attempts = sum((1 - p) ** i for i in range(cap))   # expected number of attempts
    model_cost = expected_attempts * per_attempt
    manual_cost = fail_all * manual_fix                         # expected human cleanup after total failure
    return per_attempt, expected_attempts, fail_all, model_cost, manual_cost, model_cost + manual_cost

print(cost_per_accepted_task(0.4, 1))  # Model A: Terra rates
print(cost_per_accepted_task(0.8, 2))  # Model B: 2× unit price

Results

Item	Model A (1× price, 40% pass)	Model B (2× price, 80% pass)
Cost per attempt	$0.0515	$0.103
Expected attempts	1.96	1.24
Model spend	$0.101	$0.128
Probability all fail	21.6%	0.8%
Expected human cleanup	$3.24	$0.12
Cost per accepted task	~$3.34	~$0.25

Under these assumptions Model A, at half the unit price, carries about 13 times Model B's total cost, and human cleanup dominates the difference. Look only at model spend and the ranking flips. A runs $0.101 per task against B's $0.128, so A looks slightly cheaper right up until a person has to open the editor.

The reverse holds too. Push A's pass rate toward B's and human cleanup shrinks fast, at which point the price edge becomes visible. The hinge is not the unit price. It is the pass rate, multiplied by what an hour of human failure costs.

Running the same comparison on a real repository

Controls to hold fixed

Pick a stably reproducible bug with a failing test, a public repo and a fixed commit. Medium difficulty works best, meaning not solvable in one shot and not hopeless.

Hold the prompt, the code snapshot and the retry cap identical across models. Keep billing channels consistent as well, and avoid mixing API figures with subscription quotas in one table. Run each model several times, because a single run is noisy enough to reverse a verdict.

Fields to log per attempt

Record attempt index, pass or fail, and token counts read from the API usage fields. Log human minutes whenever a failure needed intervention. The acceptance criteria should travel with the data, so a later reader knows what passed meant on the day of the run.

Matching task types to models

Work that suits Terra first

Scoped fixes with existing test coverage are the natural starting point. Pass rates tend to be higher, retries fewer, and the low unit price shows through. High-volume repetitive jobs fit the same profile, since unit-price gaps get amplified at scale.

Work that still belongs on a stronger model

Cross-module refactors and tangled dependency changes are better evaluated on a stronger model first. OpenAI itself points to GPT-6.1 Sol and GPT-6 Astra for the most complex coding work. When those tasks fail, the cleanup is expensive, and the money saved on a single call does not come close to covering it.

When the requirements are fuzzy

If tests are missing, add tests before picking a model. Without acceptance criteria there is no way to compute cost per accepted task, and any model choice defaults to taste.

This split is a starting point, not a policy. The stronger evidence is your own task data. Run a batch, compute cost per accepted task, then move work between models based on what the ledger says.

Holding the acceptance environment steady

Why environment drift contaminates the ledger

The same bug behaves differently across language and database versions. A model's first failure may come from bad code, or from mismatched dependencies, and those two failures should never share a ledger. If the runtime moves between runs, attempt counts and pass rates stop being comparable and the whole comparison loses its denominator.

ServBay, a one-stop AI development management tool, keeps PHP, Node.js, Python and other runtimes pinned on the machine alongside database and site configuration. Fix the acceptance environment once and every model attempt runs under identical conditions.

Using one endpoint for the comparison

ServBay AI Gateway also works as a single local entry point for this kind of test. Calls go out with virtual keys while the real upstream keys stay on the gateway side, encrypted locally and never uploaded. OpenAI, Anthropic and Gemini compatible paths are available, so a model swap does not require rewriting client code, and Claude Code, Codex and similar CLI tools can be pointed at the same endpoint from the interface.

Usage and cost for each run land in one place, which is what a per-task ledger needs. Per-project virtual keys keep an experiment from bleeding into production traffic, and they can be revoked when the run ends.

FAQ

Does a lower unit price always save money?

No. Unit price is one component of total cost. With low pass rates, many retries and heavy human cleanup, a cheap model can still cost more. Cost per accepted task is the metric that settles it.

How is cost per accepted task computed?

Add total model spend to human cleanup cost, then divide by the number of accepted tasks. Model spend has to include failed attempts, not just successful ones.

What is GPT-6.1 Terra's API price?

Per the launch announcement, standard API pricing is $1 per million input tokens, $0.05 per million cached input tokens and $5 per million output tokens. Prices change, so check OpenAI's official pricing page before budgeting.

Is Terra a fit for complex coding tasks?

On Terminal-Bench 4.0 at maximum reasoning effort it solved 50.3% of tasks, a clear jump over the previous generation. OpenAI still names GPT-6.1 Sol and GPT-6 Astra as the better fit for the most complex coding work.

Can cache hits distort a cost comparison?

Yes. Tasks with high cache hit rates cost less than estimates built on ordinary input prices. Record cached token counts for each model and keep prompt structure consistent across runs.

Is Copilot billed the same as the API?

No. The launch announcement does not spell out Copilot billing. Check GitHub's official billing documentation and do not apply API token unit prices to it directly.

What to take away

Terra moves price, speed and coding ability forward at the same time, and OpenAI's published numbers support that on the specific benchmarks listed above. Whether a given codebase gets cheaper is a separate question that only its own acceptance criteria can answer.

Model selection is drifting away from leaderboard position and toward how much money and time one finished task consumes, plus whether delivery holds up. The practical move is small. Take one reproducible bug, log tokens and human minutes per attempt, compute cost per accepted task, and let that number decide which work goes to which model.

What PHP2Shell Taught Me About Verified Code and the Runtime Underneath

ServBay — Wed, 28 Oct 2026 14:20:33 +0000

I spent the PHP2Shell weekend reading postmortems instead of shipping features, and the part that stuck with me was not the exploit. It was the gap between how we test code and how we actually run it.

Government sites across several European countries went offline at roughly the same time. In the Netherlands the digital identity system and personal government portals were shut down in an emergency. Major platforms in Japan posted maintenance notices one after another. Even a sushi order ran into it, with customers told the mobile mini-program was paused for a system upgrade. A cabinet official posted late at night urging everyone responsible for ops to respond immediately, and added that if a site could not be patched in time, temporarily pulling the network cable and taking it offline was still a necessary way to reduce risk.

The two flaws the security community calls PHP2Shell are tracked as CVE-2026-109618 and CVE-2026-109619, with a CVSS score of 9.2. Under default configurations, an unauthenticated external request can trigger a low-level exception through specific parameters and gain code execution on the server.

Around the disclosure, technical discussion about AI-assisted code verification was also running hot. OpenAI announced that its latest frontier models had helped find related vulnerabilities and billed it as a major win for its security program. In open-source and academic circles, Anthropic's newly released research drew plenty of admiration, with the paper claiming AI can already generate formal proofs for open-source codebases that pass independent checkers. The popular reading was that AI is wiping out human coding mistakes at unprecedented speed, and an age of essentially bug-free code is within reach.

Then came the split screen. On one side, Silicon Valley lab code that math supposedly proves airtight. On the other, production sites around the world yanking cables to save themselves.

The lesson I took is narrow and useful. Even when application code passes strict unit tests, static analysis, or formal proofs, a flaw in the interpreter that runs it can still take the whole system down.

The discovery story is less about models than the retelling suggested

The trail runs through 2004 and 2020

The person who first found the bug and produced a working proof of concept was independent researcher Ryan Austin. As early as early August he had already posted clues that included a discovery hash. In his later write-up he stressed that the initial find did not depend on any special tooling framework, and certainly not on some magical model ordinary people cannot touch.

What decided the find was decades of accumulated knowledge of the target's underbelly. The trail led back to a memory-limit defect publicly recorded in 2004, and to a 2020 issue report that never got enough attention. Those historical records set the main direction of the hunt.

Where the model actually paid off

AI's main job in this process was speeding up verification. Turning a theoretical memory flaw into a stable, reliable PoC often takes weeks of iterative debugging in traditional security research. With LLM-assisted analysis, that verification cycle shrank to a matter of days.

That division of labour reflects where the tech sits today. Research direction and intuition still rely on human understanding of system history and code context. Models mainly raise the throughput of retrieval and verification.

One caveat I keep in mind. As the bar for building exploits drops, defenders feel more time pressure. Once a patch is public, reverse-engineering the fix and extracting attack signatures gets much cheaper, and the window for operators to find and upgrade systems gets tighter.

Both CVEs sit below the application layer

What the two bugs actually do

CVE-2026-109618 ties to abnormal memory handling. When a request hits out-of-memory, the runtime uses a longjmp-style interrupt to abort. If that happens before some internal data is fully initialized, later cleanup can treat uninitialized data as valid objects, which opens a path to run attacker-chosen instructions.

CVE-2026-109619 involves leftover state after variable-scope teardown. Memory not fully cleaned from a prior request gets reused by a later one, with the risk of data leaks or diverted control flow.

Along the request path, a malicious payload can already affect the interpreter during web-server and FastCGI parsing, before any application script is read and run. Because the defect fires before app code executes, no amount of careful business logic can intercept the low-level runtime failure.

Why the scope matters more than the payload

Most website compromises in the past came from upper-layer application bugs, missing input sanitization that let malicious SQL into the database, or upload handlers that did not check extensions and let a trojan land on the server. What made this incident so widely watched is that the trigger is not in application business logic at all. It sits in the PHP interpreter's kernel.

W3Techs statistics say that among sites with a known server-side language, about 69% still run PHP. In a typical setup the web server takes the request and hands it to PHP-FPM over FastCGI, then a C-implemented interpreter handles memory allocation, request parsing, and code execution. Both critical bugs sit deep in that C implementation. A site that only prints Hello World is still exposed.

What formal proofs can and cannot say

Three tools, three scopes

Tool	What it checks
Unit tests	Expected outputs on fixed examples
Property tests	Random inputs thrown at edge cases
Formal proofs	A function meets its spec, shown with mathematical logic

All three target logical consistency in application code. Their reasoning assumes an ideal world, where hardware, OS, standard libraries, and the language interpreter all behave to spec with no surprise side effects.

Proof-checked is not deployment-verified

Anthropic's technical appendix explores using large models to help generate proofs and shows how mathematical specs can rigorously probe logical boundaries. On Hacker News many developers praised the progress in deterministic verification while also focusing on where it stops scaling for large production systems.

A formal proof can show that a payment debit function has no algorithmic hole and still say nothing about whether the PHP interpreter will overrun memory while allocating. Correctness at the app layer does not replace security review of the runtime. Security people keep repeating the same sentence, proof-checked is not deployment-verified.

Production is not the ideal world those proofs assume. As long as the C runtime has cracks, a green proof at the code layer is not the same as production safety. Treating a clean logical check as evidence that the whole system is solid is one of the biggest blind spots teams carry right now.

The patching gap nobody budgets for

The version spread

Public stats show about 65% of remaining PHP sites run on the 8.x branch. Of the rest, about 27% still use PHP 7.x, and about 7% run PHP 5.x, branches that hit end-of-life years ago.

Official fixes for this issue only cover the active 8.2, 8.3, 8.4, and 8.5 branches. That leaves roughly a third of the world's PHP sites unable to get an official security patch pushed to them.

Why upgrading is not a one-liner

For teams keeping those systems online, jumping major versions often means expensive rework. Old projects lean on deprecated syntax or stale extensions, and bumping the interpreter cold can break the app outright. Inside a tight window, a full rewrite is not realistic and easily imports new risk.

Telling those companies to tear everything down and rebuild, or hoping AI will overnight rewrite hundreds of thousands of lines of legacy code without breakage, is pure fantasy. The more workable engineering move is to keep major-version compatibility while back-porting the necessary patches into the runtime.

Where runtime-level maintenance fits

Back-porting into older branches

Handling low-level security updates like this means extending attention from code tests alone to a full evidence chain covering runtime, service config, and process state.

On the development and multi-version maintenance side, tools such as ServBay, an AI development management tool that keeps several runtimes available side by side, proved especially useful in this incident. For these vulnerabilities, ServBay not only synced fix packages for the mainstream PHP 8.x branches right away, but also back-ported security patches for officially unmaintained older PHP, including 7.x and even the 5.6 line.

That gives teams on legacy systems a pragmatic buffer. Developers do not have to risk rewriting the app. They can stay on their existing major branch and update to an interpreter build that already includes the fix, which clears the runtime hole.

Keeping the two layers apart

Paired with per-project PHP version binding, different sites can run in isolated environments matched to their dependencies. New projects take the newest PHP, old systems stay on a patched older build, and no single global environment steps on another. While developers use AI to write code or run tests, the infrastructure underneath offers a version-clear, config-transparent runtime base, so upper-layer logic verification and lower-layer environment security each stay in their lane.

What changed in my own checklist

When a test suite goes green, I ask which runtime it ran on and whether that runtime is still on a supported branch.
When I read a proof or a static analysis pass, I check whether it covers the language interpreter or stops at my own code.
For older services, I look for patched builds of end-of-life branches before I put a rewrite on the roadmap.

AI in security really does speed up discovery, assisted analysis, and logical proof. Tooling progress does not rewrite the basics of software engineering. Logical consistency in application code still rests on a stable interpreter underneath. For defects like CVE-2026-109618 that live in the basement, app-layer tests or math proofs alone are not enough. Facing the limits of verification, pairing them with controlled, reproducible infrastructure, and applying security patches promptly to both active and legacy systems, is the solid path to keeping services running.

CVE-2026-109618 Lived in the PHP Interpreter, and Formal Proofs Would Not Have Caught It

ServBay — Wed, 28 Oct 2026 14:20:13 +0000

Two CVEs in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, carry a CVSS score of 9.2. Under default configuration, an unauthenticated external request can trigger a low-level exception through specific parameters and reach code execution on the server.

The operational response was blunt. Government sites across several European countries went offline around the same time. In the Netherlands the digital identity system and personal government portals were shut down in an emergency. Major platforms in Japan posted maintenance notices one after another, and customers ordering sushi were told the mobile mini-program was paused for a system upgrade. A cabinet official posted late at night urging everyone responsible for ops to respond immediately, adding that pulling the network cable and taking a site offline was still a necessary way to reduce risk when a patch could not land in time.

Around the same days, two other stories were circulating. OpenAI announced that its latest frontier models had helped find related vulnerabilities, framed as a major win for its security program. Anthropic released research claiming AI can already generate formal proofs for open-source codebases that pass independent checkers. Put side by side, the three stories read like a contradiction. One side has math vouching for code. The other side has production sites yanking cables to stay alive.

The resolution is a layer question, and it is the reason this incident is worth studying rather than just patching.

What the Two Flaws Actually Break

Most website compromises in the past came from the application layer. Missing input sanitization let malicious SQL into the database. An upload handler skipped extension checks and a trojan landed on the server. Both are business logic mistakes, and both are fixable in the code the team owns.

The trigger sits below the script

These two bugs do not live in business logic. They sit inside the C implementation of the PHP interpreter. In a typical deployment the web server accepts the request and hands it to PHP-FPM over FastCGI, and that C runtime handles memory allocation, request parsing and code execution.

CVE-2026-109618 ties to abnormal memory handling. When a request hits out-of-memory, the runtime uses a longjmp-style interrupt to abort. If that fires before certain internal data is fully initialized, the cleanup path can treat uninitialized data as valid objects, which opens a route to running attacker-chosen instructions.

CVE-2026-109619 involves leftover state after variable-scope teardown. Memory that was not fully cleaned from a prior request gets reused by a later one, risking data leaks or diverted control flow.

The request never needs to reach the application

Along the request path, a malicious payload can already affect the interpreter during web-server and FastCGI parsing, before any application script is read and executed. That timing is what makes the blast radius so wide. W3Techs reports that among sites with a known server-side language, about 69% still run PHP. A site that only prints Hello World is exposed on the same terms as a large application, because the defect fires before app code exists in the request lifecycle.

How the Bug Was Found, and What AI Did

Early messaging leaned on how automated large language models performed in security research. The postmortem from researchers who took part in the discovery describes something closer to careful engineering.

The human trail

The first working proof of concept came from independent researcher Ryan Austin. As early as early August he had posted clues that included a discovery hash. In his later write-up he stressed that the initial find did not depend on any special tooling framework, and certainly not on a model ordinary teams cannot access.

What decided the find was accumulated knowledge of the target's internals. The trail led back to a memory-limit defect publicly recorded in 2004, and to a 2020 issue report that never got enough attention. Those historical records set the direction of the hunt.

Where LLM assistance paid off

Verification. Turning a theoretical memory flaw into a stable, reliable PoC traditionally takes weeks of iterative debugging. With LLM-assisted analysis, that cycle shrank to a matter of days.

That split is a fair description of where the technology sits. Research direction and intuition still depend on human understanding of system history and code context. Models raise retrieval and verification throughput.

There is a defensive consequence worth stating plainly. As the cost of building exploits drops, the window for operators to find and upgrade systems gets tighter, because reverse-engineering a public patch and extracting attack signatures becomes much cheaper.

The Verification Boundary

Software quality tooling has three well-understood layers, and each answers a different question.

Unit tests check expected outputs on fixed examples.
Property tests throw random inputs at edge cases.
Formal proofs use mathematical logic to show that a function meets its spec.

Every one of them assumes a well-behaved runtime

All three target logical consistency in application code, and their reasoning assumes hardware, operating system, standard libraries and the language interpreter behave to spec with no surprise side effects.

Anthropic's technical appendix explores using large models to generate proofs and shows how mathematical specs can probe logical boundaries rigorously. On Hacker News, many developers praised the progress in deterministic verification while pointing at exactly where it stops scaling for large production systems.

A formal proof can show a payment debit function has no algorithmic hole and say nothing about whether the PHP interpreter will overrun memory while allocating. Correctness at the application layer does not substitute for security review of the runtime. Security engineers keep repeating the same line, and it survives contact with this incident. Proof-checked is not deployment-verified. Treating logic checks out as the whole system is solid is one of the more expensive blind spots in circulation right now.

Patching Is an Engineering Problem, Not a Slogan

Faced with a bug this severe, the obvious instruction is one word. Upgrade.

Official fixes cover four branches

Of the PHP sites still running, about 65% are on the 8.x branch. About 27% remain on PHP 7.x and about 7% run PHP 5.x, branches that reached end-of-life years ago.

Branch	Share of remaining PHP sites	Official fix for this issue
PHP 8.x	~65%	Covered for 8.2, 8.3, 8.4, 8.5
PHP 7.x	~27%	Not covered
PHP 5.x	~7%	Not covered

Official fixes exist only for the active 8.2, 8.3, 8.4 and 8.5 branches. Roughly a third of the world's PHP sites cannot receive an official security patch at all.

A version jump is a project, not a command

For teams maintaining those systems, crossing major versions usually means expensive rework. Old projects lean on deprecated syntax or stale extensions, and bumping the interpreter cold can break the application outright. Inside a short disclosure window a full rewrite is not realistic, and it imports new risk of its own.

Telling those companies to tear everything down and rebuild, or assuming AI will rewrite hundreds of thousands of lines of legacy code overnight without breakage, is fantasy rather than a plan. The tractable engineering move is to hold major-version compatibility while back-porting the necessary patches into the runtime itself.

Extending the Evidence Chain to the Runtime

Handling a low-level security update means extending attention beyond code tests to a full evidence chain covering runtime, service configuration and process state.

Back-ported patches for unsupported branches

ServBay, a one-stop AI development management tool with a built-in local dev environment, shipped fix packages for the mainstream PHP 8.x branches immediately, and also back-ported security patches to branches that are no longer officially maintained, including PHP 7.x and the 5.6 line.

That gives legacy teams a pragmatic buffer. The application does not need rewriting. The existing major branch stays in place and moves onto an interpreter build that already contains the fix, which closes the runtime hole.

Per-project version binding

With PHP version binding set per project, different sites run in isolated environments matched to their own dependencies. New projects take the newest PHP. Old systems stay on a patched older build. One global environment no longer steps on another, and the version a site actually resolves at runtime is visible rather than assumed.

There is a second effect that matters during a disclosure window. While developers use AI to write code and run tests, the infrastructure underneath provides a runtime base with clear version lineage and transparent configuration, so upper-layer logic verification and lower-layer environment security each stay in their lane.

What Carries Forward

AI genuinely speeds up discovery, assisted analysis and logical proof in security work. Tooling progress does not rewrite the basics of software engineering.

Logical consistency in application code still rests on a stable interpreter underneath it. For defects like CVE-2026-109618 that live below the application, unit tests, static analysis and mathematical proofs address a different question than the one that gets a site compromised. Pairing honest limits on verification with infrastructure that is controlled and reproducible, and applying security patches promptly across both active and end-of-life branches, is the path that keeps services reachable.

Your php -v says patched. Your site may still be running the vulnerable build.

ServBay — Thu, 22 Oct 2026 17:36:39 +0000

Yesterday PHP disclosed two critical remote code execution (RCE) vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, with a CVSS score of 9.2. According to the official advance notice and a bulletin from the EU Computer Emergency Response Team (CERT-EU), the patch window was set for 22:00 Beijing time on October 21.

The news set off a wide discussion across the developer community—and even reached Japan's Prime Minister Sanae Takaichi (name another language runtime that gets a shout-out from a head of government. PHP really took that W).

In the hundreds of comments on the Hacker News hot thread, engineering teams kept circling two themes. First, distro builds, verification, and package distribution always leave a time gap before patches land everywhere. Second, a huge number of still-running older PHP projects have no upstream official patch support—and jumping across major versions carries steep code-migration and extension-compatibility risk.

ServBay has already shipped security updates for this PHP incident, and has also released patch support for older PHP versions. For developers maintaining multi-version projects or legacy systems, patched builds are available—so the hard part is no longer finding a fix. The critical next move is confirming that the updated binaries are actually what every target site is running.

When a PHP security patch lands, seeing an upgrade command succeed in the terminal does not mean your live sites and background jobs are out of danger. On a single server or developer machine with multiple PHP versions, the command line (CLI), the Web request path (PHP-FPM), and long-lived queue workers each load their own binaries and configs. Only by walking the four gates—package installed → site selected → process switched → regression passed—and keeping runtime evidence at each step can you prove the new patch truly owns production traffic.

Why Installed ≠ Running

Many developers lean on AI coding assistants to generate upgrade commands. After the package upgrade finishes and the terminal prints a fresh version string, it is easy to assume the fix is done. In multi-version environments, that assumption is a classic way to leave holes open.

On any one machine, PHP usually has at least three independent execution paths.

Terminal / CLI entry point

When a developer types php -v in an SSH session or local terminal, the OS resolves the executable from the current user's PATH. After a package update, the default symlink may point at the new build—but that only changes behavior for the current CLI session. It has no direct link to the processes that serve HTTP traffic.

Web server FastCGI entry point (PHP-FPM)

When Nginx or Apache handle dynamic requests, they forward them via fastcgi_pass to a PHP-FPM listen address (for example 127.0.0.1:9000) or a Unix domain socket (for example /run/php/php8.2-fpm.sock).

Two classic disconnects show up here.

The first is cross-branch coexistence: the system may have installed PHP 8.3, while the site's Nginx config still connects to php8.1-fpm.sock, so external traffic keeps hitting the old branch.

The second is a same-branch minor update: the on-disk binary has been replaced, but if the running php-fpm master never receives a reload or restart signal, the workers still resident in memory keep executing the old program.

Background long-lived processes (Queue Worker)

Projects that use Laravel Queue, Symfony Messenger, Swoole, or RoadRunner typically keep workers under Supervisor or systemd, resident in memory for long stretches. Even after CLI and Web PHP-FPM are updated, queue consumers and scheduled jobs keep running inside the old in-memory image until you explicitly restart those workers.

Four-Step Closed-Loop Verification

To prove a patch is actually active in production or staging, you cannot stop at an "install succeeded" message. You need runtime evidence collected in four steps.

加载中...

Step 1 — Inventory every PHP build on the machine

Before and after the upgrade, enumerate all PHP CLI and FPM binary paths on the host so you know the baseline.

# List every `php` executable on PATH
which -a php
# Show the default CLI version and build time
php -v
# Find running php-fpm processes (and their configs)
ps aux | grep php-fpm

If you use a Linux package manager, confirm the installed package names and build versions include the CVE-2026-109618 and CVE-2026-109619 fixes.

# Debian / Ubuntu: list installed PHP CLI/FPM package versions
dpkg -l | grep -E "php[0-9]+\.[0-9]+-(cli|fpm)"
# RHEL / Rocky / AlmaLinux: list installed PHP packages
rpm -qa | grep -E "php-(cli|fpm)"

Step 2 — Verify the target site's FastCGI binding

Do not assume the upgrade command rewrote your Web server config. Open the site's Nginx or Apache virtual-host file and locate the real address behind fastcgi_pass or SetHandler.

# Search every site config for fastcgi_pass targets
grep -rn "fastcgi_pass" /etc/nginx/conf.d/ /etc/nginx/sites-enabled/

With the socket path or port in hand, map it back to the listening process PID and the real binary that process is executing.

# Resolve the php-fpm master PID behind the socket (adjust path)
sudo lsof /run/php/php8.3-fpm.sock
# Inspect the on-disk binary that PID is actually running (replace 12345)
sudo ls -l /proc/12345/exe

On Linux, if the on-disk binary was updated but the process was never restarted, /proc/PID/exe ends with a (deleted) marker. That is direct evidence that disk is new while memory is still old.

Step 3 — Restart services and background workers

Once the site config points at the correct PHP branch, restart the matching PHP-FPM service and any background queue processes.

# Restart the matching PHP-FPM service (adjust version)
sudo systemctl restart php8.3-fpm
# Confirm the new master PID and start time
sudo systemctl status php8.3-fpm

For projects with async queues or in-memory runtimes, follow with framework-level and process-manager refresh commands.

# Laravel: ask queue workers to exit after the current job and reload
php /var/www/project/artisan queue:restart
# Supervisor: restart the worker group(s)
sudo supervisorctl restart all

Step 4 — Controlled runtime check and business regression

To verify the PHP version actually serving Web traffic, do not leave a publicly reachable phpinfo.php in the site root—that leaks environment variables and path layout to the open internet. Prefer a one-shot, minimal script reachable only from the loopback address (127.0.0.1 / ::1), print runtime version and SAPI info, then delete it immediately.

# 1. Drop a loopback-only one-shot check script
cat << 'EOF' > /var/www/project/public/.patch_check.php
<?php
if ($_SERVER['REMOTE_ADDR'] !== '127.0.0.1' && $_SERVER['REMOTE_ADDR'] !== '::1') {
    http_response_code(403);
    exit('Forbidden');
}
header('Content-Type: application/json');
echo json_encode([
    'sapi' => PHP_SAPI,
    'version' => PHP_VERSION,
    'version_id' => PHP_VERSION_ID,
    'ini_loaded' => php_ini_loaded_file(),
    'opcache_enabled' => function_exists('opcache_get_status') && opcache_get_status(false) !== false,
], JSON_PRETTY_PRINT);
EOF
# 2. Hit it from the server itself with the real Host header
curl -s -H "Host: example.com" http://127.0.0.1/.patch_check.php
# 3. Delete immediately after you confirm the version
rm -f /var/www/project/public/.patch_check.php

When the JSON shows sapi as fpm-fcgi and version matches the fixed release, the Web path has truly switched. Next, confirm core extensions the project depends on (for example redis, pdo_mysql, bcmath, opcache) still load, and run regression tests against critical APIs.

Legacy Patches and Per-Project Switching

In real maintenance work, many teams are stuck in a bind. On one hand they run new projects on PHP 8.3 alongside legacy systems still on PHP 7.x—or older. On the other, traditional package mirrors often only ship updates for active branches; forcing a major-version jump on an old codebase will break historical syntax and outdated extensions overnight.

To address that pain, ServBay not only patched today's mainstream PHP branches as soon as possible, but also published vulnerability fixes for older PHP. Combined with ServBay's per-project PHP version isolation, maintainers can harden security without breaking compatibility on legacy code. See also ServBay's PHP versio

n features.

In mixed multi-version environments, this model solves three engineering problems:

•Patch legacy projects without a rewrite: Stay on the original major branch, install the security package, and restart services—close the critical hole without a cross-major refactor.
•Bind sites clearly to the runtime they use: Each site or project explicitly selects its PHP version, so traffic cannot silently keep hitting an old socket after a host-wide upgrade.
•Unite version switching with runtime verification: Changing the project’s PHP and confirming what CLI, FPM, and workers actually load become one workflow, not two disconnected chores. ## Upgrade Verification Checklist and FAQ

Multi-version PHP environment upgrade checklist

Check item	How to verify	Pass criteria
Package installed	which -a php, php -v, dpkg -l / rpm -qa	Patched build for CVE-2026-109618 / CVE-2026-109619 is present on disk
Site selected	Inspect fastcgi_pass / SetHandler (or ServBay per-site PHP setting)	Vhost points at the intended patched branch’s socket or port
Process switched	systemctl restart for FPM; queue:restart / supervisorctl for workers; ls -l /proc/PID/exe	No (deleted) marker; PID binary matches the patched path
Regression passed	Loopback-only .patch_check.php + core extension / API tests	sapi is fpm-fcgi, version matches the fix, critical paths still green

FAQ

Q1: Why does the terminal show the latest version with **php -v, but the website is still on an old build?**

php -v only reflects the CLI binary resolved from your current PATH. HTTP traffic goes through Nginx/Apache to a PHP-FPM socket or port. If the vhost still binds an old socket, or FPM workers were never reloaded, the Web side will keep running the old version even when the CLI looks brand new.

Q2: We maintain legacy projects that cannot move to PHP 8.3. How do we fix this critical vulnerability?

Jumping major versions on old apps often triggers syntax breaks and third-party library failures. For history projects you cannot refactor immediately, use an environment like ServBay that already ships security patches for older PHP: update the patch package on the original branch and restart services. You close the critical hole while keeping existing business logic and extensions running.

Q3: After applying the security patch on the same branch, why are background queue jobs still unaffected?

Long-lived workers such as Laravel Queue, Swoole, or Workerman load the PHP interpreter into memory at start. Updating the on-disk package or restarting PHP-FPM does not interrupt those processes. You must also run php artisan queue:restart (or restart the matching Supervisor worker group) so background tasks load the patched binary.

Summary

When dealing with critical issues such as CVE-2026-109618 and CVE-2026-109619, downloading and installing a new build is only the starting line—confirming that live processes have actually loaded the new patch is the finish line. In multi-version engineering environments, leaning on a single php -v output is an easy way to be misled by surface results.

AA steady upgrade strategy has two sides. On the environment side, use a tool like ServBay that already ships security patches for both mainstream and historical PHP branches and supports binding PHP versions per project—solving the twin problems of "legacy apps that cannot cross majors" and "multi-site config chaos." On the go-live verification side, strictly follow the four-step checklist—package installed, site selected, process switched, regression passed—and record the real process state for CLI, PHP-FPM, and resident queues. Turn that verification into a team SOP, and the next runtime security update will be auditable and calm to land. Nail the process first, and you can ship the next patch without the heartburn.

PHP CVSS 9.2 RCE: Patch Isn’t Enough

ServBay — Thu, 22 Oct 2026 17:36:33 +0000