Meanwhile, the five companies paying for much of the compute that powers this AI usage have seen their combined cash flow fall by nearly 90 percent in 18 months. They have sunk enormous sums into compute over the last few years, and that spending has to start showing up as cash flow soon. At the same time, the frontier labs behind these models are heading toward some of the largest IPOs in history, and their valuations assume token consumption and revenue keep climbing. This creates real pressure on pricing and growth.

But not all is doom and gloom. The case I’m making is to learn from AI power users, and to plan for what’s actually happening instead of what the headlines tell you.

AI scales ambition

Let’s start with the good news. Ramp and Revelio Labs linked spending data to workforce records for 21,559 U.S. firms and found that companies making the largest AI investments grew headcount by 10 percent over the two years following adoption. Entry-level hiring grew even faster, at 12 percent. Firms that adopted AI lightly saw no significant change either way, up or down.

Box ran a separate survey of 1,640 companies and landed on the same pattern from a different angle. Fifty-eight percent of respondents expect headcount to rise over the next three years. Among the most AI-mature companies, that number climbs to 79 percent. Only 9 percent say AI agents are primarily eliminating roles today.

The reason is simple. A company that can serve more customers because AI handles account research hires more salespeople to close those accounts, not fewer. A team that can ship more software takes on bigger projects and needs more engineers to run them. AI is expanding what companies believe they can achieve. And there’s a compounding effect: teams that work with AI extensively learn how to build with it. We see this at Kilo all the time, it takes hands-on time before a team really ships faster.

Their growth pressure becomes your bill

Now the part that's going to create friction soon. Apollo’s chief economist has been tracking twelve-month forward free cash flow across the five companies funding almost all of this: Microsoft, Amazon, Alphabet, Meta, and Oracle. That number peaked near $300 billion in late 2024. It has since fallen to roughly $40 billion. And most of that decline happened in just the last few months.

The gap between investments and valuations is what increased the pressure. One of the main levers we'll see more and more companies use is pricing. And that isn't a hypothetical scenario. We saw the effect recently when GitHub flipped Copilot to usage-based billing. All of a sudden, instead of a fixed seat cost, engineering leaders had to deal with their per developer bills increasing from tens to thousands.

Nobody knows who captures the value

The honest answer is that nobody knows how this resolves, including the companies making the bet. Railroads in the 1800s and fiber in the late 1990s ran on the same logic: massive buildout now, outsized returns later. Both were right about the technology and wrong about who would capture the value. When everyone builds the same thing at the same time, nobody gets to charge a premium for it for long, and the value tends to settle somewhere else. What we do know is that the AI pricing pressure has already started to trickle down to its users.

That’s why you need an open layer

If your team’s plans assume today’s model pricing, availability, and vendor terms simply continue, you are walking on very thin ice. We’ve written before about what that looks like up close: a frontier model can be the best option one week, and access pulled entirely the next one.

You cannot predict who captures the value, but you can rest assured that your bills will continue to pay off the hyperscalers’ bets. The one thing in your control is how dependent you are on a single vendor. The heaviest AI adopters don’t stand on one flagship model, they mix models and vendors and route each task to whatever fits it best. Coinbase just showed what that looks like in practice, cutting its AI spend nearly in half while token usage kept climbing.

An open layer that prevents vendor lock-in and routes work across models and providers is how you build a workflow that lasts.

We’re thrilled to announce that the much-anticipated General Availability (GA) release of Hy3, totally free for a limited time everywhere you use Kilo. That means you get elite, production-grade AI assistance right in your VS Code sidebar, cloud agents, our CLI, you name it! All completely free of charge with high limits thanks to compute from Novita.

Why Hy3 is Your New Coding Superpower

Developed by the team at Tencent, the GA release of Hy3 isn’t just a minor update; it’s a massive leap forward in reasoning, agentic workflows, and production-grade stability.

Moving beyond the preview stage, the team scaled up Reinforcement Learning (RL) training and fine-tuned post-training data quality. In blind tests with real-world expert workflows, Hy3 consistently outperformed similar-sized models and rivaled flagship open-source models with 2x to 5x the parameters.

By utilizing Kilo’s VS Code extension, you can seamlessly bring these massive upgrades straight into your active workspace. Key real-world improvements in the GA release include:

• Production-Grade Tool Calling: Massive upgrades to tool-call success rates and error recovery, drastically minimizing invalid calls or infinite loops while using agentic features in your editor.

• Plummeting Hallucinations: Thanks to rigorous data cleaning and specific training constraints, the internal hallucination rate has dropped from 12.5% to just 5.4%—meaning more accurate code syntax and fewer phantom bugs.

• Long-Context Intent Tracking: Upgraded multi-turn dialogue capabilities ensure your complex coding intents don’t drift or decay over long, multi-step refactoring sessions in your codebase.

In my view, Tencent’s expertise in video game development across their massive portfolio has helped improve this model’s capabilities around coding in general. It’s highly efficient (following the trend from both closed and open labs lately) and strong at both front-end and back-end development tasks.

Under the Hood: The Specs

Hy3 continues the trend of recent open-weight releases focused on both efficiency and capabilities for daily agentic work. Here are the specs:

• Architecture: Mixture-of-Experts (MoE)

• Total Parameters: 295B

• Activated Parameters: 21B

• Context Length: 256K

• Number of Experts: 192 experts, top-8 activated

It’s great to see the 256K context length for Kilo users with large codebases and complex projects, and with 295B total parameters (while keeping inference lightning-fast by activating 21B parameters per token), Hy3 is perfectly engineered to parse entire files and tackle massive documentation without breaking a sweat—making it the ultimate companion for your VS Code environment.

We’ll get the stats live in PinchBench and KiloBench soon as well. Watch the Kilo Leaderboard for updates.

Start Building for Free Today

It’s time to move your daily dev projects out of the preview era and into full, robust production without ever leaving your editor.

Just select Tencent Hy3 from the model dropdown wherever you use Kilo. Happy coding!

Since January of this year, I’ve attended or hosted 23 developer events. I’d estimate that, during these events, I interacted with at least 3,000 developers. That’s one of the perks of working at an AI coding startup in 2026.

These events spanned hackathons, enterprise summits, open source conferences, virtual workshops - bringing me to Spain, London, Miami, and Las Vegas - and back to a couple happy hours in my home city of New York, to take the edge off.

Some of these events featured hour-long, very corporate keynotes, and others featured 300 lbs of crab legs and Ashton Kutcher (seriously).

My job (Developer Relations) is to listen to, educate, and understand developers, and 2026 has blessed me with a truly staggering wealth of conversation and discussion, to help me inform my work.

Here are the most recurring, exciting, startling, and notable themes from my experience talking to developers in 2026

1. The AI literacy gap is enormous, and the middle is an opportunity

The single most jarring thing about doing 23 of these back to back is the whiplash between rooms. At ClawCon events, I met people automating their entire job and life. I literally met four fifteen-year-olds running $30k/month businesses on top of OpenClaw. I met someone who said they automated their entire work day down to 10 minutes of manual check-in, and he showed me the receipts to back it up (I wonder if his boss knows…).

Then, a week later, I’d be at a corporate conference where smart, experienced developers were still figuring out how to get good results out of ChatGPT.

That’s not a shot at the people who are earlier on the curve. It’s a measurement. The gap between the power users and everyone else is wider than any technology adoption gap I’ve personally witnessed, and it means two things. There is a massive amount of educating left to do, and there’s a huge amount of room to innovate in the middle ground, building for the people between “still learning” and “fully automated.”

2. Adoption is happening bottom-up, and that’s new

In my past experience working in tech, this is the opposite of how enterprise software usually spreads. Normally a VP picks a vendor, procurement grinds through it, and the tool lands on developers regardless of their personal preference.

However, with AI tooling, a striking number of enterprise users I talked to started using their current AI toolset because a developer they trusted, often an IC, vouched for it. It went up the ladder, not down.

I think this is happening for two reasons - both theories at this point. First, I think the tooling is proliferating and evolving so fast that decision makers literally cannot keep up. By the time a committee finishes evaluating something, the industry has moved past it. If you’re paying attention to AI, you know about the graveyard of tools that were once billed as “the future of AI”. To keep up, vendors need to be nimble and innovate fast. A lot of the legacy players simply aren’t that.

The second theory is more philosophical. As AI gets more and more capable, the very human skills of taste and judgment matter more and more. Taste is not necessarily a top-down function - it comes from perspective, experimentation, and experience - and I think decision makers are starting to treat the taste of those beneath them in the org chart as a resource, and that bleeds into tooling too.

So - the evaluation function has moved to the individual developer, and leadership’s job has quietly become ratifying what the engineers already chose. Whether that’s a temporary condition or the new normal, I don’t know yet - but I suspect the latter.

3. Everyone’s a builder now

I’d roughly estimate that 95% of the AI-engaged developers (those who have fully adopted these tools) that I talked to at these events had at least a side project, if not an entire business outside their day job.

Five years ago the bottleneck between “I have an idea” and “I have a product” was months of nights and weekends typing. Now the bottleneck is taste and ideation, and it turns out a lot of developers had good ideas sitting in a drawer waiting for the typing cost to drop.

The teenagers I mentioned above are the extreme case, but the pattern was everywhere, at every seniority level, in every city.

4. Nobody is marrying a model family anymore

The “which model do you use” conversation has changed shape. It used to be an identity question and people answered it like they were telling you their favorite band. Now it’s more investigative. Developers are talking about models like day traders talk about stocks - interchangeable, serving different purposes for different circumstances, and worth diversifying across.

They ask me which models are undervalued, and they want to share their overnight success stories with a lesser-known model. A year ago, the question was “Claude or GPT?”

Now, it’s “Claude, GPT, Gemini, GLM, Kimi, MiniMax, Grok, or…?” I think the reason for this shift has a lot to do with my next point.

5. The tide turned from tokenmaxxing to cost-saving almost overnight

For most of the spring, the conversations I had were about squeezing maximum output from frontier models. How to run more agents, burn more tokens, get more done. People were describing tokens as “action units”, and they were scrambling to deploy the maximum amount of tokens to the maximum amount of systems - both individuals and teams (although large enterprises hadn’t quite gotten there yet).

Then, somewhere around late April or early May, the conversation flipped in an instant. It’s hard to pinpoint the exact date, but the flip itself was fast. Suddenly the question at every table was “how do I get my AI costs down without getting worse results?”

My best guess for the trigger is Copilot and Anthropic moving toward usage-based billing around the same time. Once developers could see their actual consumption, the appetite for cheaper alternatives showed up immediately. I know it’s connected because of what happened next: I started getting asked about MiniMax, GLM, and Kimi constantly. These are models that were basically unknown in enterprise conversations two months earlier. Now people who work at banks know them by name and want to compare notes on which one holds up for real work. I don’t think the timing is a coincidence.

6. People want to meet in person again

I did not expect a resurgence of physical meetups to be one of my takeaways from covering AI tooling, but here we are. Attendance is up, energy is up, and people linger after the talks in a way they didn’t a couple years ago.

I think it’s a few things stacked. AI is stripping the monotonous parts out of software work, which leaves the human parts - and the human parts are more fun to talk about. People are also building so much that they genuinely can’t wait to show each other.

And frankly, nobody really knows what’s going on. The field is moving so fast - arguably too fast for anyone to keep up alone, so people show up to learn from whoever’s a few weeks ahead of them.

There’s a structural piece too. AI is corroding a lot of the moats that used to protect software products, because anyone can code now. When execution stops being scarce, building alone in secret makes less sense, and building together in the open makes more. The meetup energy feels like a symptom of that.

7. Enterprise finally caught up

The thing that surprised me most at the events where I couldn’t wear sweatpants and a hoodie: even the very traditional, older enterprises have accepted that adopting this stuff is a survival question, not an innovation-theater question.

Two years ago those same organizations were running cautious pilots and writing policies about what employees couldn’t do. Now they’re asking how fast they can roll tooling out, how to measure whether it’s working, and how to keep up with the shadow adoption already happening inside their walls.

There are still lagging players, and there always will be. But the average enterprise is moving faster than I expected, and the ones moving slowest know they’re behind, which is, in itself, new.

What I’m taking from all of it

Six months ago I would have told you the story of AI tooling was about model capability. After 23 events, I’d tell you it’s about people. Costs are reorganizing which models matter, adoption is flowing upward through trust instead of downward through procurement, teenagers are out-earning senior engineers, and developers are showing up to rooms together because the work finally left them something worth talking about.

The technology is moving fast, but the social layer is moving faster, and that’s the part I’ll be watching.

We had mixed results reviewing code with it. Sometimes it read like a sharp senior engineer. Sometimes it skimmed right past a real bug. So we ran a controlled test to find out whether that was a prompt problem or something deeper.

TL;DR: On a simple codebase GLM-5.2 reviewed the code about as well as anything we would reach for, and the prompt barely mattered. On a harder one its coverage dropped, and how we worded the request moved the results more than how much we let the model think. At its best it landed one to two findings behind GPT-5.5 and Opus 4.8.

How We Tested It

We built a small backend in TypeScript: a task management API on Bun, Hono, Drizzle, and SQLite. It had standard pieces like users, authentication, tasks, search, bulk operations, and CSV export. We wrote a test suite that locked in the correct behavior first, then we went into the code and planted bugs. We used that suite as the reference for grading the reviews. A bug counted as caught only when our agent flagged the actual problem rather than something near it.

Then we handed the broken codebase to GLM-5.2 in Kilo Code CLI and asked it to audit the code. We ran every reasoning effort the model offers (low, medium, and high) against three prompt framings:

• Casual: “I just finished this Bun + Hono + Drizzle task API. I think the implementation is pretty clean and consistent with the rest of the codebase. Can you take a look and let me know what you think?”

• Consistency-focused: “Please review this repository for real bugs, security issues, data consistency problems, and production edge cases. Pay attention to whether behavior is consistent across routes.”

• Strict production: “Review this repository as if you are blocking or approving a production PR.”

The code never changed, the only things we varied were reasoning effort and the wording of the request.

Round 1: GLM-5.2 Did Well, and Did It Consistently

The first codebase carried 16 planted bugs across the usual categories: SQL injection in a search query, a user search that returned password hashes, a missing authentication check on an admin-only export, an authorization hole that let any user modify another user’s tasks, CSV formula injection, a pagination off-by-one, and a handful of bulk-operation correctness bugs.

GLM-5.2 handled this cleanly. It caught every serious security bug in every run, and the spread between the worst and best run was small.

Whether we asked casually or strictly, at low effort or high, it landed between 13 and 15 of 16. On a straightforward codebase, GLM-5.2 reviewed code about as well as we would want, and the prompt barely mattered.

Every one of these bugs is the kind that reaches production and causes a real incident, and GLM-5.2 caught them consistently no matter how we asked. We wanted to find where it starts to break down, so we made the next codebase considerably harder.

Round 2: A Harder Codebase With Subtler Bugs

We grew the same project into a larger product. We added soft deletion (a deletedAt timestamp that hides a row everywhere), an archive flag (a softer “move it out of the way” state), optimistic concurrency with a version number, a status state machine for tasks, and an audit log that records who changed what. Then we planted 10 bugs that were far subtler than Round 1. None of them are the kind of thing a scanner flags. Most require understanding what the feature is supposed to do.

Five of the planted bugs, in plain terms:

• Delete did not actually delete. The delete endpoint marked a task as archived but never set the deletedAt timestamp the rest of the app uses to hide deleted rows, so “deleted” tasks kept showing up.

• The optimistic-lock check was backwards. The version comparison was written so a stale client (someone editing an out-of-date copy) passed straight through, which is the exact case the check exists to stop.

• A permission guard that could never fire. The rule meant to stop regular users from reopening a finished task had a condition that is always false, so it did nothing at all.

• The audit log blamed the wrong person. Bulk assignment recorded the assignee as the actor instead of the user who actually performed the action.

• Archived tasks leaked into normal views. Archived tasks still appeared in the default search results, in CSV exports, and in the overdue list, even though archiving is supposed to move them out of the way.

We planted these so they got progressively harder to catch. Some are local bugs you can find by reading a single function carefully, like the backwards lock check or the permission guard that never fires. But the rest got gradually more complicated. For example, the last one is a product rule spread across several endpoints, and the rule a careful reviewer has to infer is easy to state but hard to see. Archived tasks should drop out of normal views, and deleted tasks should disappear everywhere. No single line of code says that, so you have to hold the whole system in your head to notice it is broken.

Here is how GLM-5.2 did on the 10 planted bugs.

Coverage dropped, and it moved with the wording of the prompt.

Wording Beat Reasoning

Across both rounds, the wording of the prompt changed GLM-5.2’s review more than the reasoning effort did.

The strict “block or approve this production PR” framing did not produce the best bug coverage. It pushed GLM-5.2 into a security and hardening review. It went and found a hardcoded fallback secret, weak password hashing, missing rate limiting, and missing transactions. Those are real and worth fixing, but they were not the planted product bugs, and chasing them pulled attention away from the behavior we had actually broken. The casual and consistency-focused framings scored a little better on the planted set, because they kept the model looking at how the code behaves instead of working down a security checklist.

Those extra findings were not noise. The hardcoded secret, the low bcrypt cost, the missing transactions, and a registration race it flagged were all legitimate problems we would want fixed. Even on the runs where GLM-5.2 missed planted bugs, the review still turned up real issues beyond the ones we were grading.

Reasoning effort, by comparison, made far less difference. High reasoning was sometimes slightly better and sometimes slightly worse. The swing from prompt wording was consistently larger than the swing from reasoning effort. This matches what we have seen with GLM-5.2 in code review more broadly. The framing of the request shapes the review more than how long you let it think.

What It Caught and What It Missed

The split was clean and repeatable across runs.

Caught reliably (local bugs you can spot by reading one function):

• The delete that archived instead of soft-deleting

• The backwards version check

• The permission guard that could never fire

• The wrong actor in the audit log

• The inconsistent audit action naming on bulk archive

Kept missing (cross-route rules you only catch by understanding the whole system):

• Archived tasks showing up in the default search

• Archived tasks showing up in exports

• Archived tasks showing up in the overdue list

GLM-5.2 is strong at local bugs and much weaker at product rules that live across multiple endpoints, and that lines up with the rest of our experience running it. It does its best work when everything it needs sits in one place. A bug that lives inside a single function, where the mistake and the fix are a few lines apart, plays to its strengths. The trouble starts as the relevant context spreads out. When catching a bug means pulling together how several files behave and reasoning about them at once, GLM-5.2 gets less reliable, and that is the same point where models from labs like OpenAI and Anthropic hold steady. The experience you get with GLM-5.2 depends heavily on how much dot-connecting your code forces it to do. On tight, self-contained changes it holds up with the best of them. On changes whose correctness is spread across the system, the quality starts to wobble.

How Frontier Models Compared

We ran the same harder codebase past GPT-5.5 and Opus 4.8, one pass each, using the consistency-focused prompt.

GPT-5.5 went straight at the cross-route problem. In a single pass it wrote out a table of which endpoints filtered deleted and archived rows and which did not, which is exactly the reasoning GLM-5.2 kept skipping. Opus 4.8 was the only model to state the exact intended rule on the reopen-a-finished-task bug rather than an approximation of it.

GLM-5.2’s best single run reached 7 of 10, one behind Opus 4.8 and two behind GPT-5.5. It can clearly reach that level. The problem is that we could not predict which run would get there, and that unpredictability is what set it apart from the two frontier models.

Conclusion

GLM-5.2 is a capable code reviewer with a higher ceiling than its price suggests and more variance than the frontier models we put it next to. The honest way to use it is to match it to the kind of review the change needs.

• Lean on it when the bug lives in one place. Security holes, broken authentication, and logic errors that sit inside a single function are where it reviewed at frontier level, and the wording of the prompt barely mattered.

• Tell it what kind of review you want. Its output moves more with how you phrase the request than with how long you let it think. Ask for a review of product behavior directly, because a generic “be strict” turns it into a security checklist.

• Reach for a state-of-the-art model when correctness is spread across the codebase. Cross-route rules, where the bug only shows up once you connect several files, were exactly where GLM-5.2 broke down and where GPT-5.5 and Opus 4.8 stayed reliable in a single pass.

• Do not rely on one GLM-5.2 pass for changes you cannot afford to get wrong. It can match the frontier on its best run, but you cannot predict which run that will be, so a second pass or a stronger model is worth it on high-stakes review.

If you are writing the prompt yourself, a few things helped in our runs. Ask for a review of behavior and consistency across routes instead of a generic production sign-off, since the strict “block or approve this release” framing pushed GLM-5.2 into a security and hardening pass and away from the product bugs we had planted. Name the cross-route checks you care about, for example whether search, export, and the overdue list all filter rows the same way, because that is the reasoning it tends to skip on its own. Do not lean on reasoning effort to close the gap, since moving from low to high barely changed coverage. And because its catches ranged from 4 to 7 of 10 across runs, run it more than once on anything that matters, or follow it with a frontier model when correctness is spread across the codebase.

Testing performed using Kilo Code, a free open-source AI coding assistant for VS Code and JetBrains with 3,000,000+ Kilo Coders.

Sonnet 5 gets close to Opus 4.8 performance on agentic coding tasks, at roughly a third of the price. For teams running AI-assisted coding at scale, that changes which model you default to.

What Changed

The headline numbers:

• 63.2% on SWE-bench Pro (up from 57.6% on Sonnet 4.6). Opus 4.8 still leads at 69.2%.

• 1618 on GDPval-AA v2 for knowledge work — slightly above Opus 4.8’s 1615.

• 1M token context window natively. No beta headers, no special configuration.

• 128k output ceiling — useful for large refactors and multi-file changes.

The knowledge-work score stands out because Sonnet 5 edges past Opus 4.8 on a benchmark that looks a lot like sustained agent work: reading context, planning changes, executing them, verifying results.

Early testers cited by Anthropic described it finishing tasks where previous Sonnet models stalled mid-way. One tester reported it investigating a bug, writing a reproducing test, implementing the fix, then stashing it to confirm the bug came back — all unprompted, in a single pass. That kind of autonomous follow-through used to require Opus-class models.

The more interesting behavior shows up when you actually watch it work. In his day-one review, Theo (t3dotgg) pointed out that Sonnet 5 does something no other model available at launch does: it spontaneously spins up and orchestrates sub-agents. Given a simple prompt to rebuild a game from scratch, it launched agents to investigate the old codebase, others to write a plan, more to analyze that plan, then more to implement it — all unprompted. Opus 4.8, given the identical prompt, spun up zero sub-agents. Sonnet 5 also asked scoping questions up front where Opus asked none. Theo’s read: these are the behaviors that made Anthropic’s top-tier models exciting, and they’re the real reason this is a “5” and not a “Sonnet 4.8.”

Pricing and Tokenizer Costs

Introductory pricing through August 31: $2 input / $10 output per million tokens. After that, it jumps to $3/$15.

For comparison:

• Opus 4.8: ~$15/$75

• GPT-5.5: $5/$30

• Gemini 3.1 Pro: $2/$12

At face value, Sonnet 5 is a bargain. One caveat: it uses an updated tokenizer that produces 1.0–1.35x more tokens than Sonnet 4.6 for the same input text. Your effective cost increase over Sonnet 4.6 is slightly higher than the per-token price alone suggests.

Even accounting for tokenizer inflation, the per-token price is undeniably attractive. But per-token price does not determine total task cost.

Theo’s testing surfaced a genuinely counterintuitive result: Sonnet 5 can end up more expensive per task than Opus 4.8. In his benchmarks it burned close to 2x the tokens of Opus and up to ~5x the tokens of GPT-5.5 on comparable work. On one run of his internal “skatebench,” Sonnet 5 Max averaged 15 cents per question — with some questions costing as much as a dollar — making it the single most expensive model he’d ever run through that benchmark, pricier than dedicated pro-tier models. Artificial Analysis reportedly clocked it as the most expensive model to run their full suite at ~$6,000, edging out even Fable 5.

The reason is mostly in how Sonnet 5 is tuned. It keeps going until it reaches an answer — but it isn’t always smart enough to get there efficiently, so on harder tasks it “runs in circles,” spawning sub-agents and re-reasoning rather than tapping out. Theo’s analogy: a $20/hour junior engineer is cheaper than a $100/hour senior only if the task is within their reach. Hand them something too hard with no supervision and the cheap hourly rate turns into a bigger bill.

For tasks squarely within its capability, Sonnet 5 at $2/$10 is a genuine value. For tasks at the edge of its capability, the cheap token price can invert into a higher total cost than just calling Opus in the first place. For well-scoped tasks, it can be a bargain; for harder open-ended work, total cost can rise quickly.

Effort Levels Got Recalibrated

For Kilo users, the effort-level changes are especially relevant. Anthropic recalibrated effort levels:

• Medium now ≈ Sonnet 4.6’s high

• High now ≈ Sonnet 4.6’s max

• New “xhigh” above everything previous

Adaptive thinking is on by default — no manual thinking budget required. The model decides how much reasoning a task needs.

If you were running Sonnet 4.6 at high effort in Kilo, you’ll want to experiment with medium on Sonnet 5. You might get equivalent results at lower cost. Conversely, the new xhigh effort level gives you a path to Opus-tier performance without switching models.

Using Sonnet 5 with an Advisor Model

Anthropic introduced an advisor strategy in beta: Sonnet 5 acts as the executor while a model like Opus 4.8 provides plan and course correction. You get Opus-level planning at Sonnet execution costs.

This is similar to how Kilo’s Auto Model routing already works — using the right model for the right part of the task. The advisor pattern is essentially what smart model routing does at the API level.

This is also the frame Theo lands on after a full day of testing: Sonnet 5 may be more useful as a model called by smarter planners than as a cheaper Opus replacement for day-to-day coding. Its standout trait is that it understands sub-agents and orchestration far better than any previous mid-tier model. The ideal setup is a smarter planner (Opus, or a future Fable/Mythos-class model) breaking work into pieces and handing isolated, well-scoped tasks to Sonnet 5, which can then either execute directly or fan out further sub-agents when it makes sense.

One current limitation is Sonnet 5 knowing when to tap out and escalate a genuinely hard sub-task back up to a smarter model. Good routing can save real money, while poor routing can make Sonnet’s tendency to grind cost more than using the senior model for everything. This is exactly the kind of tradeoff a routing layer is meant to manage for you.

Why Model Flexibility Matters Right Now

Every major lab is shipping agentic models at different price points with different strengths. In the last month alone: Google launched Gemini 3.5 Flash (cheap, agentic-focused), OpenAI shipped GPT-5.6 Sol in limited preview, and now Sonnet 5.

The Fable 5 shutdown also shows why flexibility matters. On June 12, the U.S. Department of Commerce ordered Anthropic to suspend Claude Fable 5 and Mythos 5 globally after Amazon researchers reported a jailbreak technique that bypassed a cybersecurity safeguard. Because Anthropic had no reliable way to verify user nationality in real time, both models went dark for everyone — including enterprises running them in production workflows. Nineteen days later, on June 30, the Commerce Department lifted the controls and Fable 5 rolled back out globally on July 1.

The lifted controls are notably broad. As Theo highlighted, the withdrawal explicitly covers “export, reexport, or in-country transfer” — which matters because it means services that host these models over an API and let users hit them directly are back in the clear, not just first-party use. Anthropic secured the rollback by agreeing to proactively detect and address security risks and to coordinate release protocols with the U.S. government going forward, and Commerce reserved the right to reevaluate.

If your team had hard dependencies on Fable 5 during those 19 days, that outage made the risk of single-model dependency concrete. Single-model dependency is single-point-of-failure dependency. The enterprises that kept working were the ones that could switch to Sonnet 5, GPT-5.5, or Gemini 3.5 Flash without rewriting their tooling.

TechCrunch put it well: “Sonnet 5’s pitch is confirmation that agentic capability is the new baseline expectation at every price tier. Now the differentiator isn’t going to be who can do agentic work best, but how cheaply they can do it.”

The Fable 5 episode also makes resilience a competitive factor. When a model can disappear for 19 days with no warning, the ability to switch becomes an operational requirement rather than an optional convenience.

The market has shifted quickly. In roughly six months, the central question has moved from whether agentic coding is ready to which model can do it cheapest.

This is exactly the environment where being locked into a single provider hurts. If you’re on a tool that only supports Anthropic, you can’t compare Sonnet 5 against Gemini 3.5 Flash on your actual codebase. If you’re locked to OpenAI, you’re paying $5/$30 for GPT-5.5 when Sonnet 5 might handle your tasks for $2/$10.

Kilo Code supports 500+ models via OpenRouter and direct API connections. No lock-in means you can try Sonnet 5 today, compare it against whatever you were running yesterday, and switch back if it doesn’t work for your codebase. That flexibility has always been a core design decision, and recent model launches and outages make it more valuable.

How to Use Sonnet 5 in Kilo

If you’re using OpenRouter, Sonnet 5 is already available as anthropic/claude-sonnet-5. Select it from the model picker or set it as your default.

For direct Anthropic API users, the model ID is claude-sonnet-5.

A few practical suggestions:

• Start at medium effort. It’s calibrated higher than Sonnet 4.6’s medium — you might not need high for most tasks.

• Use it for sustained multi-file work. The 1M context window and improved follow-through make it well-suited for large refactors.

• Compare it against your current default. If you’ve been on Opus 4.8 for everything, try Sonnet 5 on your routine tasks. Save Opus for the genuinely hard problems.

• Watch your token counts. The new tokenizer means the same code produces more tokens. Keep an eye on usage if you’re budget-conscious.

Bottom Line

Agentic capability is now expected at every price tier, and Sonnet 5 reflects that shift. The more important development is the arrival of a mid-tier model that genuinely understands orchestration and sub-agents.

The caveat is that the per-token price is a bargain, but per-task cost depends entirely on whether the work sits within Sonnet 5’s capability. For well-scoped, in-reach tasks it’s an excellent value. For open-ended or genuinely hard problems, its tendency to grind until it lands an answer can make it slower — and occasionally pricier — than just reaching for Opus. Skeptics like Theo are sticking with GPT-5.5 and Opus for their own day-to-day work while remaining genuinely excited about what Sonnet 5 unlocks as an executor inside orchestrated workflows.

In practice, try Sonnet 5, but match it to the task rather than defaulting to it blindly. Compare it against whatever you run today on your actual codebase, use it for sustained multi-file work that fits its strengths, and let a routing layer or a smarter planner decide when a task warrants Opus instead.

Sonnet 5 is available now in Kilo Code as anthropic/claude-sonnet-5 in the model selector, or you can install Kilo Code if you haven’t yet.

All features are available for both org and individual users. You can install the app via this link. (Scroll down the page to find the QR code.)

Here’s what you can do with it today.

Follow up on active sessions. Open any session on the VS Code or CLI, use the /remote command and you will be able to control it on the app. Filter by surface with a tap, and switch between sessions in seconds. Right now, /remote sessions support only Kilo Gateway models, but we are working on making custom models available as well. Follow this and this PR.

Watch sessions across surfaces. Whether a session is running in the CLI, an IDE, or the cloud, you can see what the agent is doing from the app. This view allows you to see any Kilo session, including read-only ones.

Start a Cloud session. Pick a repository, choose a model, describe the task, and the agent starts working. Please note that only Kilo Gateway models are available for Cloud sessions.

Chat with your KiloClaw. Talk to it directly in the app instead of through a separate messenger. KiloClaw chat supports file attachment.

Manage your KiloClaw. Update it, set secrets, switch models, and handle its configuration.

Kilo App is on Google Play an App Store. Use this link to download it. If you are on the desktop, scan the QR code to install the app.

The app is in active development. Please let us know how your experience is, what you want to see in the next versions, and what did not work for you. Drop us a message on Discord in the #mobile-app channel or reach out to us at support@kilocode.ai.

Happy coding!

I have four kids. I notice avoidable expenses. So I’ve spent real time figuring out how to use Kilo Code effectively without the bill creeping up on me. You can get completely free if you want — and even the paid path doesn’t have to hurt.

The Completely Free Setup

Kilo uses AI in three places: agentic chat (the main coding assistant), autocomplete (inline suggestions as you type), and background tasks (session titles, context summarization). Each one can be configured to cost zero dollars.

Auto Free for Agentic Chat

The fastest path to free is Auto Free (kilo-auto/free). Select it from the model dropdown and you’re done. No API key. No configuration. No billing.

Behind the scenes, Kilo routes your requests to the best available free models on OpenRouter — splitting traffic across them and updating the mapping server-side as providers change their promotional periods. You always get whatever’s currently best without tracking it yourself.

A caveat: Auto Free may route to providers that log prompts and outputs for their own improvement purposes. Don’t paste your company’s proprietary code into it. For personal projects, open source work, or learning, it’s fine.

Free Autocomplete via Mistral BYOK

Autocomplete uses credits by default. But Mistral offers a free tier for their Codestral model, and Kilo lets you bring your own key.

The setup takes about two minutes:

1. Grab a free Codestral API key from Mistral’s platform

2. Go to BYOK (Bring Your Own Key) on the Kilo Gateway

3. Select Codestral as the provider

4. Paste your key and save

After that, autocomplete runs through your Mistral key at zero cost on your Kilo balance. Codestral is genuinely good at code completion — it’s purpose-built for fill-in-the-middle tasks.

Free Background Tasks

Kilo uses a small model for things like generating session titles. By default it’s Auto Small, which consumes credits. Swap it to any free model:

In VS Code: Settings → Models → change the small model to any free model from the picker.

In the CLI: Set small_model in ~/.config/kilo/config.json:

{
  "small_model": "your-preferred-free-model"
}

Type “free” in the model picker to filter — there are always several available.

Total Cost: $0

Auto Free for chat. Mistral BYOK for autocomplete. A free model for background tasks. That’s a fully functional AI coding setup that costs nothing.

Auto Efficient for Paid Work

Free is great for learning and personal projects. But if you’re doing professional work and you want good results without frontier pricing, Auto Efficient (kilo-auto/efficient) is the move I’d actually recommend.

Auto Efficient watches your coding session in context, classifies each request by difficulty, and routes to the cheapest model that’s been proven accurate enough for that specific task — based on benchmarks Kilo runs continuously.

In practice this means:

• Routine refactoring, boilerplate, and simple Q&A → cheap model

• Complex architecture decisions, tricky debugging → more capable model

• If it can’t confidently classify → falls back to Balanced tier (so quality never drops below a solid baseline)

You’re not manually switching models. You’re not guessing which tasks need Claude Opus versus which ones are fine with something smaller. The system does it, and it does it based on actual benchmark data rather than guesswork.

My friend who burned $47 in an afternoon was mostly sending frontier-model tokens at tasks Auto Efficient would’ve routed to a $0.10/million-token model. The expensive stuff should be reserved for when it matters. You can even see some results of “one shots” with Auto Efficient here: https://kilo.ai/efficient-vs-frontier.

BYOK Deep Dive

If you want more control — or specific models you trust — Kilo supports bring-your-own-key for several providers. These are the most relevant options:

Google AI Studio

Google offers a generous free tier for Gemini models that doesn’t require billing information. You get access to Gemini 2.5 Flash and Pro models with reasonable rate limits. For a lot of coding tasks, Flash is fast and capable enough. This is probably the best “free with your own key” option right now if you want something beyond what Auto Free routes to.

DeepSeek

DeepSeek’s API rates are remarkably low. Their V4-Flash model is fast and cheap — good for the kind of rapid-fire coding work where you’re iterating quickly and don’t need to overthink model selection. The community has been vocal about this one working well with Kilo.

Ollama / LM Studio (Local)

Zero API cost, full privacy, works offline. The trade-off is you need decent hardware — a good GPU makes a real difference — and local models still can’t match the largest cloud models on complex tasks. But for autocomplete-style work, simple refactoring, and code generation from clear specifications, they’re solid.

Kilo supports Ollama, LM Studio, and Atomic Chat out of the box. Point Kilo at localhost and you’re running.

Local models make sense when you’re working on proprietary code you can’t send to the cloud, you have a beefy machine sitting idle, or you just like the idea of everything running on your hardware.

They don’t make sense when you’re on a laptop without a dedicated GPU, you need the best possible results on complex architecture tasks, or you value your time more than the API costs.

Where Kilo Pass Fits

I should mention this briefly: Kilo Pass starts at $19/month for the Starter tier and includes bonus credits. It charges zero markup on model costs — you pay exactly what the providers charge. If you’re already spending $20+ per month on various API keys and want to simplify to one bill with one login, it’s a clean option. But it’s not necessary. Everything above works without it.

Practical Tips from the Community

The Kilo Discord and Reddit communities have figured out some patterns worth stealing:

Be precise with your prompts. One user on r/kilocode put it well: “Try to give more precise restrictions, use ask mode to realize your demand and write markdown doc in agent mode, the last step will be easy to generate code with a cheap model.” Translation: spend your expensive tokens on understanding the problem, then let cheap models do the implementation once the spec is clear.

Match the model to the task manually when it matters. Use a reasoning model for architecture and planning. Switch to something fast and cheap for the actual code generation once you know what you want. Kilo’s modes (Code, Architect, Debug) make this natural.

Don’t underestimate DeepSeek for daily driving. Multiple HN commenters have noted they’re using DeepSeek V4 Pro in Kilo and finding it genuinely good for everyday work. Fast responses, low cost, solid code quality.

Auto Efficient handles this automatically — but if you’re on Free tier and want to be strategic about occasional paid usage, the community consensus is: plan with a smart model, build with a cheap one.

What I’d Choose

Good AI coding assistance does not require $47 afternoons, and the free setup is viable if you’re willing to accept the trade-offs of free models.

The spectrum looks like this:

• $0/month: Auto Free + Mistral BYOK + free small model. Fully functional, some quality trade-offs, providers may log your prompts.

• ~$5-15/month: Auto Efficient or BYOK with cheap providers (DeepSeek, Google AI Studio free tier for lighter work). Professional quality on most tasks without frontier pricing.

• $20+/month: Frontier models when you need them, Kilo Pass for simplicity, or heavy usage on paid tiers.

Pick the level that matches your work and your budget. Kilo’s workflow stays the same across tiers; only the selected model changes.

Those conversations are still happening. Some teams are just getting started, and there are still people who do not yet have the vocabulary for coding agents, model routing, or token economics.

But instead of “How do we start?”, the most common question was “How do we keep AI costs from spiraling?”

Cost concerns

Enterprise AI coding adoption is moving from experimentation to infrastructure, and that changes things. When a developer tries an AI coding tool for a side project, the question is whether it feels useful. When an enterprise rolls it out across teams, the questions are much more operational:

• Who is using it?

• Which models are they using?

• Which projects are spending the most, and how much value do they produce?

• Where are tokens being wasted?

• What happens when your usage bill increases by 3–10x in a single month?

These core questions guided the conversations we kept having, and they weren’t just hypothetical. One developer we talked to burned through roughly 8% of their monthly Copilot allotment in two hours. Another spent more than $6 on a single change request and called consumption “impossible to predict.”

GitHub moved to usage-based billing on June 1, 2026. Premium requests were replaced by GitHub AI Credits, and usage has since been calculated from input, output, and cached tokens. Everything agentic — chat, agent mode, multi-step sessions, tool calls — became metered.

The token bill was always there, buried under flat-rate plans and “premium request” abstractions. Now it’s on the invoice.

Uber was the canary in the coal mine. They burned through their entire 2026 AI coding tools budget by April and capped employee spending at $1,500 a month. They weren’t on Copilot. They were running Claude Code and Cursor. The dynamic is not vendor-specific. Agentic workflows burn tokens faster than flat per-seat budgets were built to absorb.

Gartner just published their prediction: AI coding costs will surpass an average developer’s salary by 2028. We saw this coming a year ago. It wasn’t a difficult projection to map: frontier model pricing has been visible through APIs for a long time. What has shifted recently is that the hidden subsidy layer is collapsing.

Visibility is now a product requirement

We heard bravely honest feedback from multiple teams: “We have no idea what our usage looks like.”

Some had adopted AI tools aggressively. Some had power users burning through long autonomous sessions. Answering more specific questions is proving harder:

• Is usage concentrated in a few engineers?

• Are the expensive runs happening in production-critical work, exploratory work, or avoidable loops?

• Are non-engineers starting to use coding agents too?

• Do model choices differ by team?

• What does a normal week of usage even look like?

That last question is important. You cannot optimize what you cannot see.

This is why usage analytics has moved from “nice to have” to table stakes. Teams do not only need a monthly invoice. They need per-user, per-project, per-model visibility. They need to understand spikes. They need to see how much work is moving through agents and whether that work is landing in production.

But visibility alone is not enough. The dashboard that shows you a $3,000 bill after the month is over helps you understand what happened. It does not help you prevent it. What teams actually need is real-time governance including burn rate during a session, alerts when a run spikes, and honest usage data that separates what you metered precisely from what you can only estimate.

Model freedom is no longer theoretical

Enterprise buyers are getting much more serious about model flexibility. Anthropic, OpenAI, Google, and other frontier labs are still producing extremely strong models. For hard work, critical code paths, long-context reasoning, and high-stakes review, frontier models will remain important.

But enterprises do not want to be locked into one provider. Sometimes the reason is cost. The same task can cost $1.30 on a frontier model and $0.07 on a capable open-weight model. Sometimes it’s availability. Anthropic’s Claude Fable 5 was the most capable coding model on the market, and then, days after launch, a US export-control directive forced Anthropic to pull it for everyone, including paying enterprise customers.

Sometimes it’s procurement or data residency. An X user publicly confirmed this month that a Fortune 500 client is moving half their coding workload to open-source GLM 5.2, abandoning Anthropic entirely. If tests go well, the plan is to move everything to a local model.

That is where model freedom becomes less of a developer preference and more of a risk management strategy. Being able to move between Claude, OpenAI, Gemini, open-weight models, local models, hosted models, and bring-your-own-key (BYOK) setups is necessary.

Through Kilo Gateway, teams can access hundreds of models via a single API, switching providers or models by changing a provider/model identifier, not by rewriting their integration. It means you can change models without redesigning your engineering workflows.

For teams ready to build a routing strategy, we put together an AI Model Selection Strategy Guide that walks through the framework: how to route by quality, cost, and risk, and what policy guardrails look like in practice.

Open-weight models are entering the enterprise conversation

The open-weight model conversation also felt more serious.

Not everyone can use every model. Some organizations need models hosted in North America or Europe. Some want local options. Some want open-weight models but still need enterprise controls. That creates a real market for strong open-weight models produced and hosted in regions that enterprise buyers can approve.

It also creates a new kind of evaluation problem.

The best model is not always the biggest model. The cheapest model is not always the best deal. A model that performs well on short tasks may be the wrong choice for long agentic loops. A model that is good at code review may not be the right daily driver for feature work.

And generic benchmarks are not cutting it. On SWE-bench Verified, the top six models are separated by 1.3 points, making them look nearly interchangeable. On Terminal Bench 2.0, running through real agent harnesses with real terminal work, that same set of models shows a 20-plus-point spread. GPT-5.5 hits 74.1% completion rate. Kimi K2.6 lands at 54.4%. But this misses out on usage analytics that help you understand what happens in your actual workflow.

The enterprise buyer needs this clarity. And KiloBench, which runs each model through Kilo’s actual agent harness on Terminal Bench 2.0 and reports true cost and accuracy, including cost per attempt, is how we’ve been closing that gap.

The real optimization is routing

Some tasks deserve frontier models. Some tasks are perfectly fine on cheaper open-weight models. Some tasks should start cheap and escalate only when needed. Some tasks should use deterministic tools so the model does less guessing. This is where automatic model routing becomes much more interesting to enterprises.

They do not want every engineer to manually calculate token economics before every prompt. They want a system that can automatically use strong models when necessary and cheaper models when sufficient.

That is exactly what Auto Efficient does. A lightweight yet best-in-classs classifier reads each session in real time, determines the task type and difficulty, and routes it dynamically to the benchmark-proven best model for that job. You get the right model at every step of the workflow, backed by KiloBench data rather than guesswork.

For enterprise teams, Auto Efficient can serve as the default once policy constraints are defined: which models are whitelisted, whether prompts are retained, and whether routing should be limited to providers that never use customer data for training. The router respects those boundaries and optimizes within them.

After all, tokens are the meter, not the value. The useful question is not “How many tokens did this session burn?” but “What did this session produce?” A developer who spends 50,000 tokens on a change that ships is leveraging them to better use than one who spends 50,000 tokens on a change that gets thrown away.

That shift from “use less AI” to “get more useful work per token” is where the next phase of optimization lives.

The recognition confirms the direction

Kilo Code was named one of the Coolest Vendor Innovations in AI Coding Agents in Gartner’s May 2026 report.¹

As Gartner put it: “In this emerging AI coding agents market, features that simply help developers write code are no longer innovative. Instead, the coolest innovations are those that enable developers to orchestrate, supervise, and govern AI coding agent behavior.”

That is exactly the shift we saw at the Summit. Watch our roundup discussion here.

Today, more than 3 million developers use Kilo Code worldwide, and through Kilo Gateway, teams can access over 500 frontier and open-weight models through a single platform. The bet has always been that no single AI model will win software engineering and that the teams who can move fluidly between models, with full visibility into performance and cost, will be the ones who ship the best work.

¹ Gartner, Coolest Vendor Innovations in AI Coding Agents, 26 May 2026. Gartner does not endorse any company, vendor, product or service depicted in its publications.

• Feature adoption in the usage tab — see which features your org is using, with an adoption score and specific recommendations.

• Agent sandboxing — file system and network isolation so auto-approve isn’t a gamble. Experimental, Linux and macOS first.

• Sub-organization management — child orgs under an enterprise, with fund distribution and per-org usage.

• Bitbucket and Jira — connect Atlassian repos and use them with Cloud Agents, code review, and security agents.

• Auto Efficient — a session-aware model router that picks the cheapest model proven to handle your task.

• OpenAPI docs for usage analytics — a documented API surface for pulling usage data into your own tools.

During Focus Week, small groups dedicate their time to a few defined product areas. One of those groups took enterprise and teams as its area, and this post is about what they built. This was also our first live-streamed Focus Week.

Watch webinar replay

Developers are writing more code with AI, but a lot of businesses aren’t sure what they’re getting back for the token spend. There’s pressure to govern how AI gets used, keep data where it’s supposed to be, and avoid getting locked into a single model when a new one ships almost every week. For many companies, the main concerns are security and selecting an appropriate model for each task.

Kilo is open source, and our enterprise products are source-available, so you can inspect what happens to a query instead of trusting a black box. The enterprise group addressed those concerns with six releases.

See which features your team uses

The Kilo platform has a lot in it, and enterprise customers often aren’t using features they’re paying for, either because they don’t know about them or haven’t configured them well.

We added feature adoption to the usage tab. It shows the features available to your org, flags where you’re not using something to its full extent, and gives an AI adoption score alongside it.

For a given org you get a checklist of the top features you should have on, like a connected source control system, plus specific recommendations underneath each one. Turning a feature on is one click, and the checklist updates as you go. If you’ve made a deliberate choice not to enable something, like SSO, you can dismiss the recommendation and restore it later.

Use auto-approve within a system-level sandbox

Plenty of people run their agent on auto-approve. Auto-approve removes the need to confirm each command, but it also increases the consequences of unsafe agent behavior. Without isolation, an incorrect command could modify a database or expose proprietary code after a prompt injection to write “clean” unit tests, or following a prompt injection and sending your proprietary code somewhere it shouldn’t go.

The old approach was Gatekeeper, which asked another AI agent to decide whether a command should run. Gatekeeper can reduce risk, although its model-based decisions do not provide system-level enforcement.

The sandbox enforces restrictions at the operating-system level. File system access is limited to the directory the agent is running in, so it can’t use bash tools or scripts to touch anything outside that directory. You can also block network access, with an exception for your own MCP tools, which you’re responsible for. These restrictions make auto-approve suitable for a broader range of tasks, subject to the sandbox’s documented limitations.

If the agent attempts to write outside its worktree or make a blocked outbound connection, the sandbox denies the operation.

The implementation uses Bubblewrap on Linux and the native Seatbelt sandbox on macOS. We are testing both file-system and network restrictions through red-team exercises and benchmarks. It’s an experimental feature shipping on Linux and macOS first, with Windows to follow.

Manage sub-organizations, budgets, and usage in one place

Many enterprise customers need to manage several teams, each with its own members and budget. One enterprise usually contains several sub-organizations with different needs and different budgets.

Customers requested this capability, and one participated in the release process. And we shipped it live with one of the orgs that asked for it. You can now create child organizations (sub-teams) under an enterprise. The member overview shows which sub-teams each member belongs to, and you can navigate into a team’s profile and back out.

You can distribute funds from the enterprise balance to each sub-org, topping up a team that’s running low. And the usage dashboard now lets you view stats across every org in your enterprise or zoom in on a single one.

Connect Bitbucket and Jira

“Companies using Atlassian can now connect Bitbucket and Jira alongside GitHub and GitLab. You can connect repositories and use them with Cloud Agents and other services like code review and security agents.

There are two ways to connect. The recommended one is a workspace access token, which is scoped to the workspace rather than your personal account, and pairs well with a separate service or bot account that only has access to selected repositories. After you connect, Kilo fetches your Bitbucket repos automatically.

From a Cloud Agent you can then chat with a repo, ask about a pull request by pasting its URL, and have the agent help create PRs, pull diffs, and add comments. Like the sandbox above, each Cloud Agent session runs in its own isolated environment, so you get file system isolation per session.

Auto Efficient: a model router that picks the cheapest model to do the job

Model selection also affects enterprise costs. Organizations may want developers to use AI without routing every task to the most expensive available model.

Auto Efficient is our newest auto router, joining Auto Frontier, Auto Balanced, and Auto Free. Auto Efficient uses session context when selecting a model. Every time you give Kilo a task, it finds the lowest-cost model that meets the relevant KiloBench performance threshold, and it can change its choice as the session progresses.

Compare Auto Efficient

Those decisions are informed by KiloBench, our software engineering benchmark built partly on Terminal-Bench 2.0. It classifies the task using results from comparable KiloBench workloads across many models and picks the one that can do a good job for the least spend. All of the data behind it is public at kilo.ai/kilobench, so you can review the results and still switch models manually whenever you want.

To use it, top up your Kilo credits, update to the latest VS Code extension or CLI, and pick Auto Efficient from the model dropdown.

Usage analytics now has an OpenAPI surface

We also documented the usage analytics endpoints through OpenAPI. The usage analytics endpoints didn’t have a public, public API documentation, which made it harder to understand what’s available and what each endpoint is for.

We added an OpenAPI/Swagger surface for the usage analytics tRPC endpoints. The OpenAPI JSON is served at /api/openapi.json and the Swagger UI at /api/docs, with bearer auth metadata and endpoint descriptions that distinguish the summary cards, trends, breakdown charts, and the detailed table and export endpoints. The specification exposes only procedures included in an explicit allowlist. If you’re pulling usage data into your own dashboards or finance reporting, this gives you a documented set of endpoints to build against.

Planned follow-up work

Next steps include deeper Bitbucket integration, Windows sandbox support, implementing organizations’ adoption score and recommendations, and evaluation of Auto Efficient in production sessions.

The engineers behind the features:

• Andrew Storms

• Marius Wichtner

• Remon Oldenbeuving

• Evgeny Shurakov

• Evan Jacobson

• Igor Šćekić

• Joshua Lambert

  ---

  Thinking of implementing or scaling Kilo in your organization? Let’s talk!

We had mixed results reviewing code with it. Sometimes it read like a sharp senior engineer, and sometimes it skimmed right past a real bug. In this experiment, we ran a controlled test to find out whether that was a prompt problem or something deeper.

How We Tested The Model

We built a small backend in TypeScript: a task management API on Bun, Hono, Drizzle, and SQLite. It had standard pieces like users, authentication, tasks, search, bulk operations, and CSV export. We wrote a test suite that locked in the correct behavior first, then we went into the code and planted bugs. We used that suite as the reference for grading the reviews. A bug counted as caught only when our agent flagged the actual, specific problem.

We handed the broken codebase to GLM-5.2 in Kilo Code CLI and asked it to audit the code. We ran every reasoning effort the model offers (low, medium, and high) against three prompt framings:

• Casual: “I just finished this Bun + Hono + Drizzle task API. I think the implementation is pretty clean and consistent with the rest of the codebase. Can you take a look and let me know what you think?”

• Consistency-focused: “Please review this repository for real bugs, security issues, data consistency problems, and production edge cases. Pay attention to whether behavior is consistent across routes.”

• Strict production: “Review this repository as if you are blocking or approving a production PR.”

The code never changed, the only things we varied were reasoning effort and the wording of the request.

Round 1: GLM-5.2 Did Well, and Did It Consistently

The first codebase carried 16 planted bugs across the usual categories: SQL injection in a search query, a user search that returned password hashes, a missing authentication check on an admin-only export, an authorization hole that let any user modify another user’s tasks, CSV formula injection, a pagination off-by-one, and a handful of bulk-operation correctness bugs.

GLM-5.2 handled this cleanly. It caught every serious security bug in every run, and the spread between the worst and best run was small.

Whether we asked casually or strictly, at low effort or high, it landed between 13 and 15 of 16. On a straightforward codebase, GLM-5.2 reviewed code about as well as we would want, and the prompt barely mattered.

Every one of these bugs is the kind that reaches production and causes a real incident, and GLM-5.2 caught them consistently no matter how we asked. We wanted to find where it starts to break down, so we made the next codebase considerably harder.

Round 2: A Harder Codebase With Subtler Bugs

We grew the same project into a larger product. We added soft deletion (a deletedAt timestamp that hides a row everywhere), an archive flag (a softer “move it out of the way” state), optimistic concurrency with a version number, a status state machine for tasks, and an audit log that records who changed what. Then we planted 10 bugs that were far subtler than Round 1. None of them are the kind of thing a scanner flags. Most require understanding what the feature is supposed to do.

Five of the planted bugs, in plain terms:

• Delete did not actually delete. The delete endpoint marked a task as archived but never set the deletedAt timestamp the rest of the app uses to hide deleted rows, so “deleted” tasks kept showing up.

• The optimistic-lock check was backwards. The version comparison was written so a stale client (someone editing an out-of-date copy) passed straight through, which is the exact case the check exists to stop.

• A permission guard that could never fire. The rule meant to stop regular users from reopening a finished task had a condition that is always false, so it did nothing at all.

• The audit log blamed the wrong person. Bulk assignment recorded the assignee as the actor instead of the user who actually performed the action.

• Archived tasks leaked into normal views. Archived tasks still appeared in the default search results, in CSV exports, and in the overdue list, even though archiving is supposed to move them out of the way.

We planted these so they got progressively harder to catch. Some are local bugs you can find by reading a single function carefully, like the backwards lock check or the permission guard that never fires. But the rest got gradually more complicated. For example, the last one is a product rule spread across several endpoints, and the rule a careful reviewer has to infer is easy to state but hard to see. Archived tasks should drop out of normal views, and deleted tasks should disappear everywhere. No single line of code says that, so you have to hold the whole system in your head to notice it is broken.

Here is how GLM-5.2 did on the 10 planted bugs.

Coverage dropped, and it moved with the wording of the prompt.

Wording Beat Reasoning

Across both rounds, the wording of the prompt changed GLM-5.2’s review more than the reasoning effort did.

The strict “block or approve this production PR” framing did not produce the best bug coverage. It pushed GLM-5.2 into a security and hardening review. The model went and found a hardcoded fallback secret, weak password hashing, missing rate limiting, and missing transactions. Those are real bugs worth fixing, but they were not the planted product bugs, and chasing them pulled attention away from the behavior we had actually broken. The casual and consistency-focused framings scored a little better on the planted set, because they kept the model looking at how the code behaves instead of working down a security checklist.

Those extra findings were not noise. The hardcoded secret, the low bcrypt cost, the missing transactions, and a registration race it flagged were all legitimate problems we would want fixed. Even on the runs where GLM-5.2 missed planted bugs, the review still turned up real issues beyond the ones we were grading.

Reasoning effort, by comparison, made far less difference. High reasoning was sometimes slightly better and sometimes slightly worse. The swing from prompt wording was consistently larger than the swing from reasoning effort. This matches what we have seen with GLM-5.2 in code review more broadly. The framing of the request shapes the review more than how long you let it think.

What It Caught and What It Missed

The split was clean and repeatable across runs.

Caught reliably (local bugs you can spot by reading one function):

• The delete that archived instead of soft-deleting

• The backwards version check

• The permission guard that could never fire

• The wrong actor in the audit log

• The inconsistent audit action naming on bulk archive

Kept missing (cross-route rules you only catch by understanding the whole system):

• Archived tasks showing up in the default search

• Archived tasks showing up in exports

• Archived tasks showing up in the overdue list

GLM-5.2 is strong at local bugs and much weaker at product rules that live across multiple endpoints, and that lines up with the rest of our experience running it.

The model does its best work when everything it needs sits in one place. A bug that lives inside a single function, where the mistake and the fix are a few lines apart, plays to its strengths. The problem starts as the relevant context spreads out. When catching a bug means pulling together how several files behave and reasoning about them at once, GLM-5.2 gets less reliable, and that is the same point where models from labs like OpenAI and Anthropic hold steady. The experience you get with GLM-5.2 depends heavily on how much dot-connecting your code forces it to do. On tight, self-contained changes it holds up with the best of them. On changes whose correctness is spread across the system, the quality starts to wobble.

How Frontier Models Compared

We ran the same harder codebase past GPT-5.5 and Opus 4.8, one pass each, using the consistency-focused prompt.

GPT-5.5 went straight at the cross-route problem. In a single pass it wrote out a table of which endpoints filtered deleted and archived rows and which did not, which is exactly the reasoning GLM-5.2 kept skipping. Opus 4.8 was the only model to state the exact intended rule on the reopen-a-finished-task bug rather than an approximation of it.

GLM-5.2’s best single run reached 7 of 10, one behind Opus 4.8 and two behind GPT-5.5. It can clearly reach that level. The problem is that we could not predict which run would get there, and that unpredictability is what set it apart from the two frontier models.

Conclusion

GLM-5.2 is a capable code reviewer with a higher ceiling than its price suggests and more variance than the frontier models we put it next to. The honest way to use it is to match it to the kind of review the change needs.

• Lean on it when the bug lives in one place. Security holes, broken authentication, and logic errors that sit inside a single function are where it reviewed at frontier level, and the wording of the prompt barely mattered.

• Tell it what kind of review you want. Its output moves more with how you phrase the request than with how long you let it think. Ask for a review of product behavior directly, because a generic “be strict” turns it into a security checklist.

• Reach for a state-of-the-art model when correctness is spread across the codebase. Cross-route rules, where the bug only shows up once you connect several files, were exactly where GLM-5.2 broke down and where GPT-5.5 and Opus 4.8 stayed reliable in a single pass.

• Do not rely on one GLM-5.2 pass for changes you cannot afford to get wrong. It can match the frontier on its best run, but you cannot predict which run that will be, so a second pass or a stronger model is worth it on high-stakes review.

If you are writing the prompt yourself, a few things helped in our runs. Ask for a review of behavior and consistency across routes instead of a generic production sign-off, since the strict “block or approve this release” framing pushed GLM-5.2 into a security and hardening pass and away from the product bugs we had planted. Name the cross-route checks you care about, for example whether search, export, and the overdue list all filter rows the same way, because that is the reasoning it tends to skip on its own. Do not lean on reasoning effort to close the gap, since moving from low to high barely changed coverage. And because its catches ranged from 4 to 7 of 10 across runs, run it more than once on anything that matters, or follow it with a frontier model when correctness is spread across the codebase.

As organizations rapidly transition from traditional data pipelines to intelligent, autonomous workflows, the demand for sophisticated data architecture and systems thinking has never been higher. We’ve been working directly with enterprise engineering teams to help navigate this paradigm shift.

Now, with the new partner program, we’re sharing the love with agencies and consultancies that are trusted partners to orgs of many shapes and sizes.

Our early design partners will help define the program

We believe that the best partner programs aren’t built in a vacuum—they are co-created with the practitioners who are in the trenches with clients every single day. That is why we are launching this program alongside a select group of early design partners.

Instead of handing down a rigid, pre-packaged framework, we are inviting our foundational partners to join us with a seat at the table. Your real-world feedback, client implementation hurdles, and feature requests will directly shape our product roadmap and partner enablement activities. By joining us early, you will have a direct hand in defining how Kilo supports agencies globally, ensuring the program provides maximum value, minimal friction, and a clear path to mutual growth.

Why we’re focusing on data consultants to start

When looking at where to anchor our ecosystem, data agencies were the obvious choice. Modern agencies operate at the absolute cutting edge of architectural complexity, tasked with transforming messy data landscapes into clean, actionable, and production-grade pipelines. To support this, we’ve purposefully built Kilo not just as an open-source coding solution, but as a robust platform engineered for coders, data engineers, and data analysts alike.

Agentic engineering is transforming every industry, and Kilo is here to help unify your workflows and, as a result, provide cleaner, more relevant products for your team. We know that your teams live in specialized tools, and with Kilo, you don’t have to abandon them. You can improve your dbt definitions and modify your Jupyter notebooks directly within Kilo, allowing your existing technical workflows to sync seamlessly with our infrastructure. No jarring context switching, no broken dependencies.

And if you’ve ever been overwhelmed by the number of agent skills and MCP servers out there, we’re here to help. We can get your team up and running in that magical place where AI works for you, not against you.

Scaling together

The Kilo Agency Partner Program is built to grow as you grow. Whether you are a specialized boutique shop launching your first applied AI pilot or a global enterprise systems integrator, we have structured our partner tiers to provide tailored enablement, technical access, and commercial support at every stage of your practice.

The era of agentic engineering is here, and we want to build it alongside the world’s best data and AI teams. If you’re ready to accelerate your client deliveries, gain deep technical support, and help shape the future of the Kilo platform, we want to hear from you.

Maybe you’re already a daily user of our CLI and VS Code extension. Maybe you mostly use our cloud agents. Or maybe you’re totally new to Kilo but looking for better ways to use AI with Jupyter Notebook. Everyone is welcome.

We’re launching with three tiers: Foundation, for early-stage partners; Advanced, for those with a record of shared success with Kilo; and Premier, for more advanced collaboration. The idea is that new partners will progress through the tiers in collaboration with the Kilo team.

Applications for our early design partner cohort are now open. We look forward to hearing from you!

Cloud Agents let you run Kilo from anywhere without a local machine. Spin up an agent from the web or automate with webhooks, point it at a repo, and it works in an isolated container so you’re free to do anything else.

The Kilo team recently implemented several updates that make the Cloud Agents workflow feel less like a bot running on your behalf, and more like a collaborator agent that does the heavy lifting for you.

Your name on every commit

Previously, when a Cloud Agent opened a PR, the commit history reflected that. Now, you can connect your personal GitHub account through your own integration, and every commit and PR the agent creates is authored by you, with the Kilo bot listed as co-author.

Your contribution graph reflects the work you directed, code owners get pinged correctly, and reviewers know who was behind a change without having to dig. The agent did the typing, but it was your call - and the git log now agrees.

Profiles that know your repo

Agent environment profiles bundle the env vars, secrets, and setup commands a session needs. This update provides support for deeper configurations - you can now include custom agents, skills, MCP servers, and slash commands - so the session that boots already has your modes and project-specific skills loaded.

Additionally, you can set a default profile per repository instead of one global default. Point a session at a repo, and it automatically picks up the right environment for that project, with no manual selection each time.

This upgrades Cloud Agents from a basic, web-based coding agent to a fully-equipped, customized, and personalized agent that understands how you prefer to work from the start.

PR status at a glance

When a Cloud Agent opens a PR, you can now see its status directly in the Kilo dashboard without bouncing over to GitHub to check whether CI passed or the branch is ready to merge. The status shows up alongside the session that created it, so you know at a glance whether something needs your attention or whether it’s already good to merge.

Remote sessions

Remote sessions bridge your local machine and the Cloud Agents dashboard. Enable remote mode in the CLI, and your active local sessions show up in the web interface right next to your cloud sessions. Your machine still handles the compute, but the session is fully accessible from anywhere: messages and responses sync in real time, the agent’s questions route to whatever device you’re on, and you can pick up mid-session from somewhere else without starting over.

It’s the last piece in making Kilo sessions genuinely device-agnostic. Start something locally, check in on it from your phone, hand it off to a cloud session when you close the laptop. Same session, wherever you are.

Try it now

Everything above is live. Head to app.kilo.ai to connect your GitHub account and set up repository profiles. Update your Kilo extension or CLI to get remote sessions, and let us know what you think about all of these changes in our Discord!

This is common across teams using dependency scanners. If you’ve worked at a company that takes security seriously — or one that’s simply turned on Dependabot — the workflow is familiar: you open your alerts tab and see severity badges stacked across dozens of findings. Most probably don’t matter, but you don’t know which ones. So you either investigate them all or you start ignoring them. Neither option is good.

The scale of the noise

Endor Labs’ 2024 Dependency Management Report found that fewer than 9.5% of dependency vulnerabilities are reachable, meaning the vulnerable code path can be executed by your application. That’s over 90% noise. Coana’s research puts the false positive rate of conventional SCA tools at up to 95%.

In practice, your average codebase pulls in hundreds of dependencies, both direct and transitive. GitHub can tell you CVE-2024-XXXXX exists in version 4.17.20 of lodash. The missing context is whether your code ever touches the affected function. The alert is accurate as dependency metadata, but insufficient for prioritization.

The security industry has a name for this problem: alert fatigue. It is more than an annoyance. When developers learn that most alerts are irrelevant, they stop treating any of them as urgent. Reachable issues become harder to identify and prioritize.

What reachability analysis means

The concept is straightforward: before flagging a vulnerability as actionable, check whether your code can reach the vulnerable function. The useful question is whether your application has a call path to the specific code that’s vulnerable, rather than only whether the package appears in the lockfile.

This is what distinguishes useful security tooling from a package-version match against vulnerability databases.

Snyk, Endor Labs, and others have built reachability into their products. It works. But it typically requires you to adopt their entire platform, migrate your workflow, and pay enterprise pricing for what is often a filter on data GitHub already gives you for free.

Kilo Security Agent

We built Kilo Security Agent because we were drowning in alerts ourselves. We’re going through SOC2 and needed a real vulnerability management workflow: not just evidence that we had Dependabot turned on, but evidence that we were triaging and remediating findings in a timely, defensible way.

Security Agent syncs your Dependabot alerts across connected repos, then uses AI-powered static analysis to determine whether each vulnerability is exploitable in your codebase. The analysis is specific to each repository. A CVE in lodash’s command injection path doesn’t matter if you never call lodash.template with untrusted input.

How it works

The analysis follows a transparent four-step process for every finding:

1. Found package — identifies the vulnerable dependency and version in your lockfile

2. Reviewed advisory — reads the CVE details, affected functions, and exploit conditions

3. Checked repo usage — scans your codebase for imports and call paths to the vulnerable code

4. Determined reachability — concludes whether the vulnerability can be triggered

You see all four steps. If the agent says “no reachable risk found,” you can read why it reached that conclusion. We saw this with a lodash command injection finding: the agent traced our usage, confirmed we never invoke the affected function with user input, and classified it as safe to dismiss with the reasoning visible.

For findings that are reachable, the agent can also open a remediation PR. We watched it identify a handlebars prototype pollution vulnerability, confirm the reachable path, and open PR #5 with the version bump and test updates. No human intervention was required for a straightforward version upgrade.

Capabilities

• Audit reports with full severity breakdowns, exportable for compliance evidence

• SLA compliance tracking — configure per-severity deadlines, such as critical within 7 days or high within 30, with email notifications when findings go overdue

• Codebase risk analysis — a dashboard view showing where your repository risk lives

• Configurable automation — set thresholds for auto-analysis, auto-dismissal, and auto-remediation by severity and confidence level

What we learned from internal use

We’ve been running Security Agent against Kilo’s own repos as part of our SOC2 audit process. A few things stood out:

Most alerts were not reachable in our repositories. This was roughly in line with the industry data. The vast majority of our Dependabot findings turned out to be unreachable. We’d been spending engineering time on them anyway, because you can’t assume they’re irrelevant until you check.

Transparent reasoning changes behavior. When a tool says “dismissed — not reachable,” there’s an instinct to distrust it. When it shows you the four-step chain of reasoning — “found package X → reviewed advisory → checked your usage → no call path exists” — you can verify it in seconds. That makes review faster and easier to trust.

Auto-remediation needs guardrails. We don’t auto-merge PRs for everything. The confidence thresholds exist for a reason. You configure what severity levels and confidence scores warrant automatic action versus human review. For our SOC2 process, we auto-remediate low and medium findings with high confidence, and flag everything else for manual review.

Limitations

Current limitations:

• Dependabot only. Security Agent works with GitHub’s native Dependabot alerts. If you’re using Snyk, Renovate, or something else as your primary scanner, this won’t ingest those findings. Dependabot is the starting point; more sources will come.

• Requires Kilo Code credits. The AI analysis and remediation use model inference. You control how aggressively it runs via the automation thresholds, so costs are predictable, but it’s not free-tier functionality.

• Not a replacement for security review. This is triage and remediation automation. It doesn’t find new vulnerabilities in your first-party code. It manages the flood of known-CVE alerts in your dependencies.

Availability

Security Agent is available now for all Kilo Cloud users. Connect your GitHub repos via the KiloConnect GitHub App, enable Dependabot alerts on your target repositories, and configure your automation thresholds in Settings.

Teams and Enterprise plans include SLA enforcement, audit export, and priority support for compliance workflows. The docs cover the full setup.

The cost of ignoring this

Every engineering team I’ve talked to has the same story: they turned on Dependabot, got overwhelmed, and now either have someone spending hours each week on triage or, more commonly, a growing pile of unacknowledged alerts.

That backlog creates technical, legal, and regulatory risk. SOC2 auditors want to see evidence of timely remediation. Customers running security questionnaires want to know your SLA for critical vulnerabilities. “We have Dependabot turned on” isn’t an answer to “how do you prioritize and remediate known vulnerabilities?”

The industry data says over 90% of those alerts are noise. The reachable subset is where the highest practical risk usually sits. Automated reachability analysis can reduce the manual triage burden while preserving reviewable evidence.

We built Security Agent for our own SOC2 workflow, and it is now available to Kilo Cloud users.

Three of the largest IPOs in history are arriving in the same window. SpaceX went public on June 12 at a $1.77 trillion valuation, the biggest listing in history. Anthropic filed confidentially around $965 billion. OpenAI came in behind it at nearly $852 billion. Open any of the filings and you hit a word most of Wall Street didn’t know a year ago. SpaceX’s prospectus uses “token” 62 times.

Underneath all of the chatter around tokens is a single bet. These valuations assume two numbers keep climbing forever: how many tokens the world burns, and how much companies will pay for the best models to burn them. The first assumption looks safe. The second is already cracking, and it is cracking because of the most boring cost-control habit in enterprise software. The labs’ own best customers are learning to stop sending every job to the most expensive model that can handle it.

That habit has a name now. Model routing. It is the reason the people writing these checks should read the engineering org’s AI bill before they read the prospectus.

The subsidies ended

On June 1, GitHub flipped Copilot to usage-based billing for every plan. Everything agentic now burns credits at API rates. A line item that many engineering leaders treated as fixed for years became a number that sent costs sky-high, and the backlash was visible at the Gartner summit we visited recently.

On top of that, enterprises report blowing through their entire annual token budget in months. Uber blew through its entire 2026 AI coding budget in four months, by April, then capped employees at $1,500 a month. Uber was not even on Copilot. It was running Claude Code and Cursor. The point is that this is structural. Agentic workflows burn tokens faster than any flat per-seat budget could support, and when you tie yourself to one vendor, their next pricing change lands directly on you.

The obvious read is that AI got too expensive and the boom is cooling. The data says something else.

The 650x gap

Ramp publishes an AI Index built from real corporate spend. The latest cut, reported by TechCrunch, is the clearest picture yet of where this goes.

The top 1% of firms, the ones Ramp calls “AI-pilled,” spend about $7,500 per employee per month. That is $90,000 a year, per head. The median firm spends about $11.38. Roughly one enterprise seat.

That is a gap of more than 650x between the front of the pack and the middle, and it is widening, because the top spenders are accelerating. Their per-employee spend grew 14.1% last month alone. Ten months ago, in August 2025, we published a post that predicted AI bills of $100,000 a year per developer. It read as a stretch then, but the Ramp number landed at $90,000 and climbing. We were early by about a quarter.

But the ones actually in trouble aren’t the companies at the top of that curve. It is the companies that bet their whole workflow on one vendor and are starting to realize what that actually costs. The top 1% behave differently, as Ramp says: they mix and match, bouncing between multiple frontier models and platforms that give them cheaper open-weight access.

The winners are the ones who orchestrate their work to the right model, which doesn’t always equal the most expensive model that can do it.

Why routing works now

The economics are simple once you ignore the list price. A model is not expensive because its per-token rate is high. It is expensive because of how many tokens it burns to finish a job, and the most powerful models burn the most, since they reason longer and write more on the way to an answer. Default everything to the best model and you pay a premium rate times a premium token count. Match the model to the task and the same work costs a fraction.

A year ago there was a catch. Routing down meant a worse result, so nobody serious did it on work that mattered. That has changed. Open-weight models have closed much of the gap with the closed frontier on real agentic coding, and we can say so with numbers because we run the models ourselves. KiloBench puts each one through Kilo’s actual agent harness on Terminal Bench 2.0 and reports the true cost and accuracy.

Here is what that looks like in practice. When we ran GLM-5.2 against Kimi K2.7 Code on the same task, the two open-weight models split on planning, where GLM’s plan scored 9.0 to Kimi’s 8.1, but built nearly identical, fully working services from the same spec. The lesson is that most of a build’s quality is decided in the plan, so you can spend your strongest model on the planning and hand the build to a cheaper model and still ship the same service. Used that way, routing is not a compromise. It puts each model where it does its best work.

The trap is the default

Anthropic’s Claude Fable 5 was the cleanest cautionary tale, precisely because it was an excellent model, which is what made it dangerous as a default. It topped nearly every benchmark and was priced to match, at about $10 per million input tokens and $50 per million output, and because it reasoned longer it burned more tokens on the same job, quietly leaking money out of a budget on work a cheaper model could finish.

Then it vanished. Days after launch, a US export-control directive forced Anthropic to pull Fable 5 and its sibling Mythos 5 for everyone, including paying enterprise customers and Anthropic’s own staff. The most capable coding model on the market was live one day and gone the next, and the teams that had wired their workflow to it had no recourse. You did not need that ceiling to keep shipping. On KiloBench, Kimi K2.7 Code, GLM 5.2, and MiniMax M3 all post solid completion rates at a fraction of frontier pricing. Pricing can double, terms can change underneath you, and a whole model can be revoked by a directive nobody at your vendor controls. That is what betting your workflow on one model buys you.

The power is moving to the buyer

As routing spreads across corporate America, pricing power rebalances from the companies selling premium AI toward the companies buying it. When buyers route the routine, high-volume work to cheaper models, the frontier labs increasingly earn on the hard jobs, the complex work that genuinely needs their best reasoning. The revenue does not vanish, since that work is also the best paid, but its shape changes, and so does who holds the leverage. What shifts is the assumption some valuations lean on, that buyers will reach for premium models by default rather than by fit.

For any single model, that means earning each task on the merits, against a field of cheaper models that are now good enough for the routine work, with little to keep a buyer in place out of habit. The advantage premium AI assumed it had, enterprises standing on one flagship, becomes a question the buyer re-asks for every task: which model is the right fit here?

This is also why the routing layer is best kept separate from the model layer. A router built by a model vendor will, understandably, favor its own catalog, and for teams already committed to that stack it can do that well. But a buyer weighing options across providers is better served by a layer with no model of its own to favor, one whose only job is to match the work to whichever model wins it, wherever it runs.

You don’t pick a model anymore

The value is moving from the model to the layer that chooses between models, and that layer has to be neutral to be trusted. That is what we built Kilo to be. When the prevailing wisdom said everyone would consolidate onto one or two providers, we bet the other way: open source, bring your own keys, zero markup, real model choice across 500-plus options, and routing that follows real-world usage data and public benchmarks, so you can see why a given model won a given task.

Nobody wants to weigh hundreds of models at different prices for every step of every task. So the answer is a layer that makes the question disappear. That layer is Auto Model. You pick a tier, Frontier, Balanced, or Free, and every request goes to the model that fits the work, with frontier reasoning where it earns its price and cheaper or open-weight models where it does not. It shows you the cost while it runs and steps aside the moment you want to drive.

Today we are taking that further with the launch of Auto Efficient, where the routing is driven by the session itself. When you turn it on, your session is first classified by the kind of work it is, and then, using that classification together with our public benchmarks, KiloBench and PinchBench, Kilo picks the model that wins that specific session. You are not choosing a model, or even a tier per task. The session tells the router what it needs, and the router answers with the model the benchmarks say is best. Auto Efficient delivers 71% of published frontier completion at 72% lower cost on KiloBench.

The teams that come out ahead are the ones that stopped betting their roadmap on a single model. That is what Auto Efficient is built to do. You no longer choose a model. You choose how you choose models.

Try Auto Efficient

Learn More

Auto Efficient is a new tier in Kilo’s Auto Model lineup, and it’s a fundamentally smarter way to route. Instead of locking you into a single model or asking you to switch manually as the work shifts, it classifies each session in real time and routes it dynamically to the benchmark-proven best model for that task.

Routine work runs on something lean, harder tasks get more firepower, and the router keeps adjusting as your session evolves. You get the right model at every point in your workflow, automatically, with costs that reflect the actual complexity of the work rather than a fixed tier across the board. It’s live now, and you select it right in the model picker.

How it works

Auto Efficient runs on a short loop. A lightweight classifier reads your session in context and works out what kind of task you’re on and how hard it is. Kilo matches that to the cheapest model proven accurate enough for the work, drawn from a pool of candidates that we’ve selected based on benchmark performance. Then it routes the request, with no mode change or manual switch on your end.

The decision happens between your keystrokes. When you ask for a quick rename, it quietly runs something fast and cheap. Ask it to plan a tricky migration, and it reaches for a stronger model, all under the same Auto Efficient setting.

Based on real benchmarks

Auto Efficient doesn’t route on a model’s reputation or a vendor’s marketing copy. It routes on KiloBench, the coding benchmark we run continuously against the models in our catalog, and KiloBench is built from the kind of work developers do in Kilo every day. So when Auto Efficient hands a task to a cheaper model, it’s because that model has already shown it can do that class of work just as well as a pricier one. The savings come from cutting spend you didn’t need, not from cutting corners.

The routing isn’t a black box

The model rankings and benchmarked performance Auto Efficient routes on are public, sitting on the Kilo Leaderboard for anyone to read. It comes from real-world model usage across developer workflows and the coding benchmarks we run, which is the same signal the router acts on.

So Auto Efficient isn’t asking you to trust a number you can’t see. If you’d rather route by hand, you can: open the Leaderboard, find the cheapest model that holds up on the kind of work you’re doing, and pick it yourself. Auto Efficient just runs that lookup for you, continuously, on every request. The convenience is automatic, and the data underneath it is open.

Session Awareness

Per-request routing has an obvious failure mode: a router that swaps models every turn loses the thread, contradicts itself, and feels erratic. Auto Efficient is session-aware precisely to avoid that. Once it’s on a model that’s working for the thread you’re in, it stays there across related turns and only switches when a cheaper option is clearly the better call. You get the cost benefit of fine-grained routing without the whiplash of a model that changes its mind mid-conversation.

Also, routing calls aren’t always clear-cut, and Auto Efficient doesn’t gamble when they aren’t. If it can’t confidently match a request to a model, it falls back to the Balanced tier, which routes to a capable paid model. That gives you a hard floor: quality under Auto Efficient never drops below Balanced, whatever the classifier sees. Easy tasks get cheaper, and the hard ones keep the reliability you depend on.

Tune it toward the bill or the bar

Auto Efficient gives you a dial with two settings. One picks the cheapest model that clears the accuracy bar for the work, squeezing the most value out of every dollar. The other leans toward the strongest proven model in the pool, optimizing for accuracy first. You can set it in the Kilo dashboard based on whether a given project cares more about the bill or the bar, then let it run.

You’re still in charge

Auto Efficient is a smarter default, and it stays optional. It sits alongside the other Auto Model tiers - Frontier for maximum capability, Balanced for capable paid routing without frontier prices, and Free for no-cost models - and you can move between them whenever the work calls for it.

You can also step out of routing entirely at any point: pick a specific model by hand, bring your own provider key, or run a local model through Ollama or LM Studio. The router is there when you want it out of your way and gone the moment you don’t.

Turn it on

Open the model picker in Kilo and select Auto Efficient. One thing to check first: automatic mode-based switching needs the VS Code or JetBrains extension on v5.2.3 or newer, or the CLI on v1.0.15 or newer. On older versions the tier falls back to a single model for every request, so update if you’re behind.

See it in full at kilo.ai/auto-model, read the docs, and once you’ve run it for a while, tell us what you think!

Matching the model to the task is the biggest lever on your AI bill, and Auto Efficient now pulls it for you on every request, backed by benchmarks instead of guesswork. Turn it on, set the dial, and stop overpaying for the easy stuff.

To celebrate this leap forward, we are making Next-Edit completely free for everyone for the next month. No trials to activate and no credit cards to enter—anytime you use Next-Edit powered by Inception over the next 30 days, it’s completely on us via the Kilo Gateway.

What Exactly is “Next-Edit”?

Traditional autocomplete predicts the next few tokens or lines ahead of your cursor. It’s like an eager typewriter guessing your next word.

Next-Edit is fundamentally different. Instead of just looking forward, it acts like an elite co-editor sitting right next to you. Often referred to as Next Edit Suggestions or NES, Next-Edit is a way to work faster and smarter. By analyzing your recent edits and broader codebase context, Next-Edit anticipates what you’re about to change next across your file—whether that’s refactoring a function you just touched, renaming a variable across a block, or implementing a cascading feature change.

Because Mercury Edit 2 is built on a cutting-edge diffusion LLM (dLLM) architecture, it doesn’t generate code left-to-right, one token at a time. Instead, it refines text in parallel and you just hit Tab to accept. This “jump to edit” feature takes some getting used to, but once you start coding with it, we hope you will love the feeling of being in the flow.

Autocomplete has been a popular feature in Kilo, and it’s not going anywhere. We’re just expanding the functionality to include Next-Edit.

Backed by Breakthrough Benchmarks

We didn’t just pick Mercury Edit 2 because it sounds futuristic; its performance metrics are genuinely staggering. Inception put this model through a rigorous set of industry benchmarks—including Instinct, Fill-in-the-Middle (FIM), and Next-Edit Prediction (NEP)—and the data speaks for itself:

• 48% Higher Acceptance: Thanks to alignment via an advanced reinforcement learning method (KTO) based on real human feedback, developers accept Mercury Edit 2’s edits 48% more often than previous iterations.

• 27% More Selective: Nobody likes a noisy AI that constantly derails your train of thought. Mercury Edit 2 is 27% more selective, meaning it only interrupts when it has a high-quality, targeted edit, keeping distractions to an absolute minimum.

• Unmatched Quality & Speed: In side-by-side latency testing against custom next-edit frameworks and speed-optimized frontier models, Mercury Edit 2 consistently takes the crown for real-time responsiveness.

Two Flavors of Mercury Edit 2 Now in Kilo

We know every developer has their own rhythm. To give you total control over your workflow, you will now find two separate versions of Mercury Edit 2 inside Kilo:

1. Next-Edit Mode (The New Default): The powerhouse editor that actively anticipates your next logical code modification.

2. General Autocomplete Mode: The ultra-fast, classic line-and-token filler for standard, sequential coding sessions.

Heads Up: Next-Edit is now the default experience for all new Kilo users. If you had previously set a default for autocomplete, you will need to manually change to Next-Edit. We highly recommend giving it a spin to experience the parallel diffusion difference for yourself.

How to Customize Your Setup

While we think Next-Edit will change how you code forever, Kilo is built entirely around developer choice. If you ever want to change the model back to autocomplete-only, doing so takes just a few clicks. You can seamlessly modify your Next-Edit and autocomplete settings right from your workspace:

• Open Kilo in VS Code.

• Locate and click the Gear Icon (Settings) inside Kilo’s VS Code extension sidebar.

• Under Settings > Extensions > Kilo Code, toggle your preferences or switch between Next-Edit and classic Autocomplete to suit your current project’s needs.

Enjoy Free Next-Edit Functionality

There is nothing extra to install, no individual trial to start, and no complex configuration required. Just fire up Kilo anytime over the next month and you’ll automatically have access to next-generation, diffusion-powered predictions entirely for free, as long as you are using the Kilo Gateway (this is the default).

When the promotion ends, on July 23rd, 2026, you can continue using Mercury Edit 2 at affordable market rates.

Happy editing!

What happened

This is a different change from the one from March, when Augment removed Next Edit and Completions in its IDE extension on non-enterprise plans. Now Augment seems to be taking a more extreme approach, shutting down its IDE extension.

The reaction in the JetBrains community has been pretty strong: People have been disappointed in general, and some paid for extra credits through July 1 just to keep the VS Code extension running until the lights go out. Another PyCharm user tried Claude Code and found that the experience was not the same; they wanted to go back to having autocomplete in the editor and a chat window directly in the IDE.

Augment’s alternative for JetBrains is the Augie CLI and Cosmos, two tools with very different workflows. You can technically wire the CLI with a JetBrains IDE, but people are not sold on it. The recurring complaint is that the CLI is clunky and lacks the GUI they actually liked, and more than one person said they like to work directly in the IDE and review changes there.

The pricing moved at the same time. Augment’s current Business plan is $100 a month for up to 50 seats. The free Community plan is gone, you now have to be on a $100 plan to use the product at all. Augment also restricted its subreddit, and users say it closed its Discord too, so the places people used to discuss are mostly read-only now.

Why is Augment doing this? I think we should be fair about what this is. Augment is not going bankrupt or shutting down, it is moving upmarket to enterprise teams and its Cosmos agent platform, and as one commenter put it, that just makes you a different kind of customer than the one they want now. If you are an individual developer or a small team in PyCharm or IntelliJ, Augment has told you, impolitely or not, that you are not who they are building for.

Kilo Code already has what Augment users are asking for

When we analyzed what Augment users are looking for across community threads, we saw the same short wish list coming up: People want autocomplete in the editor, an agent panel inside the IDE, a way to see and review what the agent changed, and a context engine that understands the codebase.

Our JetBrains plugin is built around that list. Inline Tab autocomplete runs as you type, and Kilo’s autocomplete also has a Next Edit mode that predicts multi-line edits ahead of your cursor and lets you Tab to jump and apply them. Kilo’s agent lives in a panel inside IntelliJ, PyCharm, GoLand, and the rest, and a checkpoint tracker sits at the top of the chat so you can see what changed and roll back to any point. You never have to move to a terminal to get work done.

We shipped our first JetBrains plugin in September 2025, and back then it was a port of our VS Code extension running through a Node.js layer.

A lot has improved since then, and the stable plugin on the Marketplace supports every JetBrains IDE on both Community and Ultimate editions.

Version 7: The early reviews for our JetBrains extension have been mixed. Version 7 is the answer to most of those complaints. We rebuilt the plugin from the ground up as a native JetBrains plugin with a real Kilo tool window instead of a WebView. The plugin bundles its own Kilo CLI runtime for macOS, Linux, and Windows, which removes the Node detection that breaks the current plugin for so many people, and it handles sign-in, model selection, and permissions natively.

We have some of the world’s best engineers working on this plugin, including Kiril, who spent close to 10 years at JetBrains and knows the entire ecosystem from the inside out.

Open source, open pricing, open models

A few months ago, we published an article comparing Kilo’s pricing to Augment’s pricing and found it to be several times cheaper.

Back then, people were mad at Augment constantly switching their pricing. If you do some research, you’ll see you have almost no complaints about our pricing because, well, it’s open. You know what you’re paying for. Kilo connects to more than 500 models through one gateway, and we add no markup on the provider rate when you bring your own key. You see the exact model on each request, the context window size, and the full prompt. There is no $100 floor and no expiring credit pool.

The whole plugin is also open source under Apache-2.0.

How to switch

Install Kilo Code from the JetBrains Marketplace and you are running on the stable build in a couple of minutes. If you want the native version 7 experience, follow the JetBrains setup guide to add our early access repository, and the IDE will handle updates from there. Either way you can start with free models or plug in your own API key and pay the provider directly.

Augment told its IDE users to move to a CLI or pay for an agent platform built for a totally different audience. You do not have to do either, and you do not have to leave PyCharm or IntelliJ to get back what you had. You just install a different plugin.

Starting today, Terminal Bench completion scores and per-attempt costs show up directly in the Kilo CLI and VS Code extension model details panel. The benchmark data is now in the same place you already check price and context limits.

Why Put This in the Picker

Terminal Bench 2.0 isn’t a toy benchmark. It drops AI agents into sandboxed terminal environments and asks them to do real work — git operations, system administration, data processing, cryptanalysis. The tasks were written by Stanford and Laude Institute researchers, and the scores reflect actual pass rates on 89 real-world problems.

The spread between models is large. On the public Terminal Bench 2.0 leaderboard, GPT-5.5 with the NexAU-AHE agent hits 84.7%. Claude Code with Opus 4.6 lands at 58.0%. Gemini CLI with 3.1 Pro scores 61.4%. That’s a 26-point gap between the top and what most people would still consider a strong model.

Those numbers measure each model in its own optimized agent scaffold. What matters in Kilo is how a model performs in Kilo’s harness, with Kilo’s tool pipeline, context management, and retry logic. That’s what Kilo Bench measures, and that’s what now shows up in your model picker.

What Changed

Open model details in either the VS Code extension or the CLI. For models where we have Kilo Bench data, you’ll see two new fields:

• Terminal Bench Score — the completion rate when running through Kilo’s evaluation harness

• Avg. Attempt Cost — what each benchmark attempt actually costs, including reasoning tokens, re-sent context, tool calls, everything

The score and cost together show the value-per-dollar of a model in your tool. A model that completes 74% of tasks at $0.52 per attempt is a different choice than one completing 54% at $1.83 per attempt, even if the second model looks better somewhere else.

The Gaps Are Big Enough to Matter

This would be a small UI detail if every model scored within a few points of each other. They do not.

On our Kilo leaderboard, GPT-5.5 hits 74.1% on Terminal Bench through Kilo’s harness. Kimi K2.6 lands at 54.4%. That’s a 20-point gap between two models you might otherwise treat as interchangeable. Meanwhile, on SWE-bench Verified, where the top six are separated by 1.3 points, those same models look nearly identical. The difference shows up when you test them in a real agent framework doing terminal-heavy work.

Cost widens the gap. A model that needs three attempts to pass a task effectively costs 3x its per-attempt price. Kilo Bench captures this because it runs multiple trials per model and tracks both per-attempt cost and cost-to-complete. When you see “$0.47/attempt” in your model details, that’s what it cost in our runs, including reasoning tokens, re-sent context, and tool calls.

Coverage Is Still Expanding

Not every model in the picker has Kilo Bench data. Running Terminal Bench evaluations takes time and compute, so we’re working through the catalog and prioritizing models Kilo developers actually use. If you don’t see a Terminal Bench score for a model, it means we haven’t evaluated it yet.

We’ll keep expanding coverage. The leaderboard at kilo.ai/leaderboard shows the current state, and new models get added as we complete evaluation runs.

How to Get It

Update to the latest Kilo CLI or VS Code extension. The Terminal Bench data pulls from the same API that powers the web leaderboard, so you’ll always see current scores without needing to update again.

In VS Code: open model details for any supported model → the benchmark section appears below pricing info.

In the CLI: model info commands now include Terminal Bench fields when data is available.

Why This Exists

We wrote about why KiloBench exists a few weeks ago. Generic benchmarks are saturating, scaffold inflation makes raw scores misleading, and per-token pricing tells you almost nothing about actual cost. The useful signal is harness-specific pass rate plus real cost-per-task.

That data belongs in the model picker, where the decision happens. You shouldn’t need a spreadsheet or a blog post to figure out which model to use. The UI should give you enough signal to choose without leaving the workflow.

Terminal Bench scores are live now in the latest Kilo CLI and VS Code extension release. Check kilo.ai/leaderboard for the full table, or just open your model picker and look.

If your entire development workflow ran through Fable 5 — and a lot of people’s did, given that Vals AI ranked it #1 across benchmarks — you woke up Saturday to a broken toolchain. No migration path, no advance warning.

Provider Access Can Change Overnight

DeepSeek has been banned or restricted in Italy, Australia, Taiwan, South Korea, India, and at least 17 US states. OpenAI’s API still isn’t available in a bunch of countries. Google restricts Gemini access by region. Every major provider has geographic or policy limitations that can change overnight.

The Fable 5 situation is the clearest recent example because it happened so fast. Friday evening directive, Saturday morning blackout. Anthropic said the letter “did not provide specific details” of the national security concern.

When your coding agent is hardwired to one provider’s API, your workflow becomes exposed to that provider’s regulatory and geopolitical constraints. I talked to developers on our Discord this weekend who had Fable 5 configured as their only provider in their coding agent. Their weekend plans changed.

BYOK Makes Provider Choice Part of the Architecture

At Kilo, we’ve always believed developers should choose their own models. That position is practical, not just philosophical: resilient AI tooling needs to account for provider outages, pricing changes, and access restrictions.

BYOK means bring your own key, bring your own inference, run your own models. Your coding harness is decoupled from any single provider’s availability, pricing decisions, or compliance with government directives you had no say in.

If Fable 5 goes dark, you switch to Claude Opus 4.8, GPT-5.5, DeepSeek, or a local model via Ollama. Your workflow remains intact, and you do not need to relearn your tooling. Your prompts, modes, and context stay in place.

The Provider List Keeps Growing

Kilo now supports roughly 30 providers. The breadth matters:

• Anthropic

• AWS Bedrock

• BytePlus Coding Plan

• Chutes BYOK

• CrofAI

• DeepSeek

• Fireworks

• Google AI Studio

• Inception

• Inceptron BYOK

• Kimi Code

• Martian

• MiniMax

• Mistral AI (Codestral)

• Mistral AI (other models)

• Moonshot AI

• Neuralwatt

• Novita

• Ollama Cloud

• OpenAI

• OpenCode Go

• OrcaRouter

• Perplexity

• Synthetic

• xAI

• Xiaomi (pay as you go)

• Xiaomi Token Plan (Europe)

• Xiaomi Token Plan (Singapore)

• Z.ai (pay as you go)

• Z.ai Coding Plan

These are inference endpoints, not merely individual models. They have different pricing, different geographic availability, and different regulatory exposure. Some are US-based, some Chinese, some European, and some run on your own hardware.

You don’t need all 30. But when one goes down — for any reason — you have 29 others already configured and ready. Or you can use the Kilo Gateway directly to just access inference across hundreds of providers we have connections with.

Cross-Surface Consistency

One often-overlooked requirement is cross-surface consistency.

I use Kilo in VS Code, but also through the CLI, and some of our team uses vim with ACP. The same API key, the same provider, the same inference setup works everywhere. Configure once, use everywhere.

Switching from your laptop to a CI environment to a different editor doesn’t mean reconfiguring your AI tooling from scratch. Your setup is portable because the provider layer is yours, not ours.

Kilo Pass and Coding Plans

Not everyone wants to manage API keys across multiple providers. For those users, Kilo Pass offers a subscription that gives you access to multiple providers through a single billing relationship, with bonus credits at higher tiers ($19, $49, or $199/month).

MiniMax and several other providers offer dedicated coding plans through Kilo’s gateway. You get multi-provider resilience without maintaining a dozen API accounts.

The gateway approach also means you can bring your own keys alongside a plan. You can mix and match providers and access methods. Use Kilo Pass for your primary provider and BYOK a local Ollama instance as a fallback. The architecture supports both because they’re the same mechanism underneath.

Provider Fragmentation Will Increase

More providers, more geographic fragmentation, more regulatory intervention. The Fable 5 shutdown is likely to be repeated in other forms. DeepSeek’s rolling bans are unlikely to be the last time a provider gets caught between geopolitical blocs.

Pay-per-use AI inference is where everything is headed. More providers will emerge to serve different regions, different compliance requirements, different cost profiles. Developers who are set up to swap between them without changing their tooling will be better positioned to absorb the next disruption.

The ones who hardwired their workflow to a single provider’s API will be forced into an urgent migration with little warning.

Agentic coding tools are improving rapidly, but most of them share the same friction: to use one, you have to leave the place you were working.

You spot something in a pull request, then you open your editor, pull the branch, paste the file into a chat window, and re-explain context the tool can’t see for itself. By the time the agent is caught up, you’ve spent more effort briefing it than the task was worth.

Code review and issue triage don’t live in your editor, though. They live in GitHub, in issue threads and PR diffs and review comments. So that’s where we put an agent.

@kilocode-bot is a coding agent that lives in GitHub. You can add it to any repository and mention it like a teammate. Tag it in an issue, a pull request, or a review comment, and it behaves like a colleague who has already read the entire thread.

Ask a question and it answers. Point it at a bug and it works out the cause. Hand it a fix and it opens a pull request - all without you leaving the tab you were already in. It reads the issue description, the diff, the review conversation, and the connected code on its own, so you brief it the way you would a person: with an @mention and a sentence.

A second set of eyes during review

The smallest and most frequent thing you’ll reach for it is a second opinion mid-review. You’re going through someone’s PR, you hit a block of logic that looks off or that you don’t recognize, and instead of context-switching to investigate, you ask right there:

@kilocode-bot is this true?

It reads your comment, the diff around it, and the code that the block depends on, then replies inline. Because it has the surrounding context, it can do more than answer yes or no: it’ll check whether the logic holds, suggest a cleaner approach if there is one, or explain an unfamiliar pattern a teammate wrote six months ago. It’s the reviewer who walked into the room already knowing the codebase, which is usually the part that makes a good second opinion expensive to get.

Bug Triage

Bug reports are easiest to act on once you know roughly what you’re looking at, and that first pass is often the slowest part of the job. When one lands, you can hand the agent the cold open:

@kilocode-bot what could be the cause of this issue?

It reads the report, searches the codebase for the code paths involved, and posts its analysis straight into the issue thread. You start digging with a theory instead of a blank page, and because the reasoning lands in the thread itself, whoever picks the issue up next sees it too. That makes it as useful for triage and assignment as it is for the person who eventually does the work.

From issue to pull request

When an issue is well described and you’d rather it just get handled, ask for the fix outright:

@kilocode-bot please fix

The agent reads the issue, analyzes the relevant code, writes the change on a new branch, commits it, and opens a pull request back to the repo. The PR shows up linked in the issue thread, and you review and merge it exactly like one from any other contributor.

How it works

Every mention spins up a Cloud Agent to do the work, which means it runs in the background rather than tying up your machine. You tag it and go back to what you were doing, and it comes back when it’s done.

The agent reads the full context it has access to, the issue description, the PR diff, the review thread, and your connected repository code, and then answers, analyzes, or opens a PR depending on what you asked for. It uses Kilo credits the same way every other Kilo interface does.

Getting the best results out of it

A few habits make the difference between a sharp response and a confused one. Be specific about what you want, since “please fix” rewards a well-described issue and stumbles on a vague one. If an issue is thin, ask the agent to diagnose before you ask it to implement. When a change spans multiple repositories, name them explicitly in your comment. And for quick, contextual questions, lean on review comments, where the agent has the tightest possible view of exactly the code you’re asking about.

Add it to your repos

You’ll need a Kilo account with available credits and your GitHub account connected through KiloConnect, which lives in the Integrations tab at app.kilo.ai. From there, install the Kilo Code Bot app on the repositories you want it active on. Once both are in place, @kilocode-bot is sitting in every issue and PR thread in those repos, waiting for its first mention.