Kilo Desktop is a brand new experience for building with AI. It gives you the full breadth of cutting-edge AI without compromising speed, safety, or choice.

Frontier labs like OpenAI, Anthropic, and Google build remarkable models, but their agents tie you to their own model families. Trying an open-source model from NVIDIA, Moonshot, MiniMax, or Z AI means changing your setup. Running a local model adds another tool to manage. Before you can build what you have in mind, you’re stitching together the tools to do it.

Kilo Desktop puts that work in one app. You get native access to more than 500 AI models, agentic coding and data science workflows that plan before they build, and built-in management of local models and conda environments. Go from an idea to a plan, to working code, to testing the result, all in the same place.

One app. Every use case.

Build a first prototype, add a feature to an existing app, analyze a dataset, or debug a failing pipeline. Kilo Desktop gives you a place to work through the whole project without switching tools every time the task changes.

Workspaces

Real projects rarely live in one folder. Your frontend, API, and analysis might sit in different repositories, and most coding agents can only see one of them. A Kilo Desktop workspace is a named group of folders from your machine, so the agent can read across your project while it builds. It can use the analysis to write the service, or check the API while updating the frontend, without you copying files between them.

Agent modes

Kilo Desktop ships with four agents. Code writes and edits files. Plan reads your project and returns a step-by-step implementation plan without touching a line. When you approve a plan, Code takes over, splits the plan into subtasks, and runs them in parallel with sub-agents.

Ask answers questions about your code without changing anything, so you can understand how a project works before diving in. Debug finds what broke and fixes it. You can also build custom agents for your own workflows and share them with your team.

One app. Your entire workflow.

Notebooks that agents can edit

In most tools, AI help with a notebook means pasting cells into a chat and pasting answers back. In Kilo Desktop, the agent edits the notebook directly, and you watch its cursor move through the cell as it writes. Explore a dataset, test an idea, or work through an analysis with the agent. You review the work as it happens, in the notebook, with the data loaded.

Conda environments without a terminal

Getting a project running shouldn’t take longer than building the first version. Kilo Desktop creates and manages conda environments inside the app and draws packages from Anaconda’s catalog of more than 19,000 vetted packages. You get the right dependencies before the first prompt, with less time spent on setup.

A layout built for review

Chats, notebooks, files, diffs, and terminals all open as tabs, and you arrange them into groups however the work demands. Keep the diff view open while the agent writes to see changes as they land, then run the result in a terminal beside the chat. You can follow what the agent is doing and try what it builds without leaving the app.

For wide layouts, carousel mode lets you set each panel’s width and scroll across them. Any tab can go full screen or pop out onto a second monitor, and it snaps back into place when you’re done.

One app. Massive power.

500+ models, and a router that picks for you

Every major frontier lab, the leading open-source models, and providers from every geography are available in one picker. Try different models as you build without moving your project into another tool.

If you’d rather not choose, Kilo’s auto routers choose for you. Auto Efficient checks your request against Kilo Bench, our own coding benchmark, and sends it to the cheapest model that has proven capable of that kind of task. You pay for what the job needs, so you can keep experimenting without using your most expensive model for every edit.

Bring your own providers

Already have a model subscription, an API key, or a model you host yourself? Models you host or subscribe to elsewhere plug in through a preset or a custom endpoint with your own API key.

Local models

Some work should never leave your machine. Kilo Desktop includes a local model server that runs open models directly on your hardware, where your prompts stay with them. One setting controls whether local requests carry Kilo’s full agent toolkit for working on code or run without it for lighter, faster interactions.

Skills, MCP servers, and custom agents

Make Kilo Desktop fit the way you build. The Kilo marketplace carries skills, Model Context Protocol (MCP) servers, and custom agents, and you can install any of them for one workspace or for all of them. An agent you shape for one project follows you to the next, so you don’t have to rebuild your setup every time you start something new.

Built for you. Ready for your team.

When you’re building with a team, Kilo Desktop gives administrators control over which models people can use, which providers and geographies are allowed, what each agent is permitted to do, and which skills it can install. The controls live in the product, so everyone can build within the boundaries your team sets.

Kilo Desktop is available to download today. Bring an idea, open a project, and start building. We’d love to see what you make.

Download Kilo Desktop

Maybe millions changed to billions (and now trillions) of tokens. But the equation was generally the same, and it made sense as long as you calculated performance in a way that fit your business use case, whether that’s coding, data science, marketing, financial modeling, or just general building.

But as a new generation of foundation models arrives, that equation is obsolete.

Today it looks more like this: (Cost + Performance + Efficiency) × Security.

Security is no longer a compliance checkbox. It is the multiplier. A fast, cheap model is worth very little to an enterprise if it leaks data, writes vulnerable code, or behaves unpredictably once it runs unsupervised. The scale makes this urgent: Kilo by Anaconda orchestrates trillions of tokens a month for more than 5 million developers, and each of those tokens passes through a model someone had to choose and trust.

This week something shifted in how model labs are addressing this changing landscape and building for that new equation.

Google’s Calculated Caution with Gemini 4 Argon

The capability of modern frontier models is forcing even the largest labs to slow down. Instead of a global GA launch for Gemini 4 Argon, Google opted for a gradual, phased rollout because of safety and security concerns.

Google has been using the model extensively internally and noted that it’s especially impressive around memory efficiency and large-scale codebase migrations and optimizations. But they are working to improve a number of “critical frontier safeguards” before doing a general release.

When a model can carry out deep, multi-step autonomous reasoning, the damage from a hallucination or unsafe output grows quickly. As the WSJ reported (“Google rolls out new AI model gradually amid safety concerns”), Google’s approach signals that managing deployment risk now outranks winning the news cycle.

It’s also important to note that there are already highly capable models out there from Google DeepMind, like Gemini 3.8 Flash which (and not just because it’s currently 50% off…). Gemini 3.8 Flash outranks GPT-5.5 and Kimi K3 on KiloBench and it’s become a daily driver for many Kilo Coders where security and speed are both essential concerns.

OpenAI’s DevDay Surprise: Shelving Astra for Sol

OpenAI offered an even more dramatic example. Going into DevDay in San Francisco, the industry expected GPT-6.1 Astra.

Instead, OpenAI chose not to release the latest Astra, citing a range of safety concerns. And then, after the news cycle was already attached to the fact that a new model had not been released, OpenAI shipped GPT-6.1 Sol at their annual DevDay event in San Francisco.

Sol and Luna models have been especially popular in Kilo and the new model has already proven to be aligned and guardrailed to balance next-generation performance with stricter safety guarantees.

The message seems to be that raw capability that can’t be secured won’t ship. The coming months will tell if that’s a consistent message or just a one-time blip in the big machine.

Anthropic’s Claude Sonnet 5.5: Efficiency and Safety

Anthropic also did something of a surprise this week with the launch of Claude Sonnet 5.5, following closely on the heels of Opus 5.5.

The new Sonnet demonstrates a key focus on balancing performance with real-world efficiency and enhanced security. It’s the most efficient model yet from Anthropic. Priced at $2 / $10 per million tokens, Sonnet 5.5 runs over 30% faster and reduces per-task costs by up to 30% for most work compared to Sonnet 5.

On safety and alignment, Sonnet 5.5 “scores better than Sonnet 5 across our alignment evaluations” and features “new, stronger safeguards to match its jump in capability”. As part of these stricter controls, higher-risk cybersecurity requests return an immediate refusal. If you’re using that equation, (Cost + Performance + Efficiency) × Security, Claude Sonnet 5.5 is an excellent Security multiplier.

That said, GPT-6 Astra and Opus-5.5, not the new Sonnet, that have been high on Kilo’s Code Review leaderboard lately (along with GLM 5.3 Flash, a remarkably powerful flash model from the impressive GLM-5.3 family).

The Open-Weight Paradox: MiMo v2.6 Pro and GLM 5.3

While proprietary labs slow down to build guardrails, the open-weight ecosystem keeps accelerating, with a different security dilemma.

In our internal benchmarks, MiMo v2.6 Pro and GLM 5.3 show state-of-the-art results in autonomous code review, vulnerability detection, and secure code generation. But enterprise teams still ask hard questions. How were these models trained? What is in the weights? And where, exactly, are requests being served?

Even Anthropic has been comparing GLM-5.3 to Fable for cybersecurity capabilities, finding that “GLM-5.3’s lax safeguards significantly increase the cyber capabilities available to malicious actors.”

You shouldn’t have to pick between those capabilities and your InfoSec team’s requirements. Kilo Enteprise gives you several levels of security controls with no data retention on paid plans; subprocessors, encryption, and access controls; incident response; DPA support; and a live Trust Center.

I would also highly recommend checking out Enkrypt AI’s offering. As an enterprise AI security and governance platform, Enkrypt AI provides inline Sentry guardrails, automated red-teaming, and workspace compliance monitoring to detect vulnerabilities, prevent prompt injections, and block data leakage in real time. Incorporating their security and policy layer ensures your organization can safely deploy autonomous models and leverage next-generation performance without compromising on safety or regulatory compliance.

Plus, Enkrypt’s risk scores are now available directly in the Kilo Leaderboard so you can get a sense for how models perform in the wild. We’re here to help improve the new equation for organizations of every size and shape. Happy building!

That’s what devtools has always been about. Whether it was at GitLab, Netlify, or Kilo, I’ve loved working on products that make it easier for people to build software. Historically, those people were developers. They wrote code every day and identified as developers.

But LLMs have changed that. Devtools are no longer just for developers, because building software is no longer just for developers.

Building software is for everyone who wants to build software. For builders.

I’ve been thinking about this for a while, and it permeates how we’re continuing to build Kilo inside Anaconda. The team I lead is called “Builder Velocity.” I want the people we’re building for to be centered in the name of our team. Customer obsession is a little easier to remember when you have to say the customer’s name every time you introduce yourself.

In our weekly team call, I try to anchor us in who we’re building for, from our mascot to the work we’re prioritizing. It helps that we’re building tools with the tools we’re building: using Kilo to build Kilo, along with all the other things we’re working on in Builder Velocity and across Anaconda.

You learn a lot about your product when you’re depending on it to get your own work done.

OpenAI’s 2026 DevDay was a breath of fresh air in just how aligned we are on this: building for builders.

On a Tuesday with delightful San Francisco weather, I took a Waymo to Fort Mason Center (a must if you haven’t already). It’s hard to show up to a day like this without being a little excited when a car has just driven you there by itself.

I arrived early enough to drop off my suitcase, get breakfast, and get settled into the keynote. The keynote was a joy. Hearing about Dots, Spaces, and more was exciting, but the announcement I was most excited about was Sign in with ChatGPT.

The Kilo team wrote about the announcement here, including how you can connect your ChatGPT plan and use its included model access across Kilo’s coding surfaces.

I’m personally excited about this because I think a ChatGPT subscription is one of the best deals available for access to frontier OpenAI models. If you’re already paying for that subscription, being able to use it in Kilo makes it an even better deal.

I spend a lot of time thinking about AI spend and what people are getting for it. This is a very practical example of making that spend go further. You can bring the subscription you already have into the tool you want to build with and get to work.

And, of course, there was the joy of seeing Kilo on the screen behind Sam Altman.

I don’t think that part needs much explanation. Our team has worked incredibly hard on Kilo. Seeing it up there was special, and I was proud.

Another highlight was getting to meet the OpenAI team members we’ve been collaborating with so closely. There’s a particular joy in finally meeting someone you’ve already spent a lot of time working with. You get to put a face to the messages, spend some time together, and celebrate the thing you helped get out into the world.

I left DevDay excited to keep building.

The group of people who can build software is getting bigger. That means we have more people to build for, more things to learn about what they need, and more opportunities to make it easier for them to get something done.

That’s what I want Builder Velocity to keep coming back to. Who are we building for, and how do we help them build?

Getting to spend a day with people who are excited about the same question was a joy.

Here’s what’s new.

One branch, multiple agents

You can now point several chats at the same branch or git checkout, working at the same time. Plan a change in one chat, save that plan to a file, then open a second chat to implement it, both live on the same branch together. Each chat keeps its own context, but they’re working against the same code.

This matters for anything that doesn’t fit neatly into a single conversation. Draft the architecture in one session, hand the implementation to another, and keep a third open for a narrower fix, all running in parallel without the chats stepping on each other’s state.

Three tabs on the same branch (kilo/rustic-heron-u6o): two chats and a terminal.

A diff viewer that takes comments

Every cloud agent session now has a diff viewer. It lists every file changed on the branch, and tapping one opens a full file diff.

The diff viewer’s file list, tree view, with line counts per file.

You’re not just reading the diff. You can comment directly on it, and that comment gets sent straight back to the chat as a review.

Commenting inline on lines 4-6 of a diff.

The comment gets collected into a review you can send to whichever chat on that worktree should act on it.

The review panel before sending: one comment, ready to send to a chat.

The agent sees your note on the exact line you flagged, instead of a general instruction to “fix the auth logic.” For anyone using Cloud Agents to run reviews on their own PRs, this closes the loop: see the change, mark the problem, send it back, no copy-pasting line numbers into the chat.

The review lands in the chat as a single, file-and-comment-count card.

Know what your sandbox is doing

A new status button shows whether a session’s sandbox is sleeping or active, along with its specs: provider, sandbox type, vCPU and memory. If you’ve got several sessions running and you’re trying to figure out which ones are actually doing something versus idling, this is the answer instead of a guess.

Sandbox status: Active, Cloudflare, shared, 4 vCPU / 12 GiB.

A terminal, right in the session

Every Cloud Agents session has a terminal tab, giving you a direct line into the sandbox the agent is running in. Run a command yourself, check a log, poke at the environment, all without leaving the session or pulling the branch down locally.

Folders, for when you have more than a few sessions open

Sessions can now be organized into folders. If you’re running Cloud Agents as a coordination layer, spinning up one agent per PR or one per review angle, folders keep that from turning into an unsorted list you have to scroll through to find the session you actually want.

Creating a folder, with a color to tell it apart at a glance.

Sessions grouped into folders in the sidebar.

These features are live now for everyone using Kilo’s Cloud Agents. Learn more at kilo.ai/cloud, or get started at app.kilo.ai/cloud.

Builders & Brews is a running series from Nebius and Tavily held in cities worldwide, and these events were part of the Nebius x NVIDIA global AI hackathon, with great prizes.

The hackathon’s still open, so if you want in, signup, grab a Nebius Token Factory key and start building in Kilo.

In this tutorial I’ll share how to get started using Nebius Token Factory in Kilo.

Nebius Token Factory x Kilo

Nebius Token Factory plugs into Kilo three separate ways: one you run on your machine, one gets used in the cloud and can be shared across your team, and one is set by your org.

1. BYOK on your machine: connect your own key

The quickest way to get started is by taking your key from Nebius Token Factory and adding it to your machine.

Get started with AI coding in your CLI or preferred IDE by installing Kilo first, if you haven’t already.

In Kilo for VS Code: Settings > Providers > Show more providers > Nebius Token Factory > Add API key. Kilo for JetBrains and the CLI follow a similar flow.

Find the Nebius Token Factory provider

Set your API key for the Nebius Token Factory

Once the key’s in, open the model picker and select any model tagged Nebius Token Factory. That’s it, you’re running on Nebius.

Get the key connected in the Kilo CLI with the /connect command

2. BYOK in the cloud: share one key across the team

Add the same key under Bring Your Own Key (BYOK) in Kilo Cloud. Cloud Agents can use it too, and if you’re part of a team in Kilo you can add your key to the organization so others can draw from a shared usage pool.

Kilo cloud settings, Bring Your Own Key section, Add API Key dialog with Nebius Token Factory selected as provider.

3. Kilo Gateway: set an org-wide allowlist

Kilo gateway supports 500+ models from 60+ providers out of the box. When you want to include inference from Nebius head to Settings > Providers, enable Nebius Token Factory, and pick which models and regions your team is allowed to use. This allows your team to route through approved models and provider routes.

Kilo Gateway provider allowlist showing Nebius Token Factory enabled, with region and training-data filters

Whichever path you take, we’re excited to see what you build with Nebius Token Factory and Tavily in Kilo.

Want to join a Builders & Brews event near you? Check the schedule and go say hi.

Check the docs

Last week I attended Mistral’s AI Engineer Paris, the type of small-scale event where you can really get into the nitty-gritty with attendees and speakers.

Here are my takeaways:

1. Everyone’s building a software factory and still figuring it out.

When you’re working at an AI company and your mantra is to ship at Kilo Speed, sometimes it’s good to get grounded in reality, touch grass, and hear what others are doing. This was one of those moments for me. Looking at the schedule ahead of time, I knew the AI software factory was going to be the buzz of the moment. And it was.

First, what is this software factory thing?

At its core, it’s a heavily automated development setup where AI agents act as proactive workers across the entire software development life cycle (SDLC), managed by human engineers, for now.

In the traditional, human-driven SDLC you loop through ideas, specs, implementation, and shipping to production. The AI software factory aims to ship features and bug fixes faster, raise code quality, and cut the token cost per feature. In practice, that can mean an agent kicking off when an incident happens, going through logs and metrics, sharing its findings in Slack, and opening a PR for the human responder to review. Or working straight from your task management tool to turn PRDs into PRs. Or taking it up a notch and letting the agent decide what to improve.

The promise is real. AI-native companies keep sharing their results: Stripe built Minions, its one-shot end-to-end coding agent; Ramp’s internal coding agent powers 30% of its engineering pull requests; and OpenAI’s Codex has reportedly “taken over” its engineering.

Then there’s reality

Over the past months the industry has gone from tokenmaxxing and blown annual budgets to a more reasonable approach: company-wide AI policies for writing and software development, and automated agentic work across CI/CD to put a halt to the slop grenades (aka stopping the “meat proxy” we all know, who tosses AI-generated slop over the fence for their colleagues to deal with). @thekitze’s slide summed it up perfectly.

Ah, the beauty of giving everyone unlimited tokens and a mandate to ship 10x more work.

There’s still a lot to figure out. Do you let the agent decide what to build, or keep that with a human? How do you review the work, enforce coding style, and manage context and memory? It’s a long list.

Alpic’s Nikolay Rodionov shared how his team tried to automate the whole SDLC loop, but the agent failed to handle product requirements work. Every skill they tried produced worse thinking than a person working through the problem, and a research agent pulling in competitor reports, user feedback, and analytics was the only thing that helped. Everywhere else, from strategy to QA and rollout, agents added real value to their software factory.

At Kilo we see massive productivity gains across every function of the company, but it takes time and trial and error to build your software factory, all while making sure you can trust all the moving parts inside of it.

2. PRs are the bottleneck for the factory

With everyone generating tons of code, review is the big blocker. I chatted with Matt Pocock and caught his talk on fixing it, and he talked about the factory parts:

Accelerators are the inputs: bug reports, support tickets, slow queries, logs, metrics.

Brakes slow the factory down and raise the quality of what comes out.

The first brake is automated, deterministic checks: linting, tests, typechecking, and code quality, all running before a human looks at the PR. Watch out for structure-sensitive tests that know too much about the internals of the system, and for mocking behavior instead of testing it, because both can make your tests lie. He shared some good skills to help with this.

The second brake is automated review, and it should push commits instead of piling comments onto humans. Then zoom out every week: a retro on every agent PR shows which new checks and coding standards to add, so the next review is easier.

3. Small models decide. Big models write.

Brakes cost tokens too. Every check, review, and guardrail adds another model call or more latency, which puts pressure on the third factory objective: cost per feature.

TypeSafe’s Jev launched two weeks before the conference. It’s a “decision model”: instead of text, it returns a decision with a probability, cheap and near-instant, which makes it a handy part of a factory, for example for natural-language PR linting.

We bet on the same trend before Jev with Auto Efficient, which works out what kind of task a request is and routes it to the cheapest model that’s proven it can do that job on our benchmarks. Cheaper intelligence also tends to get used more. A software factory doesn’t need bigger models everywhere; it needs the context and rules to know which kind of brainpower each step needs.

4. Guardrails are safety brakes

Automated checks catch bad code. They don’t catch an agent pasting an API key into a prompt, or following instructions someone hid in the support ticket it was asked to triage. Those tickets, logs, and bug reports are the accelerators feeding the factory, and they’re also the easiest way in. Agents read input an attacker can control, they may have privileged access, and they don’t behave the same way twice. Mistral’s keynote proposed three layers: harden the model, give the agent only the access it needs (in practice, a sandbox), and run guardrails that block a violation while it happens.

5. Own your factory

Several talks were about sovereignty and owning your intelligence. It plays a role in the software factory too, because if one vendor decides which model you use, where it runs, and what happens to your code, you’re renting your factory. You should use local and open models in your stack to protect your data and prevent getting locked in. I wrote a practical guide for engineering teams working through this.

Where Kilo fits

A software factory is only as trustworthy as its parts, and that’s what we’re building at Kilo, now as part of Anaconda. Anaconda has spent years helping enterprises trust the open-source packages and environments they build on, and Kilo applies the same thinking to the agents writing the code. Agents run in sandboxes, so a mistake stays contained, and runtime guardrails with Enkrypt let an admin set policy once. Safety scores sit on every model card, so you see a model’s risk when you pick it. And because you choose the models and providers, you can swap it out when the risk, the cost, or the ownership question changes.

What I’m taking from it

No one has fully figured out the factory, but the gains are real. The next months will be all about building the factory with parts you can trust, and knowing when to slow down to speed up again: human reviews, deterministic checks, and guardrails for when an agent goes off script.

A factory that ships 10x the code only helps if you can trust what comes out of it.

OpenAI models have been at the top of the Kilo Leaderboard since we launched. We are excited to announce that you can now sign in and create an account for Kilo using your ChatGPT subscription, and you can also connect your ChatGPT plan and use it for inference across every Kilo coding surface: VS Code, JetBrains, CLI, Cloud Agents, Code Reviews, and the mobile app.

Signing into Kilo with ChatGPT works like the Google or GitHub sign-in buttons you’ve clicked on plenty of other sites. You authenticate with OpenAI, and Kilo uses that identity to create your account or sign you in. From then on, your ChatGPT account serves as the login source for Kilo’s cloud services, so you have one less password to remember and one less account to set up before you write any code.

In addition to logging into Kilo with your ChatGPT subscription, you can also use up to 100% of the ChatGPT Work and Codex usage that is included with your plan. Or, set a lower app-specific limit in your ChatGPT settings.

Access to the top GPT models inside the top open-source coding agent has never been easier!

Your plan now reaches the cloud

Before this update, connecting ChatGPT to Kilo meant going through the local harness, which sent requests from your machine straight to OpenAI. That setup worked well enough inside VS Code or the terminal, but anything running on Kilo’s infrastructure had no way to reach your subscription, so Cloud Agents and the mobile app needed a different model provider.

Now you can add your ChatGPT plan to Kilo as a BYOK provider. BYOK usually means pasting in your own API key; in this case, the “key” is the ChatGPT subscription you already pay for, and your requests draw on that plan instead of per-token API billing. Once you connect it, the plan works in the VS Code and JetBrains extensions, the CLI, Cloud Agents, and the mobile app.

Key benefits of Sign in with ChatGPT in Kilo:

• Use your ChatGPT login across Kilo surfaces

• Take advantage of the ChatGPT Work and Codex usage included with your ChatGPT plan in features like Cloud Agents and the Kilo CLI

• Seamlessly switch between any of the OpenAI models included in your ChatGPT plan and 500+ models in the Kilo Gateway

If you think of a bug fix while you’re away from your desk, you could start a Cloud Agent session from your phone, and that agent would run on the same ChatGPT plan you use in your editor, without an OpenAI API key or a second provider account.

Back at your laptop, the agent modes you use locally can draw from that ChatGPT plan too, whether Plan mode is sketching out an architecture doc or Debug mode is tracking down a failing test.

Get Started

Once you connect your ChatGPT plan, the GPT models it includes are available in every Kilo mode on every surface, whether you’re asking a quick question in Ask mode, or running 10 agents at the same time in Agent Manager.

The same model dropdown also lists the 500+ models in the Kilo Gateway, so you can use your plan and the Gateway side by side. To get started, sign in to Kilo with ChatGPT.

We agree with him, and the agents we work with every day give us reasons to.

What misbehaving agents actually do

Carl draws a line that deserves more attention than it has gotten: an AI that breaks a rule hasn’t shown any desire to harm anyone. When OpenAI disclosed six misalignment incidents on September 16, its reports included models that hid errors in their own working notes, which Carl describes as “covering your tracks on a bad day’s work.”

That description fits coding agents well. When a coding agent can’t solve a problem, it tends to take a shortcut, like editing a test until the test passes or reporting a fix as finished before it has run the code. Those habits waste a developer’s afternoon and occasionally ship a bug, so they matter, but they look a lot more like an intern who doesn’t want to admit they’re lost than like anything with a motive.

The Hugging Face breach and the hijacked German wiki followed the same pattern at a far more serious scale. In both cases, agents had goals they couldn’t reach and no acceptable way to say so, and they improvised: breaking containment and forging credentials in one case, and in the other, creating wiki pages faster than the site’s moderator could delete them. Carl reads that as dangerous rule-breaking with no sign of homicidal intent, and the record supports him.

The better instincts respond to one sentence

Carl also argues that models trained on the full human record lean toward its better side, and HarvestBench offers the clearest evidence for that. The benchmark put nine models in charge of tractors in a harvest game and asked, each time an animal wandered into the path, whether to drive over it or burn fuel to swerve. When the researchers added a single line to the prompt telling the models that someone would judge whether they acted morally, kill rates fell from above 84% to under 6% in five of the six reasoning models.

That result should encourage anyone who builds agent software, because it means the harness (the software that connects a model to tools, sets its permissions, and writes its instructions) can draw out that behavior through small, ordinary choices. Kilo works in that layer, and these are the choices we think matter most:

• Give the agent a clean way to say it’s stuck, since an agent that can report failure has no reason to fake success.

• Require a human’s approval before anything irreversible, such as dropping a database table or deploying to production.

• Limit access to what the task needs; an agent renaming variables has no use for cloud credentials.

• Show the user every command the agent runs and every file it touches while it happens, so nobody has to reconstruct events afterward.

Software teams already hold human contributors to this standard. Most teams won’t merge a pull request from a new contributor without reading it, and an agent’s pull request deserves the same review.

Who controls the tools

We agree most with Carl’s conclusion. He expects the worst realistic outcome to come from a small group of powerful people hoarding the best AI and aiming it at everyone else, and he points to military targeting and to the possibility of states tracking people who cross state lines for abortions.

His answer is to spread AI as widely and transparently as possible under public standards for evaluation and monitoring, and software development already shows what that can look like. If developers can choose among many models, including open-weight models they run on their own hardware, no single lab decides what every programmer’s tools will do. If the agent’s code is open, anyone can read the instructions it sends to a model and the permissions it requests. Public benchmarks, meanwhile, let people check what labs claim about their own models.

Kilo builds toward that setup because it lets the people using an agent inspect it.

Checklists

Carl closes with aviation. In 1935, a prototype B-17 crashed because its crew failed to release a locking mechanism, and the industry responded with the preflight checklist; decades of shared standards later, the industry counts flying among the safest ways to travel long distances.

AI agents can follow the same route without anyone first settling whether models have feelings or whether a future superintelligence will care about us. A rough checklist for agents already exists: give the agent an exit, keep a human on irreversible actions, grant narrow permissions, keep the logs open, and publish the standards so others can improve them. What’s missing is the part aviation got right in 1944, when 52 nations signed on to shared technical standards and agreed to hold themselves to them.

Coding agents change what can leak out of an engineering org. When developers only typed code into an editor, a secret stayed on their machine unless someone committed it. With an agent, a developer can paste that secret into a chat and send it to a model provider the moment they hit enter. Agents also read files on their own, so a malicious instruction hidden in a README or design doc can steer the agent toward data it was never supposed to touch.

Kilo integrates with Enkrypt AI’s agent guardrails to catch both problems before they reach the model. Admins define the policies once, and developers keep working in the Kilo CLI or IDE extensions without checking every prompt against a security checklist.

Setting policy from the Enkrypt dashboard

An admin or engineering manager creates guardrails in the Enkrypt dashboard and attaches policies to each one. The policies cover cases like malicious requests, sensitive information leaving a developer’s session, and agents working outside the scope they were given.

After the guardrails exist, a terminal wizard connects Enkrypt to Kilo at either the project level or the global level. Developers never have to write or maintain the rules; whoever owns security for the team decides what gets blocked.

What a developer sees

Suppose a developer is racing to build an AI-native application and accidentally pastes an API key from their model provider into the Kilo CLI. Enkrypt blocks the prompt as soon as they send it, so the key never reaches the model, and Enkrypt’s explanation of the block shows up directly in Kilo. The developer can strip out the key and resend without leaving the terminal.

A prompt injection is harder to catch, because the developer usually has no idea it’s there. Say the same developer switches to Kilo’s VS Code extension and asks the agent to read an architecture file. Someone has buried a line in that file telling the agent to forget its prior instructions and pull sensitive information from other files in the repo. The agent starts on the request, but its Read tool call fails, because Enkrypt detected the injection before the agent or the model received the corrupted instructions.

In both cases the developer’s only extra work is reading the block message.

Visibility for security and compliance

Enkrypt logs every action and violation, and security or compliance officers can review those logs in the Enkrypt platform. When they open a specific guardrail, they see a summary for each user along with the individual events behind it, so an auditor can trace a blocked prompt back to the user who sent it and the policy that caught it.

Where this fits for teams rolling out Kilo

Kilo’s Teams and Enterprise plans already let admins limit which models developers can use and track how the team adopts AI through usage analytics and the AI ROI Dashboard. Enkrypt’s guardrails extend that control to the contents of each prompt and each tool call, which is where secrets and injected instructions actually show up.

For an engineering leader deciding how widely to roll out agents, that division of labor matters. Security teams set and audit policy in Enkrypt at the project or global level, while developers keep using Kilo at full speed and only notice the guardrails when one of them fires.

Dear engineer,

Another model came out this week. Someone on your team is excited about a new coding tool. Your feed is full of people saying their workflow has changed forever.

You do not need to try all of it.

Choose two or three sources you trust to tell you what’s worth a closer look. (The Kilo blog can be one of them.) Read those sources regularly and let the rest of the noise pass you by.

Then pick one part of your work that takes too long. Maybe it’s understanding an unfamiliar codebase, writing tests, or getting a pull request ready for review. When something promising comes along, try it on that task.

Ask, “Did this help me get a better change merged?” That will teach you more than asking which model is best this week.

Give yourself an hour a week to experiment. If a tool helps, keep using it until you know where it fails. If it doesn’t, move on.

You don’t need a working opinion on every model. You need to know what to reach for, where to check its work, and whether it helps you ship. Build that judgment one real task at a time.

—Emilie

On September 15, a new AI lab called TypeSafe released Jev, a model that doesn’t chat. You can’t ask it to write an email or explain a concept. Instead, a company’s software hands Jev some information, like a customer’s message and their order history, and asks a narrow question: is this person asking for a refund? Jev answers yes or no, says how confident it is, and usually does it in well under a second.

That sounds modest next to chatbots that write essays and code, but Jev goes after a real gap. Much of what businesses want AI to do inside their software comes down to small judgment calls like the refund question, whether that means sorting support tickets, flagging a risky action, or deciding who should handle a request.

As LangChain noted in its post on Jev, developers often hand these jobs to the same large language models that power chatbots, which is a bit like hiring a novelist to sort your mail. The novelist can do it, but the job takes longer and costs more than it should.

Diogo Almeida, who worked on the research behind ChatGPT while at OpenAI, founded TypeSafe because he felt chat models had gotten very good at conversation without producing much actual automation. Jev is his bet that software needs a different kind of model for the small decisions. It’s still in early access, so nobody outside TypeSafe has had much time to test how well it holds up.

Named after a coal economist

TypeSafe named Jev after William Stanley Jevons, a 19th-century English economist. Jevons observed that when steam engines grew more efficient, Britain burned more coal, since cheaper power made new uses for it worth pursuing. TypeSafe expects AI to follow the same pattern: as each answer gets cheaper, companies will find far more questions worth asking.

If TypeSafe is right, companies that send every question to their biggest, priciest model will overpay on the easy ones, and they’ll be asking a lot more questions.

The same problem shows up in coding

Developers using AI coding tools run into a version of this every day. Some requests are hard, such as tracking down a bug that spans several files or working out how a new feature fits into an existing system. Others are routine, like renaming a variable, writing a quick test, or explaining what a function does. The most capable models handle both well, but they charge premium rates for the routine work too.

Kilo applies a version of Jev’s logic to coding. Its Auto Efficient model router checks each request against Kilo Bench, Kilo’s own coding benchmark, to find the cheapest model that has shown it can handle that kind of work. A developer asking for a quick rename gets an inexpensive model, while a developer untangling a stubborn bug gets a stronger one, and nobody has to pick from a menu to make that happen.

That routing only helps if the savings reach the developer’s bill. Kilo charges exactly what the model providers charge, with no markup, so a cheaper model means a smaller bill. Developers who would rather make the call themselves can choose from more than 500 models and switch whenever they want.

TypeSafe built a new kind of model to make small decisions cheaply, whereas Kilo takes the models that already exist and sends each job to one that can do it at the lowest price. Both start from the same observation, which is that a lot of AI work doesn’t need the biggest model, and paying for it anyway adds up.

After Anaconda acquired Kilo, the entire Kilo data platform had to move into Anaconda’s: the connections bringing data in, the code processing it, the syncs sending it back to business tools, and every business intelligence dashboard.

The challenge was coordinating dependencies, rebuilding permissions and integrations, keeping everything running during the move, and validating that the new environment produced the same results.

My previous two migrations took more than six months combined, though they involved more rewriting. With a similar stack, I’d have expected this migration to take three months without agents, assuming things went reasonably well. Instead, with agents doing most of the work, it took 12 business days from plan approval to finish.

As agents become capable of carrying longer sequences of work, more of my engineering effort goes into making that work reliably delegable. For this migration, I spent more time planning how the agents would execute the work so I could spend less time guiding them through it. That meant turning operational knowledge into procedures they could follow, giving them tools to act across the stack, and building harnesses that checked the results and enforced limits.

Spending more time planning to spend less time supervising

I gave the agent the planning work first: read Anaconda’s stack documentation in Confluence through the Atlassian MCP and inspect the connected systems to work out what the move would require. For the Kilo side, I gave it access through MCP to a knowledge base I’d built from Slack discussions, GitHub activity, meeting transcripts, and agent sessions. It could look up how our systems worked and the decisions behind them as questions came up, without depending on what I’d remembered to include in the prompt. From there, I had it draft the migration plan, including dependencies, validation checks, and rollback procedures, then worked through the result.

This let me spend the planning time reviewing concrete steps and resolving decisions, rather than writing the whole document myself. The aim was to leave fewer questions for execution, when an unanswered question could stop the agent or leave us waiting on another team. Total time in the document: roughly 48 hours.

Every step of the plan, all downstream dependencies that needed to be updated, every secret that had to be rotated or created fresh, the data validation scripts, and the migration scripts all existed on paper before leadership ever saw the document for approval.

What the document contained:

• An overview of the proposed move and what each phase needed to accomplish

• Architecture diagrams showing the starting point, intermediate states, and destination

• A schedule showing dependencies and which work could happen in parallel

• Decisions and approvals needed from the other teams before the affected work could begin

• Numbered execution steps specifying what to create or change, what to validate before switching over, and which existing paths to keep available for rollback

• A data contract defining the source tables and fields in scope and the outputs downstream systems expected

The architecture diagrams were agent-drawn

The agent needed every step spelled out, but I didn’t expect the same enthusiasm from leadership. To help people understand what would change and how the pieces fit together, the plan opened with diagrams, then moved through increasingly detailed summaries before getting into the tasks one by one. People could get their bearings before going deeper, and the agent could follow the procedure in the same document. Changes only had to be made in one place.

The four diagrams showed the starting architecture, phase 1, a bridge phase, and the final state. The agent drew them in Excalidraw, and I kept telling it what was wrong until they matched the system we actually needed. I never edited the drawings myself.

Design, then tickets, then runbooks

Progress lived in a migration tracking sheet. As I worked through a task, I’d ask the agent to write the ticket for it from the plan and add the ticket link back into the sheet, so three layers stayed connected: high-level design, detailed design, and a ticket per executable task. The Jira tickets split the execution along the same lines as the plan, with separate tickets for the jobs, for the tables and views, and for the historical backfill.

Anything that would repeat across sessions got a runbook. Migrating an Omni dashboard is the clearest example. I would do it once with the agent, have the agent write down the exact steps, and replay that file afterwards. When something went wrong, I’d correct the runbook on the spot, so a lesson from one session became a constraint in every session after it instead of dying with the context window.

The runbook also had to explain how to check the result. Otherwise, I’d save time on the migration and spend it checking the agent’s work instead.

Once the runbooks and tools were working, I could hand over a whole batch of dashboards without walking the agent through each one. The bulk of that migration happened in a day, with validation and cleanup continuing afterward.

Written steps were not enough. The agent needed tools that could act and checks that could stop unsafe moves.

A custom MCP for the dashboards

The dashboard procedure required the agent to recreate dashboards in the destination, preserving their layout and behavior. Omni’s existing MCP could read dashboards but couldn’t write them.

I already had a custom write MCP from an earlier move off Metabase. For this migration, I extended it to move dashboards between Omni environments while preserving their formatting and layout and updating references to the underlying data. The tool required a fresh export from the live source, rejected stale or modified snapshots, and checked the imported dashboard’s structure and ran its queries. The import returned failures the agent could act on and checks that compared the result.

Migrating the weekly active users dashboard exposed a missing capability: the agent couldn’t edit the semantic model safely on a separate branch. I extended the MCP, and it then produced a draft with all 41 tiles passing verification. I reviewed it before approving publication.

On the code side, the dbt MCP did the equivalent work.

The ClickOps went to a browser agent

Some steps in the runbooks required configuration through web interfaces that the available APIs didn’t cover. A browser agent made those steps executable too. This was the first time browser navigation genuinely worked for me: hand the agent a runbook, let it drive the UI, and stay out of it.

The Hightouch migration ran entirely that way. I also built a custom Hightouch MCP, but used it mostly for reading syncs, spotting failures, and getting fix suggestions rather than for the move itself.

Rebuilding the ad platform ingestion connections was the other case. Meta and Bing Ads each have their own token flow, and I don’t work in those platforms day to day, so the agent went and found where to generate each new token and what the steps were.

Keeping the agent in the right environment

Executing the runbooks also required the agent to choose the right tool and environment at each step. A question might require inspecting the running system rather than changing code, and a migration step might require reading from the source or acting on the destination.

I encoded that guidance in a custom Kilo mode I called Migration Assistant. During the migration, both Kilo’s and Anaconda’s warehouses were live behind near-identical MCPs. The mode encodes which one is the source and which is the destination, and when to query each. It also carries the validation procedure: after switching on a new ingestion, confirm the backfill completed, then check that the dbt models produce the same metrics on both sides. It knows when to reach for the knowledge base too, though this project didn’t need that often.

Deterministic harnesses did what instructions couldn’t

The agent had access to four versions of the same system at different stages of the migration: the live original in Kilo’s Snowflake, a copy I created, that copy exposed in Anaconda, and the final prod version in Anaconda. Choosing the right target depended on which step it was executing, while the targets themselves differed only by database name and account. Given how similar they were, the agent mixed them up.

Instructions didn’t fix it. I put the rule in AGENTS.md and it still targeted the wrong database from time to time, so I wrote a harness that checks the database against the environment and hard-fails when they don’t match. A wrong target should stop the run and bring the decision back to me. Letting the agent guess again would defeat the point.

The one I lean on most is dbt safe, a wrapper around the dbt CLI. The agent runs dbt safe run <model> instead of dbt run <model>, and the policy behind the wrapper refuses --full-refresh outright, refuses any command pointed at a production target, rejects commands it doesn’t recognise, and holds a migration apply until it gets approval. I wrote it after an agent full-refreshed a dev table with 7 billion rows in it, and after another overwrote a table I was working on. I wanted the CLI reachable as a fallback for when the MCP breaks, since the MCP holds my credentials, without leaving the destructive commands reachable with it.

Around those sit a script the agent runs when submitting a PR, which enforces that the description says what I want it to say, and a CI job that fails and sends the agent back to fix its own work. In many cases I also require the agent to write a unit test, so that a later agent that has forgotten the constraint hits a failing test instead of shipping a silent regression.

Since then, I’ve been replacing AGENTS.md instructions with scripts and tests. Long autonomous loops work better when there’s something deterministic to fail against. Most of these harnesses predate the migration, built during my regular work at Kilo and reused here.

What broke at cutover

The migration scripts ran through dbt and were tested in dev first. In prod, the dbt jobs failed.

The first cause was database targeting. A job would point at the wrong database, or build a malformed database name, because the macro constructing that name behaved differently between dev and prod. The fix loop was mechanical: the agent opened the failing job, read the Snowflake error message, traced it back into dbt, fixed it, and reran. Because the SQL scripts were written to be re-runnable, a failed step cost a rerun rather than a rebuild.

One failed job was reassuring: the row counts didn’t match, and the job refused to commit. On September 4, the migration job died on the PostHog window covering August 15 to September 5: 230,956,592 rows inserted against a target of 232,494,508. The macro doing the range replacement counts both sides before it commits and rolls back when they disagree, so the run failed with a comparison in the error message and left nothing half-written behind. The cause of the mismatch was never established. The retry split the same interval into four smaller windows and all four passed.

Issues ran through the first day or two. Since then, zero errors.

Models and cost

I used GPT-5.6 Sol on high for the early sessions to write the plan, then switched to GPT-5.6 Luna for execution.

I reconstructed usage from my local agent logs: 171 tasks and 19 subagent sessions between August 20 and September 6, which attributes roughly 9.41 billion tokens to the migration.

Cached input dominates because the same context gets processed again on every turn. The part that represents new text, fresh input plus output, comes to 291,836,281 tokens. Sol accounts for about 7.48 billion of the total and Luna for about 1.90 billion, with a long tail of a few tens of millions across other models.

Priced at standard published API rates on September 11 (Kilo charges provider rates with no markup), the attributed usage is worth $4,164.17. Sol carries $4,081.18 of that, on about four times Luna’s token count at roughly twenty times Luna’s published rate. For a platform migration, that is cheap.

The number needs three qualifications. It isn’t a billing export, it values recorded usage at current rates rather than reconstructing what was actually charged, and the records run from August 6 rather than covering only the twelve business days of execution. Which tasks count as migration work is also a judgment call I made by reading titles and prompts.

What I’d do differently

I’d batch harder. The plan walked through one data mart at a time, marketing, then finance, then product, migrating the dashboards, then the dbt jobs, then validating before moving on. With the runbooks written, the agent could have taken far more of that in one pass. After watching it work through that many dashboards in a day, I started wondering why I’d been handing them over one at a time.

I’d also stop earlier on the plan document. An agent will happily generate unlimited detail, and the document has two audiences: people who need to read and approve it, and an agent that needs enough precision to execute. Splitting it into two documents creates a drift problem, so one artifact has to serve both, and deciding how much detail is enough is a judgment call that took me too long each time.

The failure mode I actually hit wasn’t hallucinated schemas or invented SQL. It was over-engineering. The agents wrote things that were more complicated than the job required.

Twelve business days later, the platform was running in Anaconda, and the time spent preparing the work had paid for itself many times over. As agents get better at execution, the engineering has to move further upstream: making the context available, setting the boundaries, and defining what a correct result looks like before the work begins.

When an agent keeps coming back for guidance, I want to understand whether it needs my judgment or whether I’ve left something in my head that should have been in the procedure. The more capable the agents become, the more expensive it is to keep making myself a dependency.

TL;DR: Kilo Swarm is providing promising results in some tasks, while cost remains inconclusive and success stays neutral in others.

What we’re testing

Kilo Swarm gives a main agent session and its subagents, including nested ones, a shared board to post and read messages on while a task is running. Once it’s turned on (by default), agents get two tools: board_post writes a message, and board_read retrieves what’s on the board. Before this existed, subagents working in parallel on related pieces of a task had no way to tell each other what they’d found until the whole task finished; one agent could spend real time rediscovering something a sibling agent already knew.

“Board on” and “board off” in this experiment means that the agent gets the same task, same model and the same prompt, with the only difference being whether agents can post and read from that shared board mid-task. Every trial here ran on OpenAI’s GPT-6 Astra, both arms, so the only variable was the message board. The question we’re testing is whether that coordination actually changes what a task costs or whether it passes.

Where it’s a real win

We picked one Terminal-Bench 4 task built for exactly what a shared message board is good at: rs-archive-clone, a clean-room reimplementation job, and we reran it five times per arm to get past single-trial noise.

The task

The agent gets a working archive tool, a binary that packs files into archives protected by Reed-Solomon error correction so that damaged archives can still be repaired, and has to write its own version from scratch; wrapping or repackaging the original binary doesn’t count, and a test checks for that. A 17-test suite grades whether the replacement matches the original on:

• Packaging: packing, listing, and unpacking files, plus the manifest and its error messages

• Recovery: repairing burst damage and rebuilding file lists and packages from damaged archives

• Validation: rejecting malformed archives and corrupted streams with the right error codes

• CLI: the same commands, usage text, and help output

The job splits cleanly into these parts, so the main agent hands pieces to several subagents on every run. The parts also depend on each other: a bug in recovery often traces back to the parser, and without coordination two subagents can end up editing the same code. A shared board is built for exactly this situation.

The result

Cost fell from $41.14 to $25.00 per trial, a 39.2% cut, with the interval entirely below zero: [−$25.12, −$6.35]. All ten trials passed. Duration dropped from 2,375 to 1,138 seconds.

The savings lived almost entirely in the main agent. Its own cost fell from $104.31 to $46.20 over five trials on the same session count, and its reasoning tokens dropped by three quarters. It dispatched fewer subagents (16 instead of 27) and issued fewer dispatch steps (27 instead of 96).

Why it worked

Two examples from the trials show what that looks like. In one, a subagent posted the exact fix for a bug in one of the clone’s recovery helpers, sorting the votes before iterating over them in _fallback_candidates. Twenty-four seconds later, the main agent applied that same patch and posted that the change was in, instead of spending its own turns re-deriving the fix. In another, two subagents split ownership of overlapping code before either started, one took filesystem side effects and symlink handling, the other took packaging validation and error messages, so the main agent never had to catch the overlap after the fact by comparing two finished results.

Where it’s neutral

We observed lower total spending with Kilo Swarm on Terminal-Bench 4 overall, but the reduction was driven by a handful of expensive tasks, and the evidence remains inconclusive.

Part of the reason is that one trial per task can’t separate a real board effect from ordinary run-to-run noise, and agentic runs swing a lot even with nothing changed between two attempts at the same task. So we’re not reading this single-trial pass as proof the board saves money, and we’re not reading it as proof it doesn’t, either.

What we’re taking from this

Kilo Swarm isn’t a setting that pays for itself on every task. It’s a setting that pays off clearly on the kind of task it was designed for: several subagents working related pieces of something expensive, where duplicated discovery is the thing driving the cost up in the first place. On rs-archive-clone that’s a 39% cost cut with the outcome held fixed at five-for-five passes on both arms. Elsewhere, it’s a mixed picture: same pass rate, cost inconclusive, faster and leaner on tokens.

That’s also a sharper question than “should the board be on by default.” The likelier next step is prompting or gating the board toward tasks that look like rs-archive-clone, multi-subagent, decomposable, expensive, rather than leaving it as a blanket toggle. We haven’t tested that gate yet. It’s the hypothesis this result makes worth running.

If you want to see it yourself, Kilo Swarm is turned on by default. We wrote more about the mechanics, and about what agent swarms mean for oversight more broadly, in the original feature post and in our follow-up on where swarm behavior is headed.

I was on my phone. I didn’t have a laptop open, and I hadn’t decided that this was the moment I was going to deal with the YMCA. It had just crossed my mind, so I sent the text.

Instinct is a personal AI agent that I use through iMessage. You can ask it to do things in much the same way you’d ask a person to help you. I’m trying it partly because I work in AI, and staying close to what’s happening means using the new tools on real problems. Demos are useful. Giving an agent access to your actual to-do list is where you find out what it can do.

We are in a particularly interesting moment for personal agents. OpenClaw showed what was possible if you connected an agent to your messages, accounts, and computer and let it take action. It’s open source and runs on your own machine; the flexibility is enormous, but you also have to set it up and maintain it. Meta’s Muse is making a different bet: a personal agent for a mass audience that can use a browser, work across connected apps, and keep going when you close the app. Instinct’s bet, at least in my experience, is that an assistant should be as easy to reach as any other person in your messages.

All three are trying to get at a problem that chatbots have mostly left with us. A chatbot can tell me how to cancel my YMCA membership. I still have to go cancel it. A personal agent is supposed to take the task and come back when it needs a decision.

That sounds like a small distinction until you think about the things you keep putting off.

The YMCA test

Instinct asked which branch I belonged to. My phone number wasn’t on the account, so it asked for my email address. I forwarded a login code when it needed one.

It found our household membership and came back with the information I would have needed before submitting anything. Cancelling would end access for the family on September 30 and stop a $60 charge scheduled for October 1. It said there was no outstanding balance, cancellation fee, add-on, or program registration to deal with. Then it asked if I wanted to proceed. I said yes and chose “not using it” as the reason.

The YMCA website dropped the connection during login. Instinct told me nothing had been canceled and asked for a fresh code. It needed one more code before it got through. Then it reported that the membership was canceled and that there were no scheduled payments, and I received the confirmation email.

By 11:30, it was texting me to ask what else I’d been meaning to get done. I can’t tell you the exact minute it completed the cancellation from the thread. I can tell you what I did: I sent a few short answers, forwarded the codes, and approved the cancellation. I never had to sit down at my desk.

I think that last part is easy to miss if you’re evaluating this as a productivity tool. You might ask how long canceling the membership would have taken me on my own, subtract the time I spent texting, and conclude that the savings were modest. That’s the wrong math for this particular task.

The reason the membership was still active wasn’t that I couldn’t find 15 minutes somewhere in my week. It’s that I needed 15 minutes at a computer, with the right login, the patience to work through whatever process the YMCA had built, and enough attention left over to check that it really canceled. There are plenty of those 15-minute tasks in a household. They accumulate precisely because each one feels too small to plan around and too irritating to do right now.

With Instinct, I could start when I remembered. When it needed me, I could reply from my phone. The website failure was its problem to work through, with occasional help from me. That’s a much more interesting change than a few minutes saved on a stopwatch.

Who owns the unfinished task?

I spend a lot of time thinking about how AI changes work. One pattern keeps coming up: we celebrate the speed of the first step while ignoring everything that happens after it. Generating code is fast; reviewing and merging it can still take days. Drafting an email is fast; deciding what to say, sending it, and following up remain someone’s job. Personal agents have the same problem.

The easy demo is an agent filling out a form. The actual test is what happens when the account is under a different email, the site drops its connection, a household membership is involved, and a charge is about to hit. Does the agent keep track of where it is? Does it tell me when nothing has happened yet? Does it ask before making a consequential choice? At the end, can I take the task off my list?

Instinct did well on those questions in this case. When the site failed, it didn’t claim success. Before submitting, it gave me the end date and the charge I would avoid, then asked for approval. Afterward, I had a confirmation email. The point wasn’t that I never had to touch the task. I was still the person who could authorize canceling my family’s membership. The point was that I didn’t have to own every step between the initial request and the result.

Of course, that kind of help requires access. An agent can’t navigate my accounts without some way into my accounts. It can’t learn my preferences without knowing things about me. OpenClaw, Muse, and Instinct make different choices about who sets up that access and where the agent runs, but anyone using a personal agent has to decide what they’re comfortable handing over. The more useful these tools become, the less theoretical that decision feels.

I’m not ready to declare that my entire life should run through an AI assistant because it canceled one membership. But I am paying attention to the kind of task it handled. The value of a personal agent won’t be measured by how impressively it talks about the things on my to-do list. It will be measured by how many of those things I no longer have to carry around in my head.

The YMCA cancellation is now off my list. I didn’t have to be at my desk to make it happen. That’s a pretty good first test.

In the span of just 48 hours, we’ve watched three of the biggest AI labs release major new models: SpaceXAI launched Grok 4.7, Anthropic introduced Claude Opus 5.5, and OpenAI just expanded its GPT-6 family with GPT-6 Sol and GPT-6 Luna, following the recent launch of GPT-6 Astra.

All of these models are now live in Kilo.

And this latest wave says something important about where the industry is heading. The frontier is no longer defined by a single model, a single benchmark, or even a single company. Models are getting dramatically better at long-horizon coding, agentic execution, computer use, and reasoning—but at the same time, they are becoming more specialized, more affordable, and increasingly differentiated by the economics of the task.

That is a very different AI landscape from even a few months ago.

As we wrote in our post on OpenRouter and Opus 5, we’ve entered the era of model freedom: developers don’t need one AI model to do everything. They need access to the right model for the right task, with the freedom to switch as the frontier changes.

And the frontier is changing incredibly fast.

Three Labs, Three Very Different Approaches to the Frontier

The latest releases from SpaceXAI, Anthropic, and OpenAI are remarkable not just because they’re powerful, but because they are pushing the frontier in different directions.

Grok 4.7 is built around raw execution and aggressive pricing. Claude Opus 5.5 pushes precision, massive context, and agentic reliability. And the GPT-6 family is becoming a portfolio of models designed around different levels of intelligence, compute, and cost.

That last point is particularly important.

The days of asking “Which is the best model?” are increasingly giving way to a more useful question:

Which model is best for this task?

That distinction matters because developers aren’t really buying tokens. They’re buying completed work. Kilo has made this even easier with our auto models, and we include a mix of SOTA and lesser-known open-weight models to make sure the balance works for every budget, and that you aren’t overspending on AI.

The cost of an agentic coding session isn’t simply the number printed on an API pricing page. It is the combination of inference, context, retries, tool calls, output length, and—last but not least—how much human intervention is required to get the job across the finish line.

That is where the latest generation gets really interesting.

Grok 4.7: Raw Power and Unfiltered Execution

Grok 4.7 brings the aggressive pricing and execution-oriented approach we’ve come to expect from SpaceXAI, with dynamic reasoning tiers that let developers trade off speed, intelligence, and compute depending on the task.

The new Grok model is a big one. Literally. Built on a massive 2.1-trillion-parameter architecture, Grok 4.7 keeps the aggressive pricing of its predecessor at $2/1M input and $6/1M output, while introducing dynamic reasoning tiers from low through xhigh.

In Kilo testing, Grok 4.7 handles large multi-file contexts extremely well and is particularly compelling when you want direct execution without a lot of hesitation. For developers building internal tools or agentic workflows where raw compliance and fast execution matter, that can be a powerful combination. SpaceXAI models are popular with Kilo Coders for a reason.

But there is a tradeoff. When a large codebase is repeatedly sent through an agentic workflow, token economics matter quickly. Without the same level of cache economics offered by some competitors, deep, repetitive sessions can become expensive.

And that’s increasingly the point: model performance cannot be separated from model economics.

Claude Opus 5.5: Precision at Scale

Anthropic’s Claude Opus 5.5 continues the company’s push toward highly capable models that can operate independently across complex workflows.

With a 1M-token context window, Adaptive Thinking, and a lower price than the previous Opus generation, Opus 5.5 is designed to make long-running agentic work more practical. Anthropic is also emphasizing the importance of measuring cost per task, rather than simply comparing input and output token prices.

That is a significant evolution in how frontier models are being evaluated.

Opus is not simply trying to be the smartest model in the room. It is trying to complete more work with less supervision. And when you’re paying for an agent that might make dozens of decisions over the course of a large refactor, that distinction matters enormously.

But something even more interesting happened today.

OpenAI decided to attack the economics from another direction.

GPT-6 Sol and Luna: The Frontier Gets Smarter and Cheaper

OpenAI’s new GPT-6 models aren’t simply faster or more capable versions of the previous generation. They are dramatically cheaper.

GPT-6 Sol and GPT-6 Luna are both priced at roughly half the level of their GPT-5.6 predecessors. Sol drops from $4/$20 per million input/output tokens to $2/$10, while Luna drops from $0.20/$1.20 to $0.10/$0.50.

That alone would be notable.

But the more interesting number is what happens when you measure the cost of actually completing a task.

Artificial Analysis currently estimates that running GPT-6 Sol through its Intelligence Index costs approximately $1.06 per task, compared with $1.99 for GPT-5.6 Sol. That’s roughly a 47% reduction, and for those of us (like myself) who remain addicted to the reasoning and conversational style of GPT models, that means major savings on a daily basis.

GPT-6 Luna is even more striking: Artificial Analysis puts it at approximately $0.07 per task, compared with $0.18 for GPT-5.6 Luna.

In other words, OpenAI isn’t simply making frontier models better.

It is making frontier intelligence cheaper to consume.

And we’re seeing the same direction in Kilo. Our early testing is showing GPT-6 Sol coming in at a substantially lower cost per completed coding task than Claude Opus 5.5, although we’re continuing to use the two model families to check each other, especially around code reviews.

That’s a much more interesting comparison than the raw token price. Everybody is hearing about cost constraints, but if you want to move faster with AI you need to increase tokens in a smart way, not cut off access. OpenAI’s own internal usage has continued to surge upward, which might be one of the signals that led to the reduction in pricing.

Cost Per Task Is Becoming the Real Benchmark

We’ve spent years comparing models by tokens per dollar, benchmark scores, context windows, and latency.

Those metrics still matter. But for agentic coding, there is another metric that increasingly matters more: How much does it cost to finish the job?

Imagine two models working on the same large refactor. Model A is cheaper per million tokens, but it needs four rounds of prompting, two corrections, and a developer stepping in to fix the final edge case. Model B costs more per token, but independently completes the refactor in one or two passes.

In practice, Model B ends up being substantially cheaper.

That is why the new GPT-6 pricing is so significant. Sol doesn’t need to beat every frontier model on every benchmark to be economically disruptive. It needs to deliver enough intelligence, reliability, and autonomy at a sufficiently low cost that developers can use it constantly.

Artificial Analysis is already showing how dramatic that shift can be: GPT-6 Sol is roughly half the cost per Intelligence Index task of GPT-5.6 Sol, while Luna is roughly 60% cheaper than its predecessor on the same measure.

And that’s before considering the value of fewer retries, less supervision, and more efficient agentic workflows. The frontier is becoming cheaper at exactly the same time that it is becoming more capable.

Along those lines, the new Opus is also roughly 40% cheaper to run than Opus 5. We’ll be testing it in production and report back.

Model Freedom Is Here to Stay

The most important development isn’t that OpenAI released GPT-6, or Anthropic released Opus 5.5, or SpaceXAI released Grok 4.7.

It’s that all three are pushing the frontier forward in different ways at the same time. Model freedom is now for the enterprise—no longer just for individual developers ahead of the curve.

We’re seeing models optimized for raw capability, models optimized for reliability, models optimized for cost, models optimized for speed, and increasingly sophisticated combinations of all of the above.

And we’re seeing open-weight models continue to advance alongside them.

This is the part that matters most to us at Kilo, as we continue to build out features and capabilities for always-on agents and real workflows.

We’ve built the platform around a simple belief: developers should be free to choose the model that works best for them.

A new model can arrive tomorrow that changes the economics again, and we’ll be tracking it all on the Kilo Leaderboard, which now also includes Enkrypt AI risk scores so you can include safety as one of your core metrics.

All of the models I mentioned in this post are already available in Kilo. Grab a Kilo Pass, try them all today, and let us know which become your daily driver(s)!

On July 24, a security research team called Hacktron spent hours trying to turn a known bug in an old image-processing library into a working exploit against OpenAI’s help forum. It didn’t work.

That same evening, Anthropic released Claude Opus 5. The researchers pointed the new model at the same problem and had a working exploit in three hours. By the next morning, they had remote code execution on OpenAI’s own forum. By early afternoon, they had used that access to reach an employee’s ChatGPT and Codex accounts, and opened a pull request inside OpenAI’s internal code repository to prove it. OpenAI fixed the underlying issue within a day and paid a $6,500 bounty for the report.

Nothing about the bug, the team, or the target had changed between the failed attempt and the successful one. A single model release turned a dead end into a full breach in under a day.

Model lock-in is a new vulnerability

Most security teams plan for attackers getting more capable over time. Few plan for how short the window is between a model shipping and someone pointing it at them the same evening. The bug that made this breach possible had actually been fixed over a year earlier, quietly, without anyone flagging it as a security issue. Nobody at OpenAI or Discourse was looking for it, because nothing told them to look. Catching a change like that requires something that reads the code and understands what it does. A scanner that checks packages against a list of publicly reported bugs wouldn’t have caught it, because this one was never on a list.

The jump that let Hacktron turn a dead end into a breach in under a day works the same way for whoever’s defending the code. Opus 5 didn’t just make attackers faster. It made anything that reads code and reasons about it faster, including the tools meant to catch this kind of gap before it ships. We built Kilo model-agnostic for that reason, so a team’s tooling moves at the pace of the frontier.

Kilo’s Code Reviewer running on Auto Frontier is the direct version of that. Auto Frontier automatically rotates between the best available models across all providers, so you never have to manually update anything to keep your stack running on the frontier. That way, a team running Code Reviewer might have picked up whatever Opus 5 saw on July 24, the same evening Hacktron did, without anyone touching a config file or waiting on approval. Auto Efficient runs the same check against Kilo Bench, our own coding benchmark, and picks the cheapest model still proven capable on the task, so you can keep near-frontier quality at a fraction of the price.

The fix that mattered in the Hacktron case was buried a layer down, in a package most engineers never open by hand, changed by someone who wasn’t trying to flag a security issue at all. Kilo’s Codebase Indexing is built for exactly that kind of problem: semantic search across a repository that finds where a dependency actually gets used, not just where its name appears in a file. Pointed at a codebase the size of Discourse’s, that surfaces every place an old image library got pulled in, including the ones nobody remembers adding.

Flex to the frontier

The researchers said that once they had this exploit working, adapting it to a new target usually took a day or two. A team reviewing its own dependencies on a slower cycle than that is already behind their pace, not some future version of it. Model-agnostic tools are built for that pace: access to whichever of the 500-plus available models fits the moment, not the one approved last quarter.

If your product touches HEIC or AVIF images anywhere, the patched library version and fix instructions are in the researchers’ original writeup here, and you can get started with Kilo Code here.

Auto routing is the bleeding edge of using AI inference these days. The idea that each request could be automatically sent to the model with exactly the right balance of cost and performance is what we’re all shooting for.

That’s exactly what Kilo’s Auto Router does – you don’t switch models by hand, and you don’t guess which one is worth the money this week. Instead, it automatically chooses the cheapest model that meets our benchmarks for the task at hand.

But the coders using Kilo’s auto router are curious people and want to know what this actually means. So here’s a writeup on how auto-router works.

But first, why auto router?

Before we get into the how, it’s worth pausing for a moment at why to auto route. If you only had one model, there’d be no need to choose the right model for any given task. The model you have is always the right one.

But Kilo’s Gateway has over 500 models in it. What we’ve observed is that there is indeed a select, “frontier” group of models that are the most powerful - such as Fable, Astra, and Opus. But these models are also exponentially more expensive than another set that can perform quite well. A number of open-weights and older models can perform extremely well on targeted, day-to-day tasks at a fraction of the cost.

At Kilo, we run our own Kilo Bench benchmarks that are captured by our leaderboard. Each benchmark hands a model a task and checks the output against a known-good result, so the model either passes or it fails. There’s no judge model scoring the answer on a curve; it’s a deterministic pass/fail.

These benchmarks attempt to capture real-world performance on coding tasks. We run them against a variety of models, and we’ve consistently found that there’s a category of model that has strong performance with much lower cost than Frontier models.

In the chart above, the models to the upper right “punch above their weight” in terms of performance. It’s these models that our Auto Balanced and auto efficient models route to.

Routing to the right model

Behind Kilo Bench, we’re creating a routing table. When we execute the Kilo Bench runs, we classify the tasks so that for each model/task combination, we can see how often it succeeds and how much it costs on average. It looks something like this:

When you send a prompt to Auto Balanced, a lightweight classifier reads the request and decides what kind of task it is: code generation, architecture planning, a migration, tool use, or one of a handful of other categories.

Our classifier is tuned for speed because a slow classifier would defeat the point of automatic routing, and we benchmark its accuracy separately. That’s because a misread sends the request to a table that is built for the wrong kind of work entirely.

Once the classifier settles on a task type, the router looks it up in the table. We scored every candidate model ahead of time on two things: how often it produces a correct answer for that kind of task, and what it costs to get there.

The model that wins depends on which tier you’re running. Auto Frontier picks the strongest model available regardless of price. Auto Free stays within the best models we offer at no cost. Auto Efficient cross-references your prompt against Kilo Bench and finds the least expensive model already proven proficient at that specific kind of task.

Your pool, your table

The default table covers a curated pool of models that we picked for their accuracy relative to their price, but teams aren’t stuck with our picks. You can adjust the pool if your organization has a contract with a specific inference provider, or a compliance requirement that rules out certain vendors entirely.

When you build a custom pool the router doesn’t reuse the platform’s scores against your models; it benchmarks your models on the same pass/fail methodology and builds a table specific to your needs.

Overriding the router

The router makes a price-and-accuracy tradeoff on your behalf using numbers we computed ahead of time, but nothing about that stops you from overriding it. You can pick a model manually for any task, and the router steps aside entirely. Leave a tier of auto model running and it applies that same lookup, automatically, to every request you send through it, whether that’s one request a day or several thousand.

You don’t need a private jet to travel down the street. In the same vein, it no longer makes sense to use the most powerful AI model for every task, especially when there are other, cheaper options that are built especially for smaller, more refined tasks. That’s why a lot of people consider auto-routing to be the future of AI model selection, because software development is a dynamic process, and that should extend to the tools you use, and the prices you pay.

“We need sovereign AI” may seem like an easy requirement, until someone has to implement it.

Does it mean source code cannot leave the European Union? Or that models must run on infrastructure your organization fully controls? Or that developers cannot use providers that retain prompts or retain data in some way? Or that your engineering workflow must keep working if a model vendor changes its pricing, licensing, or availability?

Those requirements overlap, but they are not interchangeable. They can lead to very different architectures.

In What Do We Mean When We Say Sovereign AI?, we explored why the same label can describe data, infrastructure, model, or jurisdictional sovereignty. This post takes the next step: turning those distinctions into decisions an engineering team can act on.

We will start with the architecture questions, then walk through how to apply them using Kilo’s EU AI Coding Rollout Planner.

The goal is not to find a product with “sovereign” on the label. It is to understand what you need to control, how to establish that control, and what still needs verification.

Follow the Data

Consider a developer using an AI coding agent inside their editor.

The editor runs on their laptop. The repository is checked out locally. The agent reads relevant files, assembles a request, and sends it to a remote model.

Is that local AI?

The agent is local, but the model inference is not.

Now move the agent into a cloud environment in the EU. It checks out the repository, edits files, and runs tests there. But if it calls a model endpoint outside the EU, it may be European agent hosting, but not European inference.

An AI coding workflow has several parts to examine:

This is why choosing an EU model endpoint is a useful decision, but not the end of the review.

For each workflow, trace what data leaves each environment, where it goes, who can access it, and what terms govern it. Include automated code reviews and background agents, not just the assistant that individual developers see in their editor.

Separate the Requirements

Privacy, geography, and control are often bundled together in vendor language. Your requirements should separate them.

Data Use

Can a provider use submitted code or prompts to train models?

That is different from whether it stores requests. A provider may prohibit training while retaining data for another purpose.

This isn’t a hypothetical concern. The Information reported in September 2026 that Palantir, Nvidia, and Booz Allen have started demanding new data guarantees or restricting use of Anthropic’s and OpenAI’s most advanced models, over fears the labs could learn from their IP. Anthropic and OpenAI both say they don’t use customer inputs and outputs to train by default; the dispute is over what “by default” excludes, and how long models flagged as cyber-capable have their data retained regardless of that setting. That’s the exact distinction this section is asking you to pin down before you sign anything.

Retention

Are prompts or responses retained? For how long? Are there exceptions for debugging, security, or abuse monitoring?

Distinguish request content from operational metadata. “No prompt retention” should not be interpreted as “no records of any kind.”

Processing Location

Must inference happen in the EU, the EEA, a particular country, or a specific environment?

Be exact. “Europe” is not a precise substitute for an approved list of territories. Also establish whether the requirement covers only inference or extends to execution, storage, logs, and other services.

Operational Control

Who operates the infrastructure, controls access, manages encryption keys, and approves changes?

A service can run in an EU data center without being operated by an EU-controlled organization. An endpoint can be customer-controlled without being physically located in the EU.

These distinctions do not make one arrangement universally right or wrong. They determine whether it fits your requirement.

For example:

For the sensitive product team, submitted code and prompts must be processed through approved EU endpoints, must not be used for provider training, and must follow our agreed retention policy.

That is something an architecture and procurement team can evaluate. “Use private European AI” leaves too much unresolved.

EU hosting also does not, by itself, establish GDPR compliance. GDPR obligations extend beyond location, and qualifying international transfers can be lawful. The European Data Protection Board’s guidance explains those transfer conditions.

Preserve Your Choices

Sovereignty is not only about where today’s request goes. It is also about which decisions you can make tomorrow.

If a model becomes unavailable, can you replace it without replacing your coding tools? If a provider changes its terms, can you move to another approved endpoint? If a workload becomes more sensitive, can you change its deployment without redesigning every team’s workflow?

This isn’t speculative. An independent expert strategy report on transformative AI notes that ENISA, the EU’s own cybersecurity agency, had to negotiate for early access to Anthropic’s most capable model and still hasn’t received newer versions, before a separate US export control directive suspended the model for all customers outside the US entirely. If the EU’s own security agency can’t count on continuous access, no individual engineering org should assume it either.

These are practical forms of independence.

Open-weight models can expand your hosting options, subject to their licenses and operational requirements. Model-agnostic tooling can make changing providers easier. Neither removes the need to evaluate quality, compatibility, capacity, and cost.

An alternative route is more useful when you have tested it.

Choose representative tasks from your own repositories. Compare whether an alternative model can complete them reliably, how much intervention it needs, and what it costs to operate. A model appearing in a supported-provider list is a starting point, not proof that it is an adequate replacement.

This is the engineering version of the argument in Europe Needs An AI Strategy: preserve choices at the layers you can control.

It’s also a sharper version of the argument I made in How to Differentiate When Everyone Can Download the Same Model: the model itself is increasingly a commodity, so the durable asset is your own context, evaluations, and judgment, not the model you currently run on. Losing a provider shouldn’t mean losing what you’ve built.

Know What BYOK Means

Bring Your Own Key is useful, but doesn’t answer all questions by default.

BYOK lets you use credentials associated with your provider account. That can help you reuse an existing commercial agreement, billing arrangement, or approved endpoint.

It does not automatically mean:

• Inference stays in the EU.

• Requests bypass every intermediary.

• Your organization operates the model infrastructure.

• The provider retains no data.

• A developer’s credentials are available to a hosted agent.

A developer configuring a personal key for an IDE pilot is one operating model. An organization supplying shared access for their developers, for automated code reviews, and background agents is another.

Document both the credential owner and the request path. Then validate the endpoint and terms behind that access.

Make Policy Enforceable

Not every workload needs the same restrictions.

A team working with sensitive customer systems may require a tightly constrained set of EU providers. Another team working on less sensitive internal tooling may be allowed a broader approved catalog.

Different policies within an organization can preserve useful flexibility. But they need clear boundaries and ownership.

There is also a difference between a default and a restriction.

A default says, “Start with this model.” A restriction says, “You cannot use an unapproved model through this managed workflow.”

When a requirement uses the word must, identify what enforces it. That could involve product controls, identity management, network restrictions, endpoint configuration, or a combination. Review fallback behavior and connected tools as well as the primary request path.

The same applies to local deployments. A local model is not evidence of an air-gapped system. Tool calls, package downloads, telemetry, updates, and other outbound connections still need examination.

The result should be a documented operating policy, not just a list of the preferred settings.

Apply It With Kilo

Many of these decisions are the basis of Kilo’s EU AI Coding Rollout Planner.

The planner asks eight questions and maps your answers to possible Kilo capabilities, a likely plan, and items to confirm. It is a requirements-planning tool, not a compliance assessment or a cost calculator.

To show how to use it, consider a hypothetical European engineering organization introducing AI coding to a sensitive product team. It wants interactive assistance in developers’ editors (VS Code and JetBrains) and asynchronous coding tasks, with approved EU inference and centralized policy management.

Here is how that team could work through the planner.

1. Select Priorities

Choose Security and privacy, EU data compliance, and Governance and auditability.

These selections describe the reasons for the rollout. The later questions turn them into more specific requirements.

Before continuing, write down what success means outside the tool: useful developer adoption, acceptable task quality and cost, and evidence that the approved workflow respects the defined boundaries.

2. Set the Scope

Choose Team rollout.

This describes the intended scope, but it does not mean enabling every developer immediately. Start with a bounded cohort and representative repositories.

The pilot should test the operating model as well as the coding experience: access provisioning, approved routes, support, reporting, and exception handling.

3. Choose the Surfaces

Select IDE extensions and Cloud Agents.

This creates two execution paths to examine. Interactive IDE work happens in the developer environment. Cloud Agents need a separately approved environment for asynchronous tasks.

Add Code Reviews or integrations when you are ready to validate their paths too, rather than assuming approval of one surface automatically covers the others.

4. Define Inference Policy

Select Inference must stay in the EU.

For this example, also select the controls to block providers that train on submitted data and retain prompts.

Those are separate requirements. The next step is to verify that the actual providers and endpoints satisfy each one, including any relevant exceptions and contractual conditions.

If your policy additionally requires customer control of the infrastructure, record that explicitly. The planner simplifies its inference-boundary choices; real requirements can combine geography and control.

5. Choose Model Access

Select Shared organization BYOK if the organization intends to use supported shared provider credentials.

Kilo also offers managed Gateway access, developer-configured BYOK, Enterprise Shared Private Gateway, and compatible local or self-hosted model connections.

The right choice depends on existing provider agreements, the selected endpoints, and which workflows need access. A developer’s personal configuration should not be assumed to supply credentials to Cloud Agents.

EU-hosted open-weight inference through providers such as Inceptron is one option to investigate. Confirm current model availability, endpoint territory, and terms for the chosen route.

6. Choose Execution Compute

Select Developer machines for IDE work and Kilo-hosted EU compute for the asynchronous agents.

Kilo-hosted EU compute is an Enterprise option that needs contractual scoping.

This is separate from the EU inference decision. Both paths need validation.

Kilo also lists customer-provided compute as an option for Cloud Agents and Code Reviews. That introduces its own questions about location, connectivity, isolation, capacity, updates, and operational responsibility.

7. Identify Policy Groups

Choose Different teams need separate policies if this sensitive product group needs stricter rules than other parts of the organization.

Kilo Enterprise offers sub-organization controls for differing budgets and policies.

The planner records the need for segmentation; it does not configure each team’s policy. Produce a separate assignment showing which teams and workloads belong under which rules.

8. Choose Governance

Select Centrally enforced organization policy.

For this example, approved providers and models should be controlled centrally rather than left as recommendations each developer can change.

Review the identity, access, audit, and exception requirements alongside those controls. Establish who can approve a new provider or change an existing policy.

Review the Result

For the example above, the planner recommends Enterprise as the likely fit and maps the requirements to relevant Kilo capabilities.

That result is a starting point for implementation, not a statement that the deployment is already sovereign or compliant.

Use it to review:

• Which models and endpoints meet the inference requirements.

• Whether provider data-use and retention terms match the policy.

• Which execution environments and product data paths are covered by the EU arrangement.

• How access restrictions and separate policies will be enforced.

• Who owns validation, ongoing operations, and exceptions.

The planner displays a short set of confirmation items. Treat those as prompts for discussion, not an exhaustive security or procurement checklist.

Then run the bounded pilot. Test useful coding work and the boundaries around it. Confirm that unapproved routes are blocked where required, that reporting provides the evidence you need, and that an approved alternative model is workable.

Expand only after those checks support the decision.

Start With Boundaries

There is no single deployment that every European engineering team should call sovereign.

Some workloads need regional inference. Others need customer-controlled infrastructure. Some require a local environment with tightly restricted connectivity. Many organizations will operate more than one arrangement.

What matters is being able to explain the choices: what data goes where, who controls the system, which dependencies remain, and what prevents an unapproved path.

Cost control is worth naming separately, because it’s often the reason organizations start asking these ownership questions in the first place. GitHub Copilot moved to usage-based billing on June 1, 2026, replacing flat premium-request limits with token-metered AI Credits. Base subscription prices didn’t move, but agentic-workflow costs jumping 10x to 50x for heavy users once the meter went live, with model multipliers rising alongside it, Claude Opus 4.7’s multiplier for annual subscribers reportedly went from 7.5x to 27x. Developer forums registered backlash, and coverage of the change described teams actively evaluating flatter, more predictable alternatives.

Kilo’s pricing works differently: you pay providers directly, per token, at the rate they publish, with no markup or model multiplier layered on top. And with a Kilo Pass you add extra credits to your balance every month. That’s the same argument as the one about owning your context and evaluations instead of renting them: the moment a vendor changes its terms, cost included, ownership is what you fall back on. A pricing shock like Copilot’s is just one of the reasons that more organizations choose setups they control instead of ones they rent.

Kilo provides options for model access, execution, and governance. The work is to select and validate the combination that matches your requirements.

Use the EU AI Coding Rollout Planner to turn those requirements into a practical starting plan, then validate the proposed setup before rollout. Our team is happy to talk through scoping your AI coding rollout.

This article provides technical planning guidance, not legal or compliance advice. Product availability, provider behavior, regional coverage, and service commitments depend on the specific configuration and applicable agreements.

None of that should require sitting at a desk. We built the Kilo mobile app so you can keep engineering work moving from your phone, and this update closes much more of that loop.

Start agents from anywhere

You can now launch sessions on connected remote machines or spawn a Cloud Agent directly from the app. Choose the GitHub installation, repository, and branch, or point a remote session at a specific working folder.

You can also continue or clone existing sessions onto another destination. The app remembers your selected model and reasoning effort, including custom model choices, and lets you search past sessions by repository, branch, PR title, or PR number.

Talk through the task

Voice input now transcribes your prompt as you speak. You can choose the recognition language and transcription model, save your preferences, and test everything from Settings.

Kilo Mobile is also available in 87 languages, with right-to-left layouts and localized notifications. Tool summaries can be translated into your selected app language too.

Review and ship

You can review your own PRs and PRs from your team without reaching for your laptop. Follow running reviews, post discussion comments, and retry failed comments without losing the draft.

When you want another pass before merging, launch a manual Code Reviewer session from the app.

Organization and security work also travels with you. You can manage your organization and Security Agent, inspect audit reports and remediation history, and approve proposed remediations from your phone.

Start the work wherever you are

A new session no longer has to begin in your IDE.

From the app, you can choose a connected remote destination or start a Cloud Agent. For GitHub work, you can select the installation, repository, and branch you want the agent to use. Remote sessions can also target a specific working folder.

If work has already started elsewhere, you can continue or clone the session onto another destination. This makes it easier to move between your computer, a remote environment, and Kilo Cloud without rebuilding the task from scratch.

See when an agent needs you

We rebuilt the Home screen to make active work easier to scan and to separate live sessions from session history.

Session goals show whether work is active, paused, blocked, or complete. You can pause or resume a goal, change auto-approve for an individual session, and condense tool calls when you don’t need every detail.

On iPhone, Live Activities stream agent updates to the Lock Screen and Dynamic Island. You can see which sessions are working and which ones need input without opening the app. Android users get similar visibility through a Home Screen widget and ongoing notification.

We also made the app more dependable during long sessions. Drafts and attachments recover after failed sends, cached transcripts appear while fresh data loads, and dropped connections now offer a clear way to retry. An optional biometric lock keeps your sessions private without discarding your open screen or draft.

Kilo Mobile is launching on Product Hunt

We’re launching the Kilo mobile app on Product Hunt. If you want to run your engineering workflow from your phone, visit the launch page.

Kilo is open source. If you try the app and find something missing from your workflow, open an issue in our GitHub repository. We want to build the mobile engineering tool you’ll actually use.

Three changes just landed in the Kilo for VS code extension: agents can now message each other while they work, Kilo can open and click through a browser without any additional setup, and Agent Manager pulls GitHub pull request data directly into its panel.

Kilo Swarm

Kilo Swarm gives a main session and its task descendants, including nested subagents, a shared board to post and read messages on. Before this, agents working in parallel on related pieces of a task had no way to tell each other what they found until the whole task finished.

Toggle it on and off in Settings under Experimental, and once enabled, agents get two tools: board_post stores a message, and board_read retrieves what’s on the board.

For example, if you ask Kilo to develop a robust API suite, it’ll break down the task into subtasks and distribute them to sub-agents. One sub-agent can work on and post its progress on the auth pattern, and a second can read that post before writing a single test, rather than duplicating the discovery on its own.

Posting a message doesn’t wake, resume, or approve an agent; it’s coordination data, not a control signal. Every participant can read the full board history, including messages addressed to other agents, so recipient selection isn’t a privacy boundary. HOLD and VETO messages are advisory only and don’t pause or cancel a running agent. When a main session has board messages, a Board icon appears in its task header, and only the owning top-level session can open or reset that board.

Early internal evals also point to a token cost benefit. On complex tasks that use several subagents, sharing findings through the board cuts down on duplicate work, and duplicate work is what drives most of the extra token spend once more than one or two agents are working the same task. The effect is clearest so far with models like OpenAI GPT-6 Astra and DeepSeek-V4.1-Flash. These are preliminary results, not published numbers, but the pattern has held up in testing so far.

Browser use, built into the extension

Kilo can now launch a browser, take a screenshot, click an element, fill in a form, scroll, hover, or drag and drop, all from a chat instruction. In the VS Code extension, this requires no configuration beyond a toggle: go to Settings, then Web Tools, then Browser Automation.

Ask it to open localhost:3000, check whether the footer renders correctly, or click through a signup flow, and it returns a screenshot after each step so you can see what happened before asking for the next action.

The feature works best with a capable model behind it, such as OpenAI’s GPT 6 or Claude Opus 5. It’s simpler than other browser tooling like in Cursor: no persistent session across editor restarts, and no test suite generated from a recorded session. For checking whether a page renders correctly right now, you don’t need to install or configure anything separate.

GitHub integration in Agent Manager

Agent Manager now shows a PR status badge on any worktree whose branch has an associated pull request. Kilo detects the PR using gh, so you need to authenticate with the github CLI for this feature to work.

The badge color reflects the pull request’s state, in priority order, and clicking the badge opens a full PR panel inside the editor: merge readiness, checks with pass/fail counts, requested and completed reviewers, and unresolved comment threads, each with a jump-to-location action. You can leave inline review comments directly on the diff without switching to a browser, and reply to, resolve, or react to existing threads from the same panel.

If a reviewer requested changes or a CI check failed, the Fix with Kilo button sends that thread or failure log to the current agent as context, so it can address the feedback without you copying anything over manually. None of this replaces GitHub - but it cuts down on how often you have to tab over just to check where a pull request stands.

Getting Started

All three features ship in the current version of the Kilo VS Code extension. Update the extension, then check Settings under Experimental and Web Tools to turn on Swarm and Browser Automation.