DEV Community: Job from Kilo

We spent our focus week obsessing about this: you shouldn’t have to guess what your AI coding bill is doing

Job from Kilo — Thu, 09 Jul 2026 13:35:08 +0000

Token cost is a big topic right now, and the pressure is building across the industry: the hyperscalers funding much of the compute have watched their combined free cash flow fall by nearly 90% in 18 months, and that pressure trickles down to your coding bill. We also called the $100k/year-per-developer AI bill, and cost isn't slowing down. The teams that are ahead don't cut back on AI use, but rather leverage visibility into their spend, and route across frontier and open models.

That's the whole premise behind the four cost-saving levers we've written about before: model choice, observability, governance, and time/context. This last focus week, our team put serious work in the first two, model choice and observability, and shipped a batch of things that make your Kilo spend easier to see and control.

Here's what's live now.

You now know which model actually did the work

With the launch of Auto Efficient, model routing is driven by the session itself. When you use it, your session is first classified by the kind of work it is, and then, using that classification together with our public benchmarks, KiloBench, Kilo picks the right models for it. On KiloBench, that means Auto Efficient delivers 71% of published frontier completion at 72% lower cost. That's been live for a couple of weeks. What's new is that the router gives you more visibility during the session.

You can now see, turn by turn, which model handled your request. Select Auto Frontier or Auto Efficient and you'll see the actual models that ran live during the session. If you've ever wondered what happens under the hood when you use Auto Model routing, now you can just look.

Users could already see which model ran from the usage dashboard, but now that visibility lives right in the task itself. That matters beyond just trust: seeing which model handled which kind of work is also how you learn what actually needs a frontier model and what doesn't. We think full visibility into cost and models used is the only way to build real AI capability without getting locked into a single vendor.

Models used by Kilo Auto Efficient on a single task.

Underneath that transparency, we also ran a fresh batch of benchmarks on KiloBench, our continuously-updated coding benchmark. More models and more recent data feeding the routing decisions. That means when Auto Efficient hands your task to a model, that call is backed by benchmark numbers that are days old, not months old.

KiloBench showing cost vs performance and popularity in Kilo

You can compare your inference options

Model choice isn't just "which model." It's also "how am I paying for this": pay-as-you-go, a coding plan, your own API key, a subscription bundle, or a combination of all of these. Until now, figuring out which combination made sense meant some guesswork.

We shipped a single page for that: kilo.ai/models/inference. It lays out coding plans, subscriptions, and Bring Your Own Keys (BYOK) options side by side, so you can see what you can actually bring into Kilo and what each path costs before you commit to one.

AI Coding Plans & Inference Options

Once you know your options, the next question is provider-level: two providers can serve the exact same model at meaningfully different cost and reliability. That's what the Kilo Gateway inference provider leaderboard is for. It shows how inference traffic was distributed across providers last week for the 20 most-used models, ranked by total token volume, and for each one you can see cost, cache efficiency, and error rates side by side.

Kilo Gateway inference provider leaderboard

If you want the savings math done for you rather than eyeballing a leaderboard, the new Cost Savings Calculator does that: toggle the features you'd actually use, and it projects your savings using KiloBench and live pricing data.

Cost Savings Calculator

Since coding plans went live in Kilo with MiniMax as our launch partner, we've expanded the MiniMax plans available to purchase directly in Kilo. Same idea as before: buy with the credits already on your Kilo balance, no separate subscription or invoice to manage.

You can see exactly where your balance went, everywhere you work

None of the above matters if you still can't answer "where did my money actually go this week." So we went after that directly.

The new credits page gives you full credit history and deductions: every debit, in order, instead of one number that changes without explanation.

Your Kilo Balance now shows up everywhere you work. CLI, VS Code, and JetBrains all surface your current balance and Kilo Pass status directly, not just the web dashboard. If you live in your editor or terminal all day, you shouldn't have to shift to a browser tab to know if you're about to run low.

Your Kilo balance and Kilo Pass status visible in every surface

We also improved the model picker itself: auto-model grouping and highlights right in the extension, so the model picker doubles as a cost-visibility surface instead of just a dropdown of names.

And for the moment when visibility needs to become a hard stop: Session Cost Alerts now let you set a max-cost threshold in CLI and VS Code, with an alert when you cross it. Here's what that looks like in practice:

Set a session cost alert in CLI and VS Code

The pattern underneath all of it

None of these ship in isolation. Auto Efficient tells you which model ran. The comparison page and calculator tell you what your inference options cost before you buy. The credits page, balance-everywhere, and cost alerts tell you where the money's already gone. Put together, that's helping you optimize your AI coding spend.

The pricing pressure across the industry isn't going away. Usage-based billing is becoming the default, not the exception. The teams who come out ahead of that aren't the ones spending less, but rather the ones who leverage model freedom and aren't locked into a vendor.

If you want to go deeper on the model side, we also put together landing pages comparing Auto Efficient against frontier models with the full KiloBench data and one-shot prompt comparisons, if you're evaluating this for a team and want something to share around.

And one thing shipping soon: granular cost insights and recommendations on paths forward, so you don't have to dig into the data yourself to optimize your spend and understand your usage.

Try Auto Efficient · See the inference comparison · Try the Cost Savings Calculator · Check your credits

Auto Efficient: The Right Model for Every Request, Automatically

Job from Kilo — Tue, 30 Jun 2026 12:16:58 +0000

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.

Why Most Dependency Alerts Don’t Matter

Job from Kilo — Fri, 26 Jun 2026 13:27:27 +0000

Last month I heard about an engineer on our team spending forty-five minutes investigating a critical Dependabot alert for a lodash command injection vulnerability. He traced the call paths, read the advisory, and checked our imports. The function wasn't reachable. Forty-five minutes gone for a single alert out of hundreds. (This engineer may or may not have been me.)

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:

Found package --- identifies the vulnerable dependency and version in your lockfile
Reviewed advisory --- reads the CVE details, affected functions, and exploit conditions
Checked repo usage --- scans your codebase for imports and call paths to the vulnerable code
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.

GLM-5.2’s Code Reviews Are Only as Good as Your Prompt

Job from Kilo — Fri, 26 Jun 2026 13:18:44 +0000

GLM-5.2 from Z.ai has been one of the most talked-about open-weight models since it launched, and we have made it our daily driver to see how it performs on various coding tasks. We already put it head to head with Kimi K2.7 on planning and building a backend service. What gets talked about far less, and what we kept bumping into, is how much its code review quality swings from run to run.

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 Low Auditing First Codebase

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.

GLM 5.2 Low Audit from First Codebase

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.

GLM 5.2 High Auditing Second Codebase

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.

GLM 5.2 High Audit from Second Codebase

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.

GPT-5.5 High Auditing First Codebase

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.

We predicted the $100k/yr-per-dev AI bill. Now the winners are routing around it.

Job from Kilo — Fri, 26 Jun 2026 13:12:40 +0000

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 top 1% of firms tend to mix and match, opting to bounce between multiple frontier models and platforms that give them access to cheaper open source models.

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

The GitHub Copilot Bill Came Due. Here's What Engineering Leaders Should Do.

Job from Kilo — Mon, 08 Jun 2026 08:15:18 +0000

Right now, as I write this, our team is on the floor at the Gartner Summit, and there's one conversation happening in every hallway and coffee line: what just happened to our GitHub Copilot bill?

It's the trending topic of the day for a reason. On June 1, Copilot's usage-based billing went live for everyone, and the people feeling it hardest are software engineering leaders who woke up this week to discover that a line item they'd treated as fixed for three years is now a variable cost that swings with their team's most productive days.

A few weeks ago, we wrote that this was coming — the era of subsidized, all-you-can-eat AI was over, and the only honest path forward was paying for what you use. And it's happening this week.

What we're hearing on the floor

This isn't just our read in a vendor blog. Many engineering leaders we've talked to this week are in the same scramble: how to get ahead of a bill that's suddenly a moving target.

What actually changed

GitHub has moved from seat-based pricing to an access-plus-consumption model: your subscription funds a monthly credit pool, and you pay for everything beyond it.

Copilot now bills by GitHub AI Credits, calculated on token consumption — input, output, and cached — at per-model API rates. Code completions and Next Edit Suggestions stay free and unmetered, so if autocomplete is your whole workflow, little changes. But everything agentic — chat, agent mode, multi-step sessions, tool calls — is now metered, and Copilot code review now also burns GitHub Actions minutes on top of credits. Once your allowance is gone, you pay overage, or you're cut off.

The real problem is that nobody can predict the bill

Teams can plan around a higher bill. What they can't plan around is one that swings unpredictably from one week to the next — and that's what most of this week's complaints are really about.

Developers are watching credits evaporate in ways they can't anticipate. One Pro+ user burned through roughly 8% of their monthly allotment in two hours and projected the whole thing gone in under two days. Another spent more than $6 on a single change request and called the consumption impossible to predict. A session using Claude 4.8 to fix some site issues ate 1,180 credits — about 16% of a Pro+ monthly allowance — for results the developer called mediocre. One person watched a single file review, with no code changes, consume 20% of their monthly allowance. At the org level, people are circulating projections of monthly costs jumping from $29 to $750 and from $50 to $3,000 in heavy agentic workflows. A "Goodbye, Copilot" post has been shared thousands of times, and TechCrunch called it the end of Copilot's golden age.

The r/github thread that's been climbing all week reads the same way, and the sharpest complaints aren't about price at all. One developer described being forced into "token anxiety," micromanaging every click to survive the month. Another nailed the unit mismatch: you bought a seat, and now every agentic run feels like "leaving a taxi meter running in another room." And this one should land for anyone who signs off on a budget — a developer whose org hadn't even finished configuring its credit pools wrote that, at his burn rate, "finance will be getting a hefty bill because management isn't up to date on plan changes."

To be precise: this isn't a hidden markup. Copilot charges standard per-model API rates — one commenter noted the models cost "exactly the same price as direct from OpenAI and Anthropic." The price was never the subsidy — the flat subscription was. Now that it's gone, you're just seeing what agentic coding actually costs.

Here's the kicker for anyone responsible for a budget: you couldn't even trust the preview. GitHub's Billing Preview tool was meant to estimate costs before the switch — but it runs on discounted credits, so the number it showed enterprises is lower than what they'll actually pay. GitHub also warns that older IDE and extension versions can display inaccurate pricing. And some heavy users found the projected spend wildly higher than their lived experience.

Either way, many couldn't get a number they trusted.

This is already happening at enterprise scale

The individual horror stories are the visible edge of something bigger: at the org level, agentic coding is outrunning the budgets attached to it.

Uber is the clearest example. It burned through its entire 2026 AI coding tools budget in four months — by April — and has since capped employee spending at $1,500 a month. Its CTO for Mobility and Delivery, Praveen Neppalli Naga, confirmed the blowout to The Information. And it wasn't even on Copilot — it was Claude Code and Cursor. The dynamic isn't vendor-specific: agentic workflows burn tokens faster than flat per-seat budgets were built to absorb. GitHub's change just forces every other org to confront the same math.

And the optimistic case is a trap: even as per-token prices fall, enterprise bills won't drop in step, because agentic workflows burn far more tokens per task and providers won't pass all the savings through. If your plan assumes prices will just come down, retire that assumption.

What leaders can do right now

The basics everyone here is trading notes on are the right place to start — so let's start there, then go one step further than the band-aids.

Analyze your actual usage — against the real rates. Pull your usage report now and model your team's real token consumption against the standard metered rates, not any discounted preview.
Put spend governance in place before overages start. GitHub has rolled out hard spending caps and user-level budgets with a "stop at limit" option. Set the ceiling now.
Prioritize workloads — match the model to the task. The unpredictability is worst when every action defaults to the most expensive frontier model. Reserve the heavy models for the work that needs them, and stop spending premium credits on trivial completions and boilerplate.
Don't let one vendor own your meter. The first three steps are damage control — they make a bad position survivable. The real exposure is having bet your roadmap on one provider's pricing and model availability, and this week showed how that feels when it shifts overnight.

Developers are already voting with their feet, running hybrid stacks: burn the Copilot allocation, then route the rest elsewhere. It's a smart stopgap — but still a workaround for a problem you shouldn't have.

Model freedom is the durable answer

This is the world Kilo was built for. We have always focused on open source, transparent pricing, bring-your-own-key (BYOK) support, and genuine model choice. When the prevailing wisdom said everyone would consolidate onto one or two providers, we bet on flexibility.

The principle is simple: you shouldn't have to care which vendor controls the model, or what their next pricing change does to your workflow. Bring your own keys, run any model across any provider, and see exactly what you'll pay.

500+ Models, One Place

Pick the best model for every task — coding, planning, debugging, agentic work — ranked by real-world usage across 500+ hosted options, and switch the moment the economics change.

Different work wants different models: the task that justifies a frontier model for orchestration is wasteful for a quick refactor. We show you which models lead in Code, Plan, Debug, Ask, Review, and Orchestrator, based on real usage.

We Know Which Model Fits the Job

Matching the model to the task is the single most effective way to keep agentic costs sane — and it's hard to do by hand, prompt by prompt. Kilo Bench measures cost versus performance across the most capable coding models on Terminal Bench 2.0, so the trade-off between completion rate and cost per attempt is a number you can see, not a guess.

And you don't have to make that call on every request. With Auto Model, smart routing automatically selects the optimal model for each task, across tiers that balance cost and capability — no manual switching required.

Granular Usage Analytics

The hardest thing for a leader this week is simply seeing where the spend goes — one developer complained GitHub had "made tracking your spending as difficult as possible." That's exactly what Kilo gives you: complete visibility into how your teams use AI, with spending tracked down to the individual developer.

Slice usage however the question demands — by date, feature, model, mode, provider, or project — at individual or organization scope.

And see exactly where the money goes: cost broken out by model turns "why is the bill so high" into a chart you can act on.

Governance: You Decide What Your Org Can Use

Model freedom doesn't mean a free-for-all. Kilo gives administrators 62 providers and 681 models to draw on — and full control over which your organization can actually use, with a default model set centrally.

You can disable specific models for organization members, so spend governance isn't just a cap on a bill — it's control over what runs in the first place. That's exactly the kind of structural control the leaders we're talking to are scrambling to put in place this week.

Model choice shouldn't be a premium feature, and open source is the foundation that stays stable when closed systems reprice overnight. It's good to see the broader market arriving at the same place.

PS. Looking for model freedom? Try out Kilo Pass — instant access to 500+ models, transparent pricing, and never any surcharge.

Inside Kilo Speed: The Engineer Who Teaches Teams How to Think in Agents

Job from Kilo — Wed, 13 May 2026 12:17:35 +0000

How to manage your agent team, from someone who coaches Kilo customers in agentic engineering.

Rebecca Dodd
May 12, 2026

When you're learning a new discipline—especially on the job—learning the theory behind it can feel like an abstract nice-to-have, while practice is the thing that's actually useful. Learning by doing is absolutely a valid way to upskill, but in Marius Wichtner's experience, grasping the conceptual foundation of agentic engineering helps to make the practical steps make sense.

Before joining Kilo Code, Marius was already training engineering teams on working with generative AI. At Kilo, he does the same for enterprise clients in Kilo Speedruns: one-hour sessions designed to give teams a fast, practical orientation on agentic software development. He's run them for companies across industries, and now he's sharing the foundations of those lessons (and his specific practices for each) here:

How to delegate effectively
How to scale across concurrent workstreams
How to maintain judgment and recover when things go wrong

1. How to Delegate: The Team Lead Model and the Plan

The mental model Marius uses to explain agentic engineering—both in client speedruns and in how he structures his own work—is the team lead.

Team leads don't spend all day writing code, and the same was true even before agentic tools existed. They were in pairing sessions, answering questions, reviewing output, and deciding what to merge. "Those were always the people that were only in meetings and they got called by all the juniors," Marius says. "They were just solving the last 20% of the problem."

In this model, the agent takes care of execution work, while the engineer operates as the team lead. The 80% that agents handle well—code generation, boilerplate, well-scoped subtasks—is work that the team lead delegates. The 20% that still requires the engineer is the judgment work: architectural decisions, what to merge, and recognizing when the agent has drifted.

Parallel development with the engineer acting as team lead

The engineers who transition most naturally into agentic workflows are often the ones who were already operating this way: team leads and architects who had developed the habit of switching contexts and reviewing output rather than writing it. Everyone else has to learn that mode of working, which starts with understanding the difference between a specification and a plan.

A specification captures what the user wants. It doesn't change based on the current state of the codebase. It's set from the user demand, and it stays set. A plan is how you intend to build the thing given where the code actually is right now. "A plan is dependent on your state of the code," says Marius. "Plans usually get thrown away very quickly."

When Marius works with an agent on complex tasks (especially those with important architecture decisions), he asks it to write its plan to a markdown file before it starts executing so he can review it. Asking the agent to write its plan first forces a shared understanding of what's actually being built. You review it, ask questions, and surface problems before execution begins. It's the refinement stage of traditional software engineering, but the difference now is that the feedback loop is much faster.

Plans, done right, function as constraints. Marius thinks of this as keeping an agent in the acceptable solution space: the set of outputs you will actually accept. The further an agent drifts from a confirmed plan, the more likely it ends up somewhere that requires starting over. Forcing the plan upfront dramatically increases the probability of staying on track.

Plans help to keep your agent within the acceptable solution space

The plan also acts as a contract: it documents the approach the agent intends to take, so when it does something unexpected later, there's a reference point. "You can always reiterate to the agent, 'We decided to implement this plan. Why have you decided otherwise?'"

2. How to Scale: Parallelism and the Context Rot Problem

Even with a solid plan in place, there's a natural limit to how far a single agent session can take you: context rot. As a session grows, accumulating conversation history, prior decisions, and intermediate code states, the agent starts losing coherence. Tasks that were reasonable at the start become unpredictable midway through. Early decisions can come back to bite you. At some point, recovery means starting over.

Most engineers treat this as a nuisance and work around it by brute force: shorter sessions, more restarts. Marius treats it as a signal that the work hasn't been decomposed correctly. "If you have a huge feature and you develop on it for the whole week, you will keep having context rot," Marius says. "It makes much more sense to plan out what you want to implement ahead of time and then develop each of the sub-problems individually in small context windows."

This is where parallelism comes in: you run multiple agents simultaneously, each working on a specific sub-problem. But parallel agents writing to the same file system will conflict (the same reason Git was invented). You need each agent working in its own isolated environment.

To address this, Marius built a solution into his own custom IDE, before building Kilo's Agent Manager: a tool for running multiple agent sessions simultaneously, each in its own isolated workspace, with its own file system. Instead of supervising agents one at a time, an engineer can delegate across several concurrent workstreams and review the results as they come in. Things that look good get merged; things that don't get discarded without the cost of untangling a week of compounded decisions.

Not every task demands the multi-agent treatment. Marius works across three categories depending on complexity:

How Marius routes tasks based on their complexity

Easy tasks: Things like adding documentation, writing a unit test, or well-scoped bug fixes go to a fully autonomous cloud workflow. The developer writes the spec, the agent executes, the developer reviews the diff. No supervision is required mid-session.

Hard tasks: Implementing a complex feature spanning UI and backend, or anything with meaningful architectural decisions, gets handled locally with Agent Manager. The developer supervises multiple agents working in parallel on decomposed subtasks, stays close to the work, and makes the judgment calls as diffs come in.

Unclear tasks: When the outcome isn't well-defined, it's hard to write a spec precise enough to constrain the agent toward a single solution. For these, Marius runs multiple agents in parallel against the same spec and compares the results. Instead of splitting work, the parallelism here is about generating variants and selecting the best one. The engineer's job is choosing the right route.

3. How to Stay on Track: Context Engineering and Judgment

Context engineering, as Marius defines it, is how you structure and optimize the context of the agent. The goal is to limit an agent to doing exactly what you want, over time, in your codebase. It's the ongoing work of keeping agents oriented, and knowing how to reorient them when they've drifted.

For upfront orientation, Marius uses Handy, a speech-to-text tool, to interact with agents verbally before locking in a plan. A lot of the context that matters for a task lives in the engineer's head and never gets written down, because it's too tedious to type everything out. Speaking it aloud removes that barrier, and an LLM can distil the rough transcript into a precise problem statement. The rough transcript also becomes the raw material for the plan the agent writes before executing.

When an agent session ends—whether it hit a context limit or simply reached a natural stopping point—continuing the work is usually straightforward. The original prompts, the Git diff (Agent Manager measures the delta from when the session started), and the current state of the codebase give a new agent enough to pick up where the previous one left off. Tools like Repomix can help with collecting specific file trees for this purpose. All of this can happen locally or in GitHub, where an issue describes the task, the PR contains the changes, and the history provides the thread. Most agents can continue from that context without much intervention.

What this process makes visible is what's actually irreplaceable: the context that isn't captured anywhere. Code and prompts are always an approximation—there are causal relationships in software that are hard to capture in prompts or code alone. Some of them, like another team's architectural decision creating a dependency you didn't know about, can be surfaced and handed off. Others only become visible when you run the code or at scale. An agent can't know what hasn't surfaced yet—that's still the engineer's job.

This is the difference between just coding and software engineering. The easy mistake with agentic work is treating it as a handoff: you describe what you want, the agent builds it, you ship it. In that approach, the critical last 20% can get lost: things like evaluating architectural choices and catching when an agent has veered off course. These require engineering judgment, and they're often much harder than the first 80%.

The mental shift Marius describes is about learning to apply engineering judgment at the right moments, across multiple concurrent threads, rather than sequentially inside a single one.

Read the other posts in our Kilo Speed series:

Cowboy Coder Is Back. This Time, They Scale

Job from Kilo — Wed, 13 May 2026 12:00:53 +0000

Cowboy Coder Is Back. This Time, They Scale

Andrew Storms
May 11, 2026

I should start by admitting I'm part of the problem.

I can still draw the architecture of code I wrote three years ago from memory. The data flow, the edge cases, the reasoning behind every choice that looks strange at first glance. Ask me to do the same for a feature I shipped last month with help from an agent, and I can tell you what it does and why we built it. The deeper model, the one that lives at the level of individual functions, isn't there.

That's not laziness, and it's not a lapse in review. I read every diff. An agent does a closer pass alongside me. I can speak to the intent and shape of what I'm approving. But the deep mental model, the one you actually need at 2am when something breaks and the agent isn't helping you debug, isn't forming the way it used to.

I'm a CISO who still writes code, and this worries me. It should worry anyone managing engineers right now, because it isn't just me. Across the industry, AI coding agents are quietly reviving the single worst antipattern in software engineering history. We just don't recognize it yet, because it's wearing different clothes.

Remember the cowboy?

If you've managed engineers long enough, you know the cowboy. The one who disappears for a weekend and comes back Monday with a full rewrite nobody asked for. The one who, somehow, is the only person who understands the gnarly billing module, the auth flow, the deployment pipeline. The one whose decisions land in production faster than the team can review them.

Cowboys aren't heroes, by the way. The hero is the engineer who pulls the 2am save when production breaks. The cowboy is the one who created the conditions that made the 2am save necessary in the first place. Heroes clean up. Cowboys cause.

For twenty years, our industry has been quietly learning how to build engineering organizations that don't depend on this person. Code review. Pair programming. Design docs and RFCs. Collective code ownership. Postmortems that look at process, not blame. The whole inheritance from XP, agile, and DevOps was, in large part, a response to the lesson that cowboy culture feels productive and is actually corrosive.

It worked. Not perfectly, but the average engineering team today is far more resilient than the average team in 2005.

Then the agents arrived.

Watch what happens on teams that have adopted Claude, Cursor, Copilot, Codex, and the rest without changing how they work. An engineer prompts an agent. The agent emits eight hundred lines of code. The engineer skims it, sees the tests pass, and merges. Repeat, ten times a day, across the team.

The output is enormous. The velocity charts look incredible. And underneath, something is going wrong that nobody is naming yet.

Nobody on the team has reasoned through that code. The "author" couldn't walk you through it under questioning. They didn't write it, they prompted it. The reviewer couldn't either; they had thirty other PRs in the queue, and half the time the reviewer is another agent. Six months from now, when something breaks at 2am, the engineer who gets paged will be debugging code that has, in any meaningful sense, no human author at all.

This is the cowboy pattern. The weekend rewrite, the opaque module, the knowledge silo, the tech debt nobody quite remembers creating. Same antipattern, new substrate.

Why it's actually worse

The cowboy archetype, for all its damage, had one redeeming feature: somewhere, in one human brain, the model of the system existed. Bus factor of one.

Development driven by agents, without comprehension, produces bus factor zero. The code enters the repository with nobody understanding it. There is no expert to consult, because the "expert" was a probability distribution that has since moved on to the next prompt.

The social brakes that used to slow cowboys down are also gone. Cowboys had egos, reputations, and peers who could push back in code review. Agents have none of these. They don't sulk when overruled, don't take credit, don't feel shame when prod breaks. The friction that used to make cowboy culture limit itself in healthy teams, the simple fact that other humans were watching, is absent.

And there's a new accountability sink. When the cowboy shipped a bad rewrite, you knew whose desk to visit. When an agent ships a bad rewrite, the conversation goes "well, the AI wrote it" and everyone shrugs. The blame diffuses into the tooling.

What managers should do now

The good news: the playbook for fixing this already exists. We wrote it the last time. It needs updating, not reinventing.

Require comprehension, not just approval. Before any meaningful PR written with an agent gets merged, the author should be able to walk through it without asking the agent again. If they can't explain why a function exists, the PR isn't ready. This is the most impactful change you can make, and the one I'd benefit from most personally.

Cap PR size, hard. Code review evolved assuming limited human throughput on both sides. Agents broke that assumption. A PR of 50 lines can be meaningfully reviewed; a PR of 800 lines gets approved without thought. Set a limit, enforce it in tooling, and force large changes to be decomposed.

Tag agent involvement and track it. Make AI authorship a first class piece of metadata on commits and PRs. Watch incident rates, time to debug, and refactor cost on modules where agents wrote most of the code, and compare against the rest. You can't manage what you can't see, and right now most engineering orgs are flying blind on this.

Protect the loop of deliberate practice. Junior engineers who never struggle through a hard bug don't become senior engineers who can debug under pressure. Build in rotations without agents, pair on hard problems, and make "can debug from scratch" part of your leveling criteria. The seniors riding herd on agents today learned their craft the hard way. The next cohort needs a path to the same skill, or you'll wake up in five years with a team that can prompt fluently and reason about nothing.

Reframe tech debt as unread code. The most dangerous code in your repository is no longer the bad code. It's the unread code, modules that work today and that nobody on the team has actually internalized. Schedule comprehension audits. Assign engineers to read and document modules written by agents that they didn't author themselves. Treat unread code as a liability on the books.

This is not an argument against AI

The agents are useful. The productivity gains are real. I use them every day, and I'm not giving them up.

The point is that the technical productivity of these tools is arriving faster than the organizational practices needed to absorb them. The teams that already had healthy engineering culture, the kind with code review that actually reviews, sustainable pace, and collective ownership, will adapt and thrive. The teams that quietly tolerated cowboys are about to have a much worse problem, at much greater scale, with no single person to point at.

And the rest of us, the ones who can still picture the flow of code we wrote three years ago but no longer build that same depth of model with the new stuff, need to be honest that the muscle is atrophying. Mine is. Yours probably is too.

The cowboy didn't go away. The cowboy scaled, with a million tokens of context. The work of engineering management is to recognize the pattern in its new form and apply the lessons we already learned the last time.

7 Unexpected Ways AI Makes Your Team Faster

Job from Kilo — Mon, 11 May 2026 11:58:46 +0000

Most enterprise teams adopt AI coding tools expecting one thing: faster code output. And sure, that happens. But the teams getting the most out of AI are finding speed in places they didn't anticipate. The decisions, the handoffs, the context switches, the organizational friction that quietly eats weeks off every quarter. That's where the real time goes, and that's where AI has the most room to compress it.

Here are seven of those less-obvious wins, based on what we're seeing across engineering orgs using Kilo at scale.

1. Decisions that don't stall in Slack threads

A lot of good engineering decisions happen in Slack threads. Two or three people hash out an approach, agree on a direction, maybe sketch out some pseudocode in a message. Then someone has to take all of that context, switch to their IDE, reconstruct the conversation in their head, and actually implement it. That translation step is where momentum dies. The idea was clear in the thread, but by the time someone sits down to build it, they're re-reading messages and second-guessing what the team actually agreed on.

Kilo for Slack can read the full thread context, understand what the team discussed, and start implementing directly from the conversation. Instead of someone manually distilling a Slack thread into a ticket and then into code, Kilo picks up the intent from the discussion itself, with all the nuance that multiple contributors added along the way. The gap between "we agreed on an approach" and "someone started building it" shrinks from hours or days to minutes.

For engineering teams, this changes the rhythm of how work gets kicked off. Conversations become the starting point for implementation, not a precursor to yet another handoff.

2. Code contributions from people who aren't engineers

Product managers, designers, data analysts, and other non-engineering team members are able to use AI agents to write and submit code. They can describe what they need, have an agent generate a PR, and push it up for an AI-powered review. Some years ago that PR would have been dead on arrival. The code might work, but it might not follow the team's conventions, handle edge cases, or meet the bar for production.

Kilo's Code Reviewer changes that equation. When a non-engineer submits a PR, the reviewer analyzes it against performance, security, style, and test coverage, then gives structured feedback the contributor can actually act on. The contributor iterates with their agent based on that feedback, resubmits, and the cycle repeats until the code reaches an acceptable level. Each round takes minutes, not days waiting for a human reviewer to find time.

The impact for enterprise teams is significant: work that used to require an engineer's time from start to finish can now arrive as a reviewable PR from someone outside the engineering org. Engineers still own the final approval, but they're reviewing and approving instead of building from scratch. That frees up engineering bandwidth in a way that no amount of "write code faster" tooling can match.

3. Onboarding that doesn't require a sherpa

New engineers joining a large codebase used to spend their first few weeks in a fog. They read docs that are three sprints out of date, ping senior devs with questions that feel stupid, and take twice as long on their first PRs because they don't understand the conventions yet.

AI changes the dynamic. When a new hire can point an agent at the repo and ask "how does authentication work in this service?" or "what's the pattern for adding a new API endpoint here?", they get answers grounded in the actual code, not someone's best recollection of how things worked six months ago. Kilo's Ask mode works well here, providing read-only answers powered by codebase indexing. New devs ramp in days instead of weeks, and senior devs get fewer interruptions.

The compounding effect matters: every engineer who onboards faster is productive sooner, and every senior engineer who isn't answering onboarding questions is shipping their own work.

4. Documentation that actually updates

Every engineering team says they value documentation. Almost none of them have enough of it, because writing docs is tedious and the codebase moves faster than anyone can document manually.

AI flips the economics. Generating docs from code is exactly the kind of structured, pattern-heavy task where AI agents perform well. A developer can point a webhook-triggered Cloud Agent at a new PR and get a first draft of internal docs, API references, or architecture decision records in minutes. That draft still needs a human to review and refine, but the difference between "edit a draft" and "write from scratch" is the difference between documentation existing and not existing.

For enterprise teams, this pays off across the org. Knowledge stops being locked in individual developers' heads. Teams that depend on each other's services can actually find out how those services work. The "bus factor" for any given system gets a lot less scary.

5. Maintenance work that stops being a black hole

Every codebase has a backlog of maintenance tasks that never rise to the top of the sprint: dependency upgrades, test coverage gaps, deprecated API migrations, lint rule enforcement. Each one is individually small, but collectively they represent weeks of accumulated drag on the team.

AI agents can handle a lot of this at volume. Kilo's orchestration capabilities let you break down a large maintenance initiative (say, migrating from one logging library to another across 200 files) into subtasks and distribute them to agents running in parallel. What used to be a quarter-long slog becomes a focused effort measured in hours.

The net effect is that the maintenance backlog actually shrinks instead of growing indefinitely. Teams spend less time working around known issues and more time building features that move the product forward.

6. Cross-team requests that don't take a sprint

In larger orgs, teams constantly need small things from each other. A backend team needs a new field exposed in an API. A frontend team needs a config change. A platform team needs a migration script. Each request is maybe a day of work for the team that owns the code, but it sits in their backlog for two weeks because it's nobody's priority.

When the requesting team can use AI to draft the change themselves (using agents that understand the target repo's patterns and conventions), the dynamic shifts. Instead of filing a ticket and waiting, they can open a PR with a well-formed change and ask the owning team to review it. The owning team spends minutes reviewing instead of a day implementing, and the requesting team isn't blocked for two weeks.

This might be the single most impactful change AI enables in enterprise settings, and it almost never shows up in productivity benchmarks.

7. Consistency that doesn't depend on tribal knowledge

Most large codebases have a "right way" to do things that isn't fully captured in any linter config or style guide. It lives in the heads of engineers who've been around a while, and it gets enforced inconsistently through code review when those engineers happen to be reviewers.

AI can formalize this. Kilo's custom modes and rules system lets teams encode their conventions, patterns, and preferences so that every developer (and every agent) follows the same playbook. New patterns get adopted uniformly instead of unevenly, and deprecated patterns stop spreading through the codebase via copy-paste.

For enterprise teams managing large, long-lived codebases, this is arguably the most valuable thing AI can do. Consistency across a large codebase reduces cognitive load for everyone who touches it, which makes everything else on this list work better.

None of these seven things are what most people think of when they hear "AI makes developers faster." They're not about generating code in fewer keystrokes. They're about removing the organizational friction, the coordination overhead, and the knowledge gaps that slow engineering teams down far more than typing speed ever did.

If your team is evaluating AI tooling and only measuring lines of code generated or time to first commit, you're probably missing the real value. The teams getting the biggest returns are the ones that recognized AI as a way to make the whole system move faster, not just individual contributors.

To see how Kilo fits into your engineering org, check out our enterprise plans or talk to our team.

Hermes vs. OpenClaw - When to Reach for Which Agent

Job from Kilo — Fri, 08 May 2026 10:53:38 +0000

Hermes vs. OpenClaw — When to Reach for Which Agent

Last week, someone in the Kilo Discord asked: "Should I switch from OpenClaw to Hermes?" I've seen this question pop up a dozen times since Hermes launched in February. It's the right question to ask — both are open source, both connect to your chat apps, both run tools and remember things. On paper, they look almost identical.

But after running both for the past two months, I think the feature checklists are a distraction — the design philosophies are where they actually diverge.

The One-Sentence Difference

Hermes packages a gateway around a learning agent.
OpenClaw packages an agent around a messaging gateway.

That distinction sounds abstract, but it has practical consequences for how you configure and interact with each tool.

What Hermes Gets Right

Hermes Agent comes from Nous Research and launched in February 2026. It's hit about 135,000 GitHub stars as of this writing. The headline feature is what they call a "learning loop" — the agent creates and evolves its own skills based on what it does.

From their feature docs:

Self-improving skills: The agent generates procedural knowledge from experience. Run the same task type a hundred times, and Hermes actually gets better at it.
Five sandbox backends: Local execution, Docker, SSH, Singularity, and Modal. You pick how isolated you want command execution to be.
Subagent delegation: Spawn child agents with isolated contexts and terminals. Parallel workstreams without context pollution.
Broader browser/voice stack: Browserbase, Browser Use, Firecrawl, local Chrome, plus native voice in Discord channels.

The Hermes documentation is worth reading even if you don't use it — the provider matrix alone covers 19+ providers with detailed auth flows.

What impressed me most was the checkpoint system. Before Hermes touches files, it snapshots your working directory. /rollback if something goes wrong. I've used this more times than I'd like to admit.

What OpenClaw Gets Right

OpenClaw has been around longer and has the larger community — roughly 369,000 GitHub stars and 13,700+ community-built skills. It started as a personal assistant project by Peter Steinberger and grew into something much bigger.

OpenClaw is fundamentally a gateway. The docs are explicit: "The Gateway is the single source of truth for sessions, routing, and channel connections."

What that means in practice:

Channel breadth: Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo, WebChat. One Gateway process handles all of them.
Multi-agent routing: Isolated sessions per agent, workspace, or sender. You can run different agents for different purposes through the same gateway.
Mobile nodes: iOS and Android apps that pair with the gateway for camera, canvas, and device actions.
Massive skill ecosystem: 13,700+ community skills covering everything from email to calendar to flight check-ins.

The architecture assumes you want one always-on process that routes messages to agents. That's different from Hermes's model of "here's an agent runtime that can talk to various platforms."

Known Pitfalls

Both tools have well-documented failure modes that the communities are vocal about. Worth knowing before you commit.

Hermes:

Self-evaluation always passes. Hermes evaluates its own work to decide if a task succeeded. The problem: it almost always thinks it did well, even when it didn't. This means the skills it auto-generates from "successful" tasks can encode errors. You need external validation for anything important.
Self-learning overwrites manual edits. The same system that auto-generates skills also overwrites your customizations. If you've spent time tuning a skill for a specific workflow, the agent may "self-improve" it back into something generic. Power users find this maddening.
Maturity gap. With only 11 releases compared to OpenClaw's 137, Hermes simply hasn't been tested at the same scale. Fewer updates means fewer chances to break things — but that's not the same as proven stability.

OpenClaw:

Updates break things. This is the most consistent complaint in the community. Users report roughly a 25% chance that any given update will break response delivery, cron jobs, or webhooks. The development process lacks the staging/testing discipline you'd expect.
Memory is unreliable. Agents forget instructions, cross-contaminate data between projects, and repeat mistakes. Memory retention issues are the #1 driver of user churn.
Self-hosting is the real barrier. Docker setup, SSH configuration, YAML files, security hardening, 24/7 uptime — users consistently report spending more time on infrastructure than on their actual agent workflows.

Trade-offs

A comparison on ScreenshotOne put it well: Hermes is "agent-first" while OpenClaw is "gateway-first."

Hermes optimizes for the agent becoming more capable over time. It's built for people who want autonomous agents that learn from experience.

OpenClaw optimizes for a persistent assistant you can message from anywhere. It's built for people who want infrastructure they can talk to.

Neither approach is wrong. But they lead to different outcomes:

Dimension	Hermes	OpenClaw
Learning	Native skill evolution	Skills are static (community-maintained)
Sandbox options	5 backends (local, Docker, SSH, Singularity, Modal)	Docker, SSH, local
Channel breadth	7 messaging platforms	24+ platforms and plugins
Community size	~135k stars, growing fast	~369k stars, larger skill library
Browser providers	6+ options including cloud services	Local Chrome + managed profiles
IDE integration	ACP support (VS Code, Zed, JetBrains)	CLI + browser control UI

Security Considerations

This matters more than people think. A Reddit thread documented OpenClaw's 2026 security incidents: 6 CVEs, 341+ malicious skills identified in the community repository, 135,000+ exposed instances found by Shodan.

OpenClaw grew fast. Some security assumptions that made sense for a personal tool on a laptop became dangerous when people started running it on public VPSes with open ports.

Hermes, being newer, has zero reported agent-specific CVEs as of April 2026. That's not because it's inherently more secure — it just hasn't had the same scale of exposure. Give it time.

Both projects now have sandboxing options and approval flows. But if you're deploying either on a server, audit the defaults. Neither assumes you're running on a hardened production box.

When to Pick Hermes

Hermes is the better choice if:

You want an agent that improves at tasks over time
You need multiple sandbox backends (especially Modal for cloud execution)
You're doing research-style workflows with subagent delegation
You want tight IDE integration via ACP
You're willing to trade ecosystem size for a more capable core agent

The learning loop is what justifies choosing Hermes over OpenClaw. If you're running the same types of tasks repeatedly — data analysis, code review, research synthesis — Hermes will genuinely get better at them.

When to Pick OpenClaw

OpenClaw is the better choice if:

You want to message your assistant from everywhere (24+ platforms)
You need the existing skill ecosystem (13,700+ skills)
You want mobile nodes for phone camera/canvas integration
You're building team infrastructure, not just a personal agent
You value stability over cutting-edge features

If your primary use case is "I want to message my AI from WhatsApp and have it do things on my computer," OpenClaw has that nailed.

The Cost Problem

This doesn't get discussed enough. Running either agent autonomously is expensive if you're not careful. Every message sends the full conversation history to the API, so costs compound within a session.

Users in the community report anywhere from $1-3/day on budget models to $130+/day on Claude Opus for heavy agentic use. The fix is aggressive session resets and picking appropriate models per task tier:

Quality-sensitive work: Claude Opus 4.6 (expensive, best agentic performance)
Daily driver: GPT 5.4 (thinking mode on medium+) or MiniMax M2.7
Budget automation: Qwen 3.5/3.6 (free on OpenRouter), GLM-5.1, Kimi K2.5

Flat-rate subscriptions (MiniMax at $10-20/month, Ollama Pro Cloud at $20/month) are rapidly replacing per-token billing as the community default.

What I Actually Use

I run both — and the community data confirms this is a growing pattern. The specific architecture that works: OpenClaw as orchestrator (planning, decomposition, multi-step coordination, scheduling) and Hermes as execution specialist (fast, repeatable task loops). They communicate via the ACP protocol.

OpenClaw handles my day-to-day messaging — it's the interface I talk to from Telegram. I've been using it for months and the skill ecosystem covers most of what I need.

Hermes runs on research tasks where I want the learning loop. When I'm doing a series of similar analyses, Hermes's skill evolution actually matters.

I could probably consolidate — Hermes's docs actually note that it's the "successor to OpenClaw" and they have a migration command (hermes claw migrate) — but I haven't felt the urgency. They solve different problems well.

Summary

Both projects are actively developed. Both have real communities. Both work.

Hermes is younger, more ambitious architecturally, and smaller in ecosystem. OpenClaw is more mature, broader in integrations, and has had more security scrutiny (for better and worse).

The 30% of developers who switched from OpenClaw to Hermes cite "maintenance fatigue" from debugging community skills and wanting the learning loop. The 35% who stayed on OpenClaw cite integrations and ecosystem breadth.

Pick based on what you actually need. If you want a persistent assistant you can message, OpenClaw. If you want an agent that improves itself, Hermes.

Or run both — they're free, and the resource overhead of a second process is negligible.

Links:

Mistral Medium 3.5 is Live in Kilo

Job from Kilo — Fri, 08 May 2026 10:44:59 +0000

Mistral Medium 3.5 is Live in Kilo

We're thrilled to announce that the public preview version of Mistral Medium 3.5 is now live in Kilo. This is Mistral's first blended model (it merges instruction-following, reasoning, and coding into a single 128B dense model) and it puts the lab instantly back on the OSS map.

If it's seemed quiet on the Mistral front for a while, that's because they've been heads-down building. This new model is a major leap for the lab, and the focus on agentic work — coding and agentic engineering — benefits all of us.

Mistral's new flagship is a dense 128B model with a 256k context window, built from the ground up for long-horizon agentic work. It merges instruction-following, reasoning, and coding into a single set of weights, with configurable reasoning effort so you can dial it up for a gnarly refactor or keep it light for a quick edit. It scores 77.6% on SWE-Bench Verified, putting it ahead of Devstral 2 and models like Qwen3.5 397B A17B. The vision encoder was trained from scratch to handle variable image sizes, and the whole thing can run self-hosted on as few as four GPUs.

And Mistral is sticking to their OSS principles: the new model shipped with open weights under a modified MIT license.

This is a serious new model for serious engineering tasks, and Mistral users will find that it's now the default for the Mistral Vibe CLI and Le Chat. And with Kilo, anybody can use the model among hundreds of other top models and always find the right tools for the job.

Use Mistral Medium 3.5 Everywhere You Use Kilo

The new model is available in the Kilo Gateway, so you can use it everywhere with a single login.

VS Code Extension

The upgraded Kilo Code VS Code extension now surfaces Mistral Medium 3.5 in the model switcher. Pick it for any task where you want a model that can hold a lot of context, reason through complexity, and produce structured output your codebase can actually consume.

Kilo Code CLI

Running Kilo from the terminal? Mistral Medium 3.5 is available there too. It's a strong choice for longer CLI sessions — dependency upgrades, test generation, CI investigations — where you want the model working steadily without losing the thread.

Cloud Agents

Kilo Code's cloud agent infrastructure is where Mistral Medium 3.5 really opens up. Kick off sessions powered by this model, walk away, and come back to finished branches or draft PRs. The model was built specifically for async, multi-tool work — running long stretches reliably, calling tools in sequence, producing structured handoffs. That makes it a natural fit for the tasks you want to delegate completely: module refactors, issue triage, test coverage gaps, incident investigations.

KiloClaw

Mistral Medium 3.5 is available as a model option across KiloClaw recipes. Whether you're running a personal claw or a work claw, you can now back those workflows with a model that handles complex, multi-step reasoning without breaking a sweat.

Try It in Kilo Today

Mistral Medium 3.5 is priced at $1.50 per million input tokens and $7.50 per million output tokens through the API. For a frontier-class 128B model at this capability level, that's competitive — especially for agentic runs that justify the context and reasoning headroom.

At a blended price of $3 per million tokens for general chat, and just $1.56 per million tokens for long-context summarization, it's more affordable than it might look at first glance.

Plus, if you grab a Kilo Pass you can embrace a healthy discount :)

Open the model switcher in the latest version of our VS Code extension, select it in your CLI agent config, or choose it as the backing model for your next KiloClaw recipe. It's available now in public preview — we'd love to hear what you build with it.

Originally published on the Kilo Blog.

KiloClaw in VS Code, Kilo CLI in KiloClaw

Job from Kilo — Fri, 08 May 2026 10:42:14 +0000

KiloClaw in VS Code, Kilo CLI in KiloClaw

When your AI agent lives inside your AI coding assistant (and vice versa)

By Brendan O'Leary · May 04, 2026

Last week in the Kilo Discord, someone asked if they could SSH into their KiloClaw instance from VS Code. Not to use Kilo Code — just to edit their agent's AGENTS.md file directly. A few messages later, another person asked how to get KiloClaw chat working inside their editor.

Same underlying need from two directions: how do I talk to my always-on agent while I'm in the middle of writing code?

Kilo Code shipped answers to both in April. KiloClaw now has a native chat panel inside the VS Code extension. And the Kilo CLI — which ships built into every KiloClaw instance — got org-aware /kiloclaw support so you can manage your cloud agent from the terminal.

What this looks like in practice

KiloClaw in VS Code means you open the KiloClaw chat panel alongside your Kilo Code sidebar. You're editing code with Kilo Code's agent on one side, and on the other you have your KiloClaw agent that's running on a server somewhere — doing background work, monitoring things, managing tasks. Interactive coding in one panel, autonomous agent in the other.

Kilo CLI in KiloClaw means your cloud-hosted KiloClaw instance has the full Kilo CLI available. Your agent can use kilo run to spin up coding sessions on its own projects, use kilo pr to check out and review pull requests, or invoke any of the 500+ models through the same interface you use locally.

Josh from the Kilo team said it plainly in Discord:

KiloClaw ships with Kilo CLI built-in. We are also working to integrate KiloClaw inside of the extension. Being able to start a session, pick it up with KiloClaw, set KiloClaw to do work autonomously, etc. is pretty powerful.

Setting up KiloClaw in VS Code

The panel shipped in v7.2.20 and is available now if you have a KiloClaw instance.

Update your VS Code extension to the latest version
In the sidebar, click the KiloClaw icon (chat bubble) or open the Command Palette and run KiloClaw
If you already have a KiloClaw instance configured through Kilo Gateway, you'll see the chat panel with your agent's conversation history
If you don't have one yet, you'll get a setup view that walks you through provisioning

The panel uses the same Stream Chat WebSocket as the web UI, so messages appear in real time. Your agent's responses stream in, and the panel restores automatically when you reopen VS Code.

One detail I noticed: it uses the same kilo-ui component library as the rest of the extension. Markdown rendering, buttons, toast notifications all match. Doesn't feel bolted on.

Using Kilo CLI inside KiloClaw

If you're running KiloClaw (either self-hosted via OpenClaw or on Kilo's managed hosting), the Kilo CLI is already there. Your agent can invoke it directly.

A few patterns I've been using:

Your KiloClaw agent watches a repo for new PRs and uses kilo pr <number> to check them out and run a review session. Results come back to you over Telegram, Discord, or wherever you get KiloClaw messages.
You tell your agent "refactor the authentication module" and it uses kilo run with the right model and mode to do the work, commits the result, and opens a PR for you to review.
Your agent has access to multiple repos and can run separate Kilo sessions in each one, coordinating changes that span services.

The /kiloclaw command in the CLI now supports organization contexts too. If you've selected a team via /teams, running /kiloclaw resolves to that org's KiloClaw instance rather than your personal one. Useful if your company has a shared agent for CI tasks.

Why both

Kilo Code in VS Code is interactive. You're pair-programming with it. It sees your editor state, your file tree, your terminal output. It works in your context.

KiloClaw is persistent and autonomous. It runs when you're asleep, handles background tasks, monitors systems, processes incoming requests. It works in its own context, on its own machine.

Having both accessible from the same editor means you can tell your KiloClaw agent to start a background task while you keep coding, check in on what it found overnight, or hand off a tedious refactor while you work on the interesting parts. When it finishes, the results show up right there in your editor.

I've been doing this for the last week. Writing code with Kilo Code, glancing over at KiloClaw to see what my agent turned up from the research I asked it to do that morning. No tab switching, no opening a separate app. It's there.

Rough edges

This is new. A few things to know:

The KiloClaw panel requires Kilo Gateway authentication. If you're using Kilo Code with just a bare API key and no Kilo account, you won't see the panel.
The /kiloclaw command in the CLI only works when connected to Kilo Gateway. Same prerequisite.
Error handling got improved this week — there was an issue where failures in the WebSocket connection could leave the panel in a bad state. That's fixed in the latest release.
Documentation is still catching up. There's an open PR to add a "Setting Up Other Tools" page for KiloClaw that should cover this in more detail once it lands.

What's next

Your coding assistant and your autonomous agent used to be separate tools with separate UIs. Now they share the same extension, the same underlying engine, and the same model ecosystem. I expect the boundary between "interactive coding agent" and "background autonomous agent" to keep blurring.

I use both daily. KiloClaw runs my email checks, monitors Discord, handles blog research (it's writing this post right now, actually). Kilo Code handles the interactive stuff — writing features, debugging, reviewing diffs. Having them in the same window means I stop context-switching between tools to check on what my agent is doing.

If you're running KiloClaw already, update your VS Code extension and try the panel. If you're just using Kilo Code, the /kiloclaw command in the CLI is how you'd set up your first instance.

Originally published on the Kilo Blog.