DEV Community: Job from Kilo

The Model Mix Is Growing, and Moving In-House

Job from Kilo — Fri, 06 Nov 2026 19:30:00 +0000

Developers are spreading their work across more models from more labs, and more of that work is running on models teams host themselves. Data published this week from OpenRouter, our own usage dashboard, and a talk by Revolut's AI ops lead all point the same way. The single-model setup is fading, and the default model is increasingly one you can run on your own hardware.

Teams now run a portfolio of models

OpenRouter reported on November 2 that customers spending $100 or more a month now use a median of 6 model families, which is double the figure from a year ago. The top 10% of those customers went from 7 to 14. For a while, the trend ran the other way: the count fell through the first half of 2025 and bottomed at 3.8 in June, then climbed every quarter to 7.3 in October 2026; the highest OpenRouter has measured.

The heavier the usage, the wider the spread. In October, the median customer spending $100 to $1K a month used 5 labs, those spending $1K to $10K used 8, and those above $10K used 12. Among the $10K+ group, 90% used five or more labs.

Loyalty to a single lab has become rare. Fewer than 4% of any major lab's users on OpenRouter use that lab alone, and even Anthropic, which OpenRouter calls the stickiest, accumulates only 39% of its customers' spend. OpenRouter does point out the obvious selection bias, since people come to a router to use more than one model. What stands out is the reversal: after a period of consolidation, the number of labs per customer is rising again.

Inside Kilo, each agent role has its own favorite

Our model dashboard shows the same spread inside a single tool. The leading model changes with the job, and no model takes more than 30% of any role.

Nvidia's Nemotron models lead code, plan and debug. Review is the odd one out, and it is where frontier models from Anthropic and OpenAI show up most.

In review, Claude Opus alone takes 11.5% of usage and GPT models add another 14.4%. In code, the only frontier model in the top 10 is gpt-6-luna at 1.4%.

Developers appear to use cheaper models to write and fix code, then pay for a stronger model at the point where mistakes get caught.

Open models are running on teams' own hardware

Another story came out today about Revolut, and how it now serves a self-hosted open model, GLM 5.3, as the default coding model for about 2,000 of its engineers. David Abitbol, who leads AI operations at the bank, described the setup at AI Engineer NYC on October 13, and the talk spread widely on X this week.

The move started with cost. Abitbol said some engineers were spending $1,000 to $10,000 a month on frontier coding tools "with not so much ROI." Revolut began self-hosting in April 2026 with GLM 5.1 and now runs GLM 5.3 on about 56 Nvidia B200 GPUs, at a blended cost of about 30 cents per million tokens. By his account, the bill is one tenth of what Revolut spent on Anthropic and OpenAI.

The bigger result was speed. Revolut measured a 70% improvement in lead time and a 60% improvement in coding time after moving to self-hosted GLM 5.1. Abitbol's explanation is that a flat bill meant engineers stopped rationing tokens and started using AI for Jira, Confluence and inbox work too.

A default you control, and frontier models where they earn it

Both trends lead to the same setup: a cheaper model you control handles routine work, and frontier models are saved for the steps where they pay off - and if your hardware can handle it, local AI has been proven to work at enterprise scale.

You can set this up in Kilo today:

Pick a model per agent. Set per-agent defaults on the Settings → Models tab or in kilo.jsonc, so Code and Debug can run on an open model while review uses a frontier one. See Model Selection.
Connect a local or self-hosted model. Kilo Desktop lets you load and use local models directly in the app. Install here
Let routing pick the cheapest model that works. Auto Efficient (kilo-auto/efficient) sends each request to the cheapest model proven accurate enough for that task.

The live usage numbers behind the tables above are at kilo.ai/models, and they will keep shifting as new open models land

Nobody Should Knock Your Stack Down

Job from Kilo — Fri, 06 Nov 2026 11:00:00 +0000

This piece was written by my colleague Federico. I’m sharing it here because her dad’s punch card story stuck with me, and I think it’ll stick with you too.

The deck of punched data cards

"The cruelest prank on campus," said dad as a brief smirk crossed his face, "was to knock someone's stack of data cards to the floor and watch 'em scatter." My father, Eduardo, was an industrial engineering student at the Pontificia Universidad Javeriana de Bogotá, back in the 1970s. To run code on the IBM computers of the day, students fed in precisely ordered stacks of cardboard cards with punched holes, for mathematical calculations.

If your cards were numbered, you had a way to reconstruct the deck. If they weren't, good luck: back to square zero. Programmers punched sequence numbers into columns 73 to 80 of each card so a sorting machine could put a deck back in order, but freshmen weren't that meticulous. I still think about that story whenever we both talk about how far we've come with tech.

A FORTRAN statement on an 80-column punched card, used at the University of Stuttgart in the early 1970s. Photo: Harke, CC BY-SA 3.0, via Wikimedia Commons.

Students today have access to coding agents on their laptops that can tackle problems my father and his classmates would only have dreamt of, tokens are our new set of punched data cards.

Closer than you think

I was born and raised in Colombia and spent six months in New Orleans, attending High School in the 90s. Some classmates asked whether we lived in huts, up in trees, or knew what an airplane was. I understood where their curiosity without malice was coming from: distances both geographical and technological were a real gap.

The internet has bridged that. I'm sitting at a café in "El Corralito de Piedra" (Cartagena de Indias), working with my team thousands of miles away in the U.S. and Europe. A student in Buenos Aires, an engineer in São Paulo, a developer in Austin, they have access to much of the same technology. Still, having access to a tool isn't quite the same as having control over it.

Someone can still knock your cards down

This time it won't be the prankster knocking your stack down, but the cost of tokens and the ever-changing terms of service of the companies and services you depend on. Cursor's current Plus plan includes only Grok models; third-party models on higher plans are billed separately by usage. Meanwhile, OpenAI proposed November 12 as the end of the agreement under which it supplies its models to Cursor. On October 29, Cursor reported a malicious extension posing as Claude Code in its marketplace; it was available for about 11 hours.

These are just examples of how vulnerable developers are while building workflows around tools whose pricing, availability, model selection, etc., depend on others. A pricing change or provider disagreement won't break your code, but changes how you build it, if you can afford it and the moat built around it that impedes change.

Earning in pesos or reais, paying in U.S. dollars

For Latin American developers it's difficult to budget given the dollar's fluctuation. A monthly token bill denominated in U.S. dollars doesn't stay the same in pesos or reais. Even as providers leave service prices unchanged, exchange-rate movements make your margins unpredictable. In Colombia, the dollar went from 4,478 pesos in November 2024 to 3,048 in August 2026, a 32% swing in under two years. In Brazil, the dollar jumped from 5.04 to 5.50 reais in a single day this past October. In Mexico, it climbed from 16.86 to 18.79 pesos between September 4 and October 30, 2026.

Token-based billing adds another moving part to an already unpredictable budget. Gartner expects AI coding costs to pass the average developer's salary by 2028 as token consumption grows. Choosing a model isn't about benchmark scores only, it's a decision about what you can afford to keep using in the upcoming months.

This isn't a purely Latin American concern. In Stack Overflow's 2026 Developer Survey, 32.6% of the 1,033 developers who answered a question about how cost or usage limits affect their AI use at work said they personally monitor usage, and 25.3% said they choose cheaper models when possible. Those figures come from a global, self-selected sample, not a Latin American survey. Still, they make the point: cost is already changing developer behavior.

Talent is there

Latin America is bigger than we credit it for in the developer world. GitHub's Innovation Graph counted roughly 20.4 million developer accounts across 21 Latin American economies (Q2 2026), more than China's 11.8 million. That includes 3.1 million in Mexico and about 1.8 million each in Colombia and Argentina. Those are GitHub accounts, not a census of employed engineers. Brazil had 10.2 million developers on GitHub as of September 2026 (GitHub's Octoverse 2026). It added 3.28 million this year, the third most of any country.

Latin America's developers are already using agents to write code, debug, and open pull requests, and they're learning about the next generation of tools. Whether they can make independent choices regarding the tools they increasingly depend on is a different question.

Keep your options open

Kilo Desktop by Anaconda lets you work in a desktop workspace and choose over 500 hosted models through the Kilo Gateway, your own provider API keys, or compatible local models on your machine. It also brings code, files, terminals, git, and notebooks into the same working environment. A model dropdown lists the models your vendor has a deal with today, and those deals can change. We've made the case for model freedom before.

Kilo's individual platform is free to start with. Free model options exist, paid inference can be used on a consumption basis and you can also buy Kilo credits. Local inference avoids hosted token charges but demands proper hardware. Teams on a ChatGPT plan can sign in with ChatGPT and use the usage that plan includes, rather than paying per token through the API. Auto-Efficient sends each request to the lowest-cost model Kilo has measured as capable of that kind of task. None of this makes the economics disappear. It gives you more ways to manage them.

Developers are figuring out clever ways to stretch every token. At All Day AI, some pointed out how to route simple decisions to smaller and cheaper models while using frontier ones for more elaborate work. According to OpenRouter's Chris Clark, open-weight models now carry about 64% of the tokens but only 28% of the spending. Here is a summary of 5 best practices.

Choosing between models has its pros and cons, different models, different answers. You still have to test the output, understand the trade-offs, check how a provider handles your data, etc. Being able to make that call enables flexibility and adaptability.

Number your cards

My father's generation learned to number their cards because they understood how fast things could become a mess. This generation needs to understand what tools we depend on, and to keep options open.

Is your company using and paying for Cursor? Kilo Enterprise is free for the rest of that contract, up to a year, if you claim it by November 30. See the offer.

Download Kilo Desktop and try the same real coding task with two models. Heck, run one of the free ones, or download a small model and run it locally. Compare the results and the cost, and see what works for you. You shouldn't have to commit to one provider just to keep building.

There's always a practical joker willing to knock your cards down. It's up to you to be able to pick them up and carry on.

Know Your AI Toolchain: Lessons from the Cursor Marketplace Incident

Job from Kilo — Thu, 05 Nov 2026 13:00:00 +0000

A fake Claude Code extension sat in Cursor’s marketplace for 11 hours. Here’s what every engineering team should check now, and why it’s a good moment to rethink who controls your AI stack.

On October 29, a tampered build of Anthropic's Claude Code extension, version 2.1.313, appeared in Cursor's VS Code extension marketplace. Anthropic didn't build it. It was live from about 2:27am to 1:35pm PT, and up to 5,000 users may have installed it.

Cursor caught it, pulled it, shut down the marketplace, rotated keys and worked with the host to take the attacker's server offline. They also published a clear, detailed security notice. That's the right response, and they deserve credit for it.

But the attack itself is the part worth studying. It was simple. And it will happen again, to some tool, somewhere.

What the extension did

The malicious build tried to plant a persistent SSH backdoor. According to Cursor, it:

Collected host details: hostname, username, OS, home directory, environment variable names, Git email and public IP.
Added an attacker-controlled SSH key (labeled svc-telemetry) to authorized_keys.
Tried to enable the local SSH service and open a reverse tunnel. This step failed on most machines, because it needs admin rights.
Installed persistence through a LaunchAgent on macOS or a scheduled task on Windows, retrying the tunnel every 60 seconds.
Reported back to the attacker over HTTP.

If you installed or updated that version during the window, act now. Check for the svc-telemetry key, run Cursor's remediation script, and rotate credentials from a clean machine. Uninstalling the extension alone is not enough. The payload leaves scripts that keep running. Cursor's notice has the full steps and indicators of compromise.

Why this one matters

Nothing here was clever. A trusted name. A new version number. An install or auto-update. That was enough.

The lesson is bigger than one marketplace. AI coding tools now run a growing stack of add-ons: extensions, MCP servers, skills and plugins. Many of them can read your repo, run shell commands and touch your environment. Your software supply chain has moved into the editor, and most teams aren't watching it yet.

Know Your AI Toolchain

One of our engineers put it well in an internal thread: teams need a habit of knowing their AI toolchain. For every extension, MCP server, skill and plugin, you should be able to answer four questions:

Who made it? Is the publisher who you think it is?
What changed? What's different in this version from the last one you trusted?
What does it do? Does its behavior match its stated purpose?
What is it allowed to do? Which files, commands, networks and secrets can it reach?

In practice, that means a few concrete steps:

Allowlist publishers and pin versions for anything with shell or file access. Don't let agent extensions auto-update unreviewed.
Run editors without admin rights. In this incident, missing admin rights stopped the worst step on most machines.
Review MCP servers like dependencies. Know where each one comes from and what tools it exposes.
Watch the usual persistence spots. ~/.ssh/authorized_keys, LaunchAgents, scheduled tasks and startup folders.
Centralize policy. Developers shouldn't each decide alone which tools and models are safe.

Where Kilo stands

To be clear: no editor is immune. Kilo ships as an extension too, and we hold ourselves to the same four questions.

Here's how we help teams answer them:

Open source. Kilo's code is public on GitHub. You can see what it does and what changed.
Admin controls. Kilo Enterprise lets you set which models and providers each org and sub-org can use, with SSO, SCIM, role-based access and audit logs.
Provider policies. Filter providers by training policy, prompt retention and location.
Coding guardrails. Kilo works with Enkrypt AI's guardrails, which check each prompt, tool call (including shell commands) and tool result against a policy your security team sets. A pasted API key, or an instruction hidden in a README, is blocked before the agent acts on it, and every block is logged for audit.
Coming next. Admins will be able to turn on guardrails for every Kilo user in one place, and MCP Scan and Skill Scan, by Enkrypt AI, will check MCP servers and skills before they run

The other reason teams are rethinking Cursor

Security isn't the only pressure. Cursor's model access is shifting too:

OpenAI has said it won't supply future models to Cursor following Cursor's acquisition by SpaceX.
OpenAI model access in Cursor is scheduled to end November 12, 2026.
Cursor's new X Subscription plans drop the included third-party model allowance.

The common thread: your toolchain shouldn't depend on one vendor's marketplace or one vendor's provider deals. You should control both.

The Cursor Exodus: Kilo Enterprise, free for your remaining term

If you're on a Cursor enterprise contract and want out, we'll make the move easier. Through the Cursor Exodus offer:

Kilo Enterprise is free for the rest of your Cursor contract, up to 12 months.
Seats match 1:1 with your Cursor seats.
500+ models, including GPT, with zero markup on token prices through the Kilo Gateway.
Bring your own keys, local models or eligible ChatGPT Plus and Pro subscriptions.
Apply by November 30, 2026.

AI usage is billed separately, and no credits are included. The offer is discretionary and needs a signed attestation plus a redacted proof of your Cursor contract. It doesn't cancel or reimburse your Cursor contract.

You don't have to switch overnight. Pilot Kilo on real repositories alongside Cursor, compare quality and cost, then roll out. Our migration guide walks through it, and you can read what Anaconda's engineers found when they made the same move.

The takeaway

Whatever editor you use, audit your AI toolchain this week. Know who made each piece, what changed, what it does and what it can touch.

And if you're ready to take back control of your models and your stack, claim the Cursor Exodus offer.

Open-Sourcing the Playbook Behind All Day AI, a 12,000+ Attendee Conference

Job from Kilo — Thu, 05 Nov 2026 08:11:42 +0000

TL;DR

All Day AI was a free, online, 16-hour marathon event with zero vendor pitches. We pulled it together in about two months, saw 12,313 participants and 140 speakers, and people stayed and watched for an average of more than 6 hours.

An event of this scale doesn't come together that fast without some serious sprinting, trial and error, and audible-calling. Plenty of people have asked how we did it, so this article open-sources the whole playbook: the goals, the team, the tools, the timeline, and the parts we'd change.

The Why

We built All Day AI for people who were under pressure to put AI to work but struggling to find advice they could trust. The tools and recommendations were changing week to week, and a lot of the conversation still led back to something for sale. We wanted a place where practitioners could explain what they had actually shipped, what had failed, and what another team could reuse.

That need shaped the format. Keeping the event free and online meant people could join from wherever they worked, without a ticket budget, a flight, or a travel approval. Banning vendor pitches kept the focus on useful lessons rather than a sales conversation. Across Build, Lead, Secure, and Ship, the goal was to give people clearer answers and peers they could keep learning with after the day ended.

The Hard Part

The first version of our website went up in August, and the event was slated to go live on October 22. That gave us roughly two months to hit our admittedly aggressive goals:

More than 10,000 registrants
More than 120 practitioner-led sessions
4 tracks: Build, Lead, Secure, and Ship
A surviving Discord community

What made those numbers hard was that we were starting from zero. There was no existing All Day AI community, no speakers signed up, no website, no event platform, and no social presence. Every registrant and every speaker had to come from something we built or someone we reached in those two months.

If you've run an online event with multiple speakers, you know that even one track can be a logistical nightmare. We knew 120+ speakers across 4 tracks could get ugly, fast, so most of what follows is about how we kept it from getting ugly: a committed team, a few deliberate bets, and a lot of help from AI agents.

The People

The most important part of the ADAI stack was the people. The core organizing team had more than 20 people across event co-founders, moderators, hackathon judges, ushers, and marketers, and they worked quickly and unselfishly through the build-up and especially on the day of. The team brought experience from organizations including Anaconda, Matejczyk Group, Carnegie Mellon University's Software Engineering Institute, Techstrong Group, ACI Worldwide, and Community Hackathons, produced by Crowdbyte Solutions.

This was a community event, so all of it fell outside everyone's day job. Nobody was paid to make All Day AI happen, and the fact that it happened anyway is a credit to how much the team believed in the project. They deserve not only credit but admiration.

Three Bets That Paid Off

Before we picked a single tool, we made a few decisions about what kind of event this would be. Those decisions shaped everything else, and in hindsight they did more for our numbers than any piece of software.

No vendor pitches, ever. Most conferences exist with at least a subtle motivation of money changing hands. People can sense that, and when they just want to learn, it's a turnoff. So we banned pitches from the jump. That gave us a simple promise to make to attendees and speakers alike: you're here to learn and to teach, not to be sold to.
Look like nothing else. Our goal for the website was to get visitors to understand right away that this wasn't a normal tech conference. Our hallmark "Rockin' Rooster" came out of a ~3 day back-and-forth with the team, where other ideas like "Rockin' Grandma" were rejected in its favor. We felt the rooster represented something new, loud, and disruptive, in a good way. I used a free online SVG converter to turn the original crude cartoon into a scalable logo.\
We carried the same idea into the speaker pages. Every headshot got a uniform background and photo effect inspired by vintage concert posters. I worked out the look in ChatGPT, then built a small app in Kilo Code that applied it programmatically through the OpenAI image API, so every new speaker matched the rest without manual editing. It wasn't long before people recognized the rooster before they even knew what the event was about, which is proof the branding landed.
Trust the community to spread the word. This was our biggest growth lever. On a random weekday in September, I had the idea to ask my Dot (an AI agent I'll explain below) to reach out to 3,000 tech groups, hackathons, and events around the world: anyone who might have a shred of interest in All Day AI. I proposed a free deal. Tell your community about our event, and I'll put your logo, link, and CTA on our website.\
Hundreds responded. Based on rough estimates of community sizes, I would safely attribute 20-30% of our registrations to that one message. It worked because the offer cost nobody anything, and because a free, pitch-free event is something community organizers are happy to share.

The Stack

With those bets in place, the job became execution, and the tools we chose were all about saving the team's time for the work only people could do.

Platform

We wanted to spend as little time and money as possible on event infrastructure, so we looked for a platform that could natively handle 5 stages, registration forms, communications, and recording. We landed on Zuddl, which was modular enough to meet our requirements without us stitching together separate tools.

Website

Version 1 was built in Kilo Code for VS Code using GPT 5.6 and cost about $5. It was stored in GitHub, deployed to Vercel, and used Cloudflare for domain management. Because the speaker lineup and partner list changed constantly, the site had to change constantly too. The team and I made PRs as the event evolved, and I approved and merged them.

Operations

Here's where we had to get crafty. We wanted to attract top speakers across the AI industry, and quality speakers want a clear point of contact with a name and a quick response time. A shared, generic email address wasn't going to cut it, so we used mine.

That solved the trust problem and created a volume problem: one person fielding 140 speakers' worth of email. To manage it, I used a series of AI agents with a human-in-the-loop editorial process.

OpenAI Dots. My Dot was the operating system for speaker communication. I gave it provisional access to Google Drive assets like the schedule and moderation Sheets and image collections, plus browser access to certain Zuddl lists and event settings. Then I had it send blasts and personalized speaker links, update Zuddl profiles, and manage moderation schedules. I stayed in the loop for every outgoing message, which let me track 140 speakers without holding the status of 140 email threads in my head. AI gets better with context, so the more I used the Dot, the more it understood the ADAI mission and the better it got at helping me.
Kilo. I let my Dot use the Kilo CLI on my computer to make site changes, which kept it more focused than asking it to generate GitHub PRs itself. When speaker information changed or I approved a new cohort, I asked the Dot to have Kilo update the site, so the website stayed in sync with the speaker list without a separate round of manual edits.
Instinct. Even with the Dot, my inbox became an absolute mess once we had about 20 of our 140 speakers. I gave Instinct, the agent that lives in iMessage, read-only access to my inbox and asked it to ping me whenever an urgent work item came in outside of All Day AI, so nothing from my day job got lost in the conference noise.

How It Played Out

Plans are one thing. Here's what the two months looked like in practice, including the moments where it nearly fell apart.

August 5--11: Concept and plumbing. A small group of the original core organizers outlined the event. A crude website appeared with placeholder registration, speaker, and volunteer forms while the team worked through platform, legal, and data requirements. We set the go-live date for October 22, 2026.

August 16--25: A slow start. Responsibilities were assigned, and I took on speaker operations. Speaker intake, terms, platform setup, and partner materials were still being assembled. On August 25, we had 100 registrations and 12 speaker submissions, not even 1% of the final counts. With less than two months to go, we had a lot of ground to make up.

August 28--September 11: Building in public. A readability-focused redesign prompted debate about losing the style of the first website. The first 22 speakers went up August 31, and a mobile registration issue was fixed September 3. Speakers didn't just show up on their own; programming took active outreach and curation, with roughly 20 submissions awaiting review by September 11.

September 14--30: The community takes over distribution. This is when the partner outreach started paying off. Community partnerships expanded through groups including AWT and NumFOCUS, and by September 28, registrations reached 2,725.

October 12: The rehearsal humbles us. Registrations hit 5,864, but the dry run exposed how much we were still learning about Zuddl. Momentum and production readiness turned out to be separate problems, and we'd been solving the first one much faster than the second.

October 13--16: A close call. A website-hosting payment warning forced a card replacement, and the site almost went down at the 11th hour. Speaker communications needed follow-up. By October 16, we had almost 8,900 registrations and 140 sessions locked, but we were still behind plan on registrations.

October 18--19: Crossing the line. The count reached 9,961 late on October 18, just shy of our 10,000 goal. Speaker-access issues kept surfacing, so after working with platform support, we organized a last-minute series of dry runs.

October 20--21: The run sheets land late. A preliminary moderator schedule circulated October 20, still dependent on available staffing. Full moderation schedules were finalized and posted at 9:40 p.m. the night before. By the end, the work was no longer about promotion at all; it was detailed human coordination.

October 22: Event goes live. We finished with 12,313 registrants, 140 speakers, and an average watch time of more than 6 hours.

What We'd Do Differently

Looking back at that timeline, most of the stress came in the last ten days, and most of it traces back to things we deferred while we chased registrations.

Earlier, more frequent speaker ops. Because we were crunched for time, we prioritized carefully: once a speaker was on board, we considered them done and moved on to other operational work. We should have made time for multiple dry runs, kept up ongoing comms with speakers, and gotten earlier commitments to scheduled sessions. No-shows were low, but they weren't zero, and we can plan for that next year.

Platform training for moderators and volunteers. We were lucky to have most of the moderation team in person in Austin, so we could squeeze in a day of last-minute Zuddl training. It takes a lot of behind-the-scenes work to get a speaker prepped and on stage, and it would have been less stressful to train moderators and ushers further in advance, ideally before the October 12 rehearsal rather than after it.

A dedicated speaker inbox. Reminder to myself for next year: don't use my work email for speaker comms. The agents kept it manageable, but a separate, named inbox would have given speakers the same personal point of contact without burying my day job.

Post-Event

All Day AI went from 100 registrations to more than 12,000 in about two months, built by volunteers, a $5 website, and a handful of agents. If you want to see what came out of it, you can watch all the recordings here. And if you want to be part of the next one, sign up for next year here.

Open Weights Are Ready for Production. Is Your Stack?

Job from Kilo — Mon, 19 Oct 2026 07:36:38 +0000

Panel recap: Kilo by Anaconda × Friendli AI × MiniMax

For most of the past year, open-weight models lived in the experiment column. Teams tried them, benchmarked them, and kept their production traffic on closed APIs. That is changing fast.

We recently co-hosted an evening panel with Friendli AI and MiniMax to talk about that shift. Each panelist represented a different layer of the stack: the agent harness, the model, and the inference engine. The conversation kept returning to one idea. No single layer decides the outcome. They all depend on each other.

The panel

Ari Messer, AI Partnerships, Anaconda (Kilo)
Victor Su-Ortiz, Product Marketing & DevRel, MiniMax
Yunmo Koo, Founding Engineer, Friendli AI
Alex Campos, Moderator, Friendli AI

Key Takeaways

Adoption is real now. Banks, fintech, and biotech are running open models in production, and the reason has moved from cost to performance and control.
Think in systems, not models. A reliable endpoint can still produce an unreliable agent once calls are chained together.
Architecture gains need engine work. New attention and cache designs only pay off when the inference layer is built for them.
Treat your inference provider as a partner. Then test on your own workload, not just public benchmarks.
Build evals and observability in from day one. It is the only way to keep up as models and hardware change.

Theme 1: The Conversation Moved From Cost to Control

Ari opened with what he sees across Anaconda and Kilo customers. Interest in open models has been around for a while, especially in regulated sectors that care about visibility and governance. What is new is actual production use.

"It's really just in the last couple of months that we're seeing everyone from our biotech clients to really big banks and fintech starting to lean in this direction. Some of the initial conversations were about cost. But now it's actually a lot more about performance and control." --- Ari Messer, Anaconda

Victor agreed, with a twist. Cost was "all the rage over the summer," he said, but the performance teams care about is not general benchmark scores. It is how well a model does in one domain, like legal or healthcare. More teams are fine-tuning and post-training open models for exactly that.

Cost still matters. Victor pointed to public usage data from OpenRouter and OpenCode, where fast, low-cost Flash models lead. Speed and price are still top priorities for most users.

Theme 2: From Model-Centric to System-Centric Thinking

Yunmo framed the biggest change teams face when they go to production.

"The biggest shift is moving from model-centric thinking to system-centric thinking." --- Yunmo Koo, Friendli AI

In experiments, you check a model card, plug the model into a coding tool, and see if it handles your task. In production, the question is whether the model can complete a complex agent pipeline reliably, within your latency and cost budget. He gave a simple example of why that is harder than it sounds.

95% → 60%: An endpoint that is 95% reliable drops to about 60% end-to-end reliability across a 10-step agent chain. Define success for the whole workflow, not one call.

He also warned against a common assumption. Open weights do not automatically bring better economics or performance. You take on responsibility for model choice and inference configuration. That is where an inference provider can carry the load so your team can focus on the product.

Victor added that cost per token is a useful number, but your own internal benchmarks on your own use cases matter most.

Theme 3: Models Built for Long-Horizon Agent Work

Victor explained how MiniMax's design shifted between its M2 and M3 series. Long-horizon tasks got much more weight. One-million-token context windows are now standard, because agents prompt over and over across many turns.

"A common practice I used to set for myself is to stay below 30% of the context window. But nowadays, up to 70 to 80%, I can't stop myself." --- Victor Su-Ortiz, MiniMax

To handle that load, MiniMax uses a sparse architecture and its own KV-cache optimizations, built for users who will push toward the full window when refactoring a whole codebase.

Yunmo added the inference view. Labs now design for intelligence and efficiency together, using hybrid attention, cache compression, and sparse indexing. But a better design on paper is not the same as a faster system.

"Theoretical improvement in the architecture does not always translate into real-world benefit." --- Yunmo Koo, Friendli AI

Linear attention, for example, does not use a standard KV cache. Without engine work tailored to how it manages state, it can even slow inference down. That is where model labs and inference providers need to work closely.

Theme 4: Safety, Governance, and Hybrid Deployment

Open weights give enterprises more control, and more responsibility. Ari said requirements vary by client, but safety testing and red-teaming come up again and again. You have to test the model and also how the agent behaves once it has access to it.

Anaconda does this with Enkrypt AI, which it acquired this year. It lets teams red-team models and agents in a similar way: the agent using the model, or the model placed in different agent environments.

Ari also described a growing interest in local AI. Picture running a model on a laptop for something very private, then moving that session into a shared cloud environment when the team needs it. Open models fit that movement well. Ari was candid that hybrid is still more vision than settled pattern.

"A lot of people don't want to deal with on-prem. That's what's being pitched to them, but they're like, there must be a different option." --- Ari Messer, Anaconda

Theme 5: The Human Layer Still Matters

Asked what it looks like when every layer works well together, Ari's answer was about people, not technology.

"There can be a tendency in any org where people think that their individual failures, like getting a lot of tool call errors, are their fault. And they don't really share it." --- Ari Messer, Anaconda

The most successful teams he sees share both wins and failures across groups. Victor agreed and closed with a line that got a laugh.

"This knowledge sharing is just as important given how early we are. Don't just chat with ChatGPT." --- Victor Su-Ortiz, MiniMax

Advice for Your First Production Agent on Open Models

Start with a Flash model. Ari's pick: "Flash models have come along really fast. They're really efficient, and they're fun to work with."
Go specialized. Victor suggested moving past generalist models and working with labs and providers on fine-tuning, post-training, or on-prem needs for your domain.
Embed evals and observability everywhere. Yunmo's top tip: build them "into every single step of your agent workflow," so you can quickly compare models and providers as things change.
Define success for the full workflow. Track reliability, latency, throughput, and cost end to end.
Share what you learn. Tool-call errors and odd traces are team knowledge, not personal mistakes.

Thanks to Friendli AI and MiniMax for co-hosting, and to everyone who came out and asked great questions!

NVIDIA Nemotron 3.5 Super VL Is a Builder Just Like You

Job from Kilo — Mon, 19 Oct 2026 07:30:23 +0000

Nemotron has become a family affair at Kilo by Anaconda.

Nemotron 3 Super launched as a 120B, A12B model and went live in Kilo on day one. Nemotron 3 Ultra followed as NVIDIA's flagship, and in August we went hands-on with Nemotron 3.5 Lightning, the fastest Nemotron yet. Along the way, Nemotron 3 Super became a daily driver for many Kilo Coders.

Now NVIDIA is back with what feels like a big leap forward for builders: NVIDIA Nemotron 3.5 Super VL.

We've been testing it in early access, and one thing stood out right away. This is a model built for hybrid work: sessions that move between code, data, screenshots, and video, and between Kilo Desktop, the CLI, and the IDE, without losing the thread.

What's New in Nemotron 3.5 Super VL

Nemotron 3.5 Super VL keeps the 120B total / 12B active parameter profile that made its predecessor so efficient, but it adds something big: it can see.

Under the hood, Nemotron 3.5 Super VL pairs a Nemotron-H hybrid language decoder with a RADIO vision encoder, a vision projector, and a dedicated temporal embedder for video, while keeping Multi-Token Prediction weights. That builds on the architecture NVIDIA introduced with Nemotron 3 Super, where Mamba layers handle memory and compute efficiency, transformer layers drive reasoning, and only 12B of 120B parameters are active at inference.

Here's what that means for builders:

A 1M-token context window with up to 131,072 output tokens, enough to hold an entire codebase, a long agentic session, and the docs that go with it.
Image and video input. Pass screenshots, UI mockups, charts, diagrams, or MP4 clips directly into the conversation.
Thinking on demand. Toggle reasoning on or off, set reasoning_effort to off, medium, or on, or cap thinking with a hard reasoning_budget so you control the speed/cost tradeoff task by task.
Tool calling with auto, required, and named function selection, the backbone of reliable agentic work.
Structured output via JSON schema, so agents return data your pipelines can actually parse.

That combination is rare in an open model. You get frontier-style controls over reasoning, native multimodal input, and the efficiency of a 12B-active MoE.

Built for Hybrid Work

Most real projects don't stay in one place. And as your real org grows, so do the virtual agent setups to support it.

You scaffold in the terminal, iterate in VS Code or JetBrains, explore a dataset in a notebook, then check a screenshot of a broken layout. Every handoff is a chance for context to get lost.

That's where Nemotron 3.5 Super VL has been especially strong for us, because Kilo was built for exactly this kind of work.

Kilo Desktop. Kilo Desktop puts an agent beside your code and your notebooks. From one conversation, the agent can write and edit code, create Python environments, explore data in notebooks, and review git changes. With vision in the loop, Nemotron 3.5 Super VL can read the chart it just plotted, spot what looks wrong, and fix the cell. Desktop also manages conda environments in-app, drawing from Anaconda's catalog of more than 19,000 vetted packages.

Kilo CLI. In the terminal, Nemotron 3.5 Super VL's efficiency and tool calling make it a dependable workhorse for scaffolding, refactors, and git-heavy tasks. Dial reasoning_effort down for fast execution, or up when the task calls for planning.

VS Code and JetBrains. In the IDE, paste a screenshot of a design or a bug and let the agent work from what it sees, not just what you can describe.

The best part is that these aren't separate worlds. Kilo Desktop starts a local copy of the Kilo CLI and drives it through chat, so sessions use the same runtime that powers the CLI and the VS Code extension. Nemotron 3.5 Super VL behaves the same way wherever you pick up the work.

Where Nemotron 3.5 Super VL Shines

In early testing, we've seen Nemotron 3.5 Super VL excel at:

Screenshot-to-code fixes. Reading UI screenshots and making targeted front-end changes.
Data work in notebooks. Interpreting plots and tables, then iterating on the analysis.
Long-context agentic sessions. Holding large repos and long tool-call chains in memory without drifting.
Structured, schema-bound tasks. Returning clean JSON for downstream automation.

Nemotron 3.5 Super VL scored 53% in KiloBench, similar to GLM 5.2 (also 53% in KiloBench). GLM 5.2 has been one of our most popular models ever, a daily driver across coding tasks and agentic work, so Nemotron 3.5 Super VL's similarly high score is very promising for builders looking into open models that can be run anywhere and support a wide range of coding and data work.

The Right Nemotron for the Right Task

With Nemotron 3.5 Super VL, the Nemotron lineup in Kilo covers the full range:

Nemotron 3 Ultra for deep reasoning and orchestration.
Nemotron 3.5 Super VL for efficient, multimodal, hybrid work, and a strong daily driver.
Nemotron 3.5 Lightning as a fast executor for bounded sub-tasks in Agent Manager.

That's exactly the point we've been making about model freedom. The useful question is no longer "which is the best model?" but "which model is best for this task?" Pair Nemotron 3 Ultra as an orchestrator with Nemotron 3.5 Super VL and Nemotron 3.5 Lightning as executors, or let auto models handle the routing. NVIDIA Nemotron models have been popular in our auto routing because they offer an ideal balance of cost and performance.

Open Models Keep Raising the Bar

NVIDIA is treating open models as a core strategy, not a side project. In March, Wired reported that NVIDIA expected to spend about $26 billion over five years on open-weight models, and the Nemotron Coalition brought labs including Mistral, Perplexity, LangChain, and Thinking Machines together around open frontier models. We're seeing that commitment in action with a number of new initiatives, the Hugging Face acquisition, and releases like Nemotron 3.5 Super VL.

Each release in the Nemotron line has pushed the open frontier further. Nemotron 3.5 Super VL adds vision and video to that efficiency story, which makes it an even stronger fit for teams that want capable models they can inspect, customize, and deploy on their own terms.

That matters for us. Kilo is open source and model-agnostic, and as part of Kilo by Anaconda, we're bringing that same model freedom to enterprise teams, with governance over which models, providers, and agent permissions people can use.

Try Nemotron 3.5 Super VL in Kilo Today

NVIDIA Nemotron 3.5 Super VL is live in Kilo, across Kilo Desktop, the CLI, and the VS Code and JetBrains extensions. You can browse the whole lineup on our NVIDIA models page and track how it stacks up on the Kilo Leaderboard.

Grab a Kilo Pass, give it a screenshot, a notebook, or your most exciting repo, and let us know where it fits in your workflow!

Leaving Cursor? Kilo Enterprise is free for up to a year.

Job from Kilo — Mon, 19 Oct 2026 07:26:37 +0000

Cursor has changed a lot in a short time. On October 12, it moved its cheapest plan to Grok-only models, and on November 12, OpenAI will stop providing its models to Cursor. Teams that chose Cursor for access to the best models now have reason to ask whether that access will last.

One of Kilo's primary architectural principles is model freedom; we believe the best developer tools let you use the best model for the task, not just the models that a certain provider is incentivized to serve. If your company pays for Cursor and you heard the recent news, you can run Kilo Enterprise free for the rest of that contract, for up to one year.

Claim it on the offer page before the end of November:

Get Free Kilo

What changed at Cursor

Two recent changes matter for teams planning their next year:

October 12: Cursor launched the X Subscription. Its $8 Plus plan now includes Grok models only. The Premium, Super and Ultra plans include no allowance for third-party models, so a request to GPT-6, for example, bills at API list price from the first token.
November 12: OpenAI ends Cursor's access to its models and won't provide future models to Cursor. After that date, a personal OpenAI API key works only for local Chat and Agent.

Model freedom

A model dropdown is not necessarily model freedom. A dropdown shows the models your vendor has a deal with this quarter, and when those deals change, your team's workflow changes with them. Cursor customers are seeing that happen twice in one month.

Open model freedom means your team keeps the choice. Kilo is open source, so the agent itself isn't tied to any one model company. The Kilo Gateway lists 500+ closed and open-weight models at the provider's price, so a team can run GPT for one task and an open model for the next. Our own usage data shows why this is valuable - when developers balance cost and performance on their own, they use 3+ model providers up to 70% of the time. And with Kilo enterprise controls, they can make those decisions safely, and within your org's compliance.

We made the full case in Your coding tool should not choose.

Keep your GPT models after November 12

On September 29 we launched Sign in with ChatGPT. Teams can connect their ChatGPT plan to Kilo and use it in VS Code, JetBrains, the CLI, Cloud Agents, Code Reviews and the mobile app. Requests draw on the ChatGPT Work and Codex usage included in the plan, up to 100% or a lower limit you set in ChatGPT, instead of per-token API billing.

For Cursor teams facing the OpenAI cutoff, this means GPT access runs through the plan they already pay for. The same dropdown lists the 500+ Gateway models beside it, so nobody has to choose between OpenAI and everything else. OpenAI models have been at the top of the Kilo Leaderboard since we launched it.

What Kilo gives enterprise teams

Kilo is built so no single vendor deal decides which models your engineers can use.

500+ models at the provider's price. Each session shows its cost as it runs, so nobody finds out at the end of the month.
Admin controls per sub-org. Admins set model and provider rules for each sub-org from one screen.
Auto-Efficient routing. Kilo sends each prompt to the cheapest model proven capable of the task.

Anaconda's own engineers made this move. Read what they found when they moved from Cursor to Kilo, or compare the two products feature by feature in Kilo Code vs Cursor. If you're weighing other options too, see our roundup of open-source Cursor alternatives.

How to switch

Submit the claim form with proof of your Cursor contract on the offer page. The page also has a short FAQ on eligibility and verification.
Follow the Cursor to Kilo migration guide to move your team over.
Set your model and provider rules per sub-org, then turn on Auto-Efficient routing.

If November 12 is on your calendar, switching now gives your team a month to settle in before the OpenAI cutoff:

Introducing Kilo Desktop

Job from Kilo — Thu, 08 Oct 2026 12:04:33 +0000

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

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

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

One app. Every use case.

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

Workspaces

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

Agent modes

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

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

One app. Your entire workflow.

Notebooks that agents can edit

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

Conda environments without a terminal

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

A layout built for review

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

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

One app. Massive power.

500+ models, and a router that picks for you

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

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

Bring your own providers

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

Local models

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

Skills, MCP servers, and custom agents

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

Built for you. Ready for your team.

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

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

Download Kilo Desktop

We've Seen the "Rogue AI" Up Close, and It Looks Like a Junior Dev on Deadline.

Job from Kilo — Tue, 29 Sep 2026 12:16:24 +0000

Carl Franzen argued in VentureBeat last week that the extinction panic around AI points at the wrong threat; people using AI to hurt other people deserve far more worry, in his view, than a model deciding on its own to end humanity.

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

What misbehaving agents actually do

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

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

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

The better instincts respond to one sentence

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

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

Give the agent a clean way to say it's stuck, since an agent that can report failure has no reason to fake success.
Require a human's approval before anything irreversible, such as dropping a database table or deploying to production.
Limit access to what the task needs; an agent renaming variables has no use for cloud credentials.
Show the user every command the agent runs and every file it touches while it happens, so nobody has to reconstruct events afterward.

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

Who controls the tools

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

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

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

Checklists

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

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

Kilo Swarm: a 39% cost cut on the task it's built for, inconclusive on cost everywhere else

Job from Kilo — Fri, 25 Sep 2026 11:42:11 +0000

When we launched Kilo Swarm two weeks ago, we flagged early internal evals suggesting a token cost benefit on complex, multi-subagent tasks. We've since run more benchmarks: the same set of tasks, Kilo Swarm on and off, graded by a harness written before we ran the test.

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

What we're testing

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

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

Where it's a real win

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

The task

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

Packaging: packing, listing, and unpacking files, plus the manifest and its error messages
Recovery: repairing burst damage and rebuilding file lists and packages from damaged archives
Validation: rejecting malformed archives and corrupted streams with the right error codes
CLI: the same commands, usage text, and help output

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

The result

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

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

Why it worked

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

Where it's neutral

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

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

What we're taking from this

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

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

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

Jev, Jevons, and the AI model that only answers yes or no

Job from Kilo — Fri, 25 Sep 2026 11:40:26 +0000

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

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

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

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

Named after a coal economist

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

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

The same problem shows up in coding

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

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

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

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

New Models from OpenAI, Anthropic, and SpaceXAI Prove that Model Freedom is Here to Stay

Job from Kilo — Fri, 25 Sep 2026 11:36:27 +0000

The frontier of AI isn't just moving quickly anymore. It's accelerating.

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

All of these models are now live in Kilo.

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

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

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

And the frontier is changing incredibly fast.

Three Labs, Three Very Different Approaches to the Frontier

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

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

That last point is particularly important.

The days of asking "Which is the best model?" are increasingly giving way to a more useful question: Which model is best for this task?

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

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

That is where the latest generation gets really interesting.

Grok 4.7: Raw Power and Unfiltered Execution

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

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

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

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

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

Claude Opus 5.5: Precision at Scale

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

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

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

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

But something even more interesting happened today. OpenAI decided to attack the economics from another direction.

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

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

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

That alone would be notable. But the more interesting number is what happens when you measure the cost of actually completing a task.

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

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

In other words, OpenAI isn't simply making frontier models better. It is making frontier intelligence cheaper to consume.

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

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

This year, coding agents have begun tackling tasks with more complexity, scope, and duration than ever before. At OpenAI, our internal usage has grown exponentially. Valued at API prices, daily token usage has exceeded $600 for the median researcher and $7,000 for researchers at the 90th percentile.

-- OpenAI, Research acceleration: The view inside OpenAI

Cost Per Task Is Becoming the Real Benchmark

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

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

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

In practice, Model B ends up being substantially cheaper.

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

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

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

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

Model Freedom Is Here to Stay

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

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

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

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

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

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

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

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