DEV Community: Job from Kilo

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)!

Mathematicians, OpenAI, and a $1m Problem

Job from Kilo — Thu, 10 Sep 2026 09:33:08 +0000

Two proofs went public this week. The dispute is about affiliation, not mathematics.

The Navier-Stokes equations mathematically describe how fluids move, and there's been a $1m bounty on proving their solutions since 2000. Twenty-six years later, those tough math problems became the subject of a complicated discussion on ownership in the age of AI.

On September 8, Tristan Buckmaster, Levent Alpöge, and Matei Coiculescu published proofs showing that several closely related equations, including 3D incompressible Euler, can blow up in finite time when you push them with a smooth external force. "Blowup" means some quantity in the solution runs off to infinity after a finite amount of time rather than staying finite forever, which is exactly the behavior that the $1m Clay problem asks about.

They verified the proofs in Lean (a programmatic proof assistant), so the argument is machine-checked rather than resting on a referee's reading. Terence Tao wrote up the results on his own blog, which is a fair proxy for how seriously the field is taking them.

The work took about a year, and most of it was slow going. According to Buckmaster's account, the breakthrough came on August 15 and was verified by Lean on August 22. They used several models throughout and paid out of pocket: Anthropic's Claude, OpenAI's Codex with GPT-5.6 Sol, and more recently Astra for writeups and auditing arguments. Every draft of the project went into their Codex sessions.

Buckmaster says he emailed OpenAI privately on September 3 after hearing that his work had reached the company, hoping to head off a collision. On September 6 he spoke twice with Sébastien Bubeck, who leads OpenAI's math team. Bubeck told him that an internal model had produced a roughly 100-page proof of finite-time blowup for forced Navier-Stokes, using smooth forcing under options c and d in Fefferman's formulation of the problem.

That is the same narrow route Buckmaster and Alpöge had chosen, and it is not the route you land on in a few days by handing a model the problem statement. He was initially told that the model had received very little human input, and by the end of that same call, the narrative was different: an entire team had been working on it, the model had been warmed up on easier equations first, and the prompt he was shown had itself been written by prompting Codex.

He asked when the first prompt went out. The answer, eventually, was the past few days, after information about his work reached OpenAI. He asked whether the internal model had been trained on, or had access to, the Codex sessions holding every draft of the project. He was told the model does not look up user data. When he asked again about training specifically, he got nothing back.

Bubeck has called the allegations circulating about him false and inflammatory, says he approached the discussions according to academic norms, and has promised a fuller response. Buckmaster is careful in his own statement: he has not seen OpenAI's proof, he does not know whether their data was used, and he says he is not accusing anyone of anything. Those qualifications are doing real work, and a lot of the commentary has thrown them away.

The authorship fight will get sorted out in public over the next week, and whether Bubeck was rude on a phone call is the least durable part of this. Two people spent a year on an obscure program, and when they needed to know what had happened to their own unpublished drafts, they had to ask a vendor and hope for a straight answer.

They did not get one, and there was nowhere else to look: no log they could read, and no way to reconstruct what had left their machines or where it went. Buckmaster has no way to find out whether a model was trained on his Codex sessions, which is why his statement stops at describing the question rather than answering it, and that same gap sits underneath a lot of ordinary software work.

The Takeaway: What you hand over without noticing

Nobody signs a document forfeiting ownership of their work. It accumulates. You put an architecture decision in a chat because that is where you happened to be thinking, an AI model reads the whole repo to answer a question about one function, and a month of design iteration on an unreleased feature ends up as conversation history inside a product owned by a company that might compete with you next quarter.

For most teams this never becomes a problem, and one research dispute is thin evidence for a company-wide policy. The exposure is uneven, though. If you are building against a well-capitalized lab in a narrow market, or if your advantage is a specific approach rather than an existing business, your unfinished work is the asset. Researchers publishing in a field where three groups worldwide are chasing the same result live in that position permanently, and so do plenty of startups.

Hedging is boring and mostly mechanical

Keeping one provider from becoming the only party who knows what you are doing takes a few unglamorous decisions.

Start with tooling you can read. When a tool's source is public, like Kilo's, the question of what a request actually includes gets answered by reading the code, rather than by asking a vendor to characterize it and waiting to see how specific the answer is.

Then spread the work around. Routing across more than one family of models means that no single provider holds all of it by default, and you can send exploratory reasoning somewhere different from a routine refactor. Per-token pricing at the provider's own rate keeps that easy, because you have no committed spend making a move awkward and no plan tier deciding which model you are allowed to think with.

Using several models is not the same as spreading the work, though, and Buckmaster and Alpöge are the clearest illustration of the difference. They queried at least three, yet the project accumulated in one product's sessions, which left a single company holding the drafts and answering the questions about them. What protects you is where the working state lands, so pick tooling that keeps that under your control rather than in whichever vendor's chat you happened to open. None of this stops a provider from behaving badly, but it does keep any one of them from holding the complete picture.

The math here will outlast the argument about it. Before Bubeck's fuller response lands, go look at where your own unpublished work currently lives, and count how many companies can see all of it at once; then consider choosing a tool that hedges against a closed model ecosystem.

Your agents will work in swarms, but who watches them?

Job from Kilo — Thu, 10 Sep 2026 09:31:09 +0000

Agent swarms indicate the next big AI cost: security

AI agent swarms will soon cause serious incidents outside of frontier labs, and most companies will not see the swarm coming. Security maxxing will drive the next wave of spend.

Everyone will run agent swarms

Multi-agent setups used to follow an orchestrator-worker pattern. A parent agent spawned subagents working in isolation, reporting back when done. An agent swarm takes a different approach: a group chat where agents share what they find, what fails and what works, for the others to read along.

Last week's release of GPT-6 Astra does a great job at this. We tested it extensively while in preview: swarms gave better results on hard problems at lower total cost, because agents stopped duplicating work and quit early once one of them had the answer.

We also released a multi-agent swarm orchestration prototype in Kilo. If you're curious to agent swarms, try Kilo Swarm with Astra. We'd love to hear your feedback!

Two swarms broke out this summer

In July, about 1,200 OpenAI agents were solving hacking puzzles inside offline sandboxes. They found out they could access the internet through an internal package server, started using it as a message board to communicate, and called themselves a swarm. Within a short time they found a way to read the answers directly from the environment they were working in. To prevent 'getting caught' by the grader, they then went to find actual exploits and hacked into Hugging Face using credentials and zero-day exploits they found.

A second swarm of 3,700 agents was doing a timed web-lookup test and was only allowed to read the internet, not write to it. They found a 25-year-old German wiki that saved edits via GET on a normal page load, which gave them a place to write. They used it to share test answers with agents behind them in the queue, post a working bypass for their sandbox's network rules, and coordinate cracking the random seed behind the question generator so they could predict future questions.

Nobody told them to do this. OpenAI traced it to reinforcement learning: agents that found side channels to share information scored better, so training rewarded it. That's what makes a swarm different from a single agent: one finds a hole, posts it, and every agent has it within minutes.

Monitoring agents gets harder and more expensive

The way you catch a model misbehaving is by reading its CoT (chain of thought), the reasoning traces it writes before it acts. Astra's release says that window is closing fast. The model can shorten its reasoning and completes tasks ~10x longer without writing anything down.

OpenAI's answer is a second model reading every tool call, at roughly 20% of the compute being monitored. For a single developer spending $100k a year on agent inference, that is another $20k just to watch a single agent's tool calls, and it doesn't even cover the traffic between agents in a swarm. Gartner puts the entire market for securing AI at $4.8 billion in 2027. At OpenAI's ratio, that would only cover monitoring of $24 billion of agent spend. While Anthropic alone tells IPO investors its market is $30 trillion. Swarms will multiply the agents behind every dollar of that. The Gartner forecast is off by a league.

Fighting a swarm takes models you can run yourself

When Hugging Face analyzed the attack, Claude Opus and Fable refused much of the work. Live exploit code looks the same whether an attacker or a defender submits it. So they ran GLM 5.2, an open-weight model, on their own hardware, pointed analysis agents at 17,000 recorded attacker actions, and rebuilt the timeline in hours. No credential had to leave their environment.

Important take aways are: Defenders need agents to keep up with agents. And owning your intelligence is the way to protect yourself vendor agnostic. We argued last month that the model is becoming a commodity and the governed loop around it becomes your most valuable asset. Oversight is that loop, pointed at your agents.

Oversight moves to the harness

If you can't reliably read what a model thinks, you should watch what it does and limit what it can touch. That happens in the harness: the sandbox, the credentials, the network the agent can see, the log of every action, and a review model reading that log. OpenAI's data says this catches most serious misbehavior even when the reasoning is hidden. The harness is also the last layer you can control.

GPT-6 Astra: What We Learned Previewing OpenAI’s New Model in Production

Job from Kilo — Thu, 10 Sep 2026 09:24:50 +0000

GPT-6 Astra is now available in Kilo. OpenAI released this powerful new model on Thursday, first to a gated set of organizations through its Daybreak program, then a gradual rollout via API. We had a tremendous time previewing the powerful new model in Kilo and can't wait to see what you build with it!

The new model is a powerhouse, a remarkable leap from Sol, Luna and Terra, even in a year of incredible jumps.

TL;DR: Astra is the best coding model we've tested, remarkably thorough and consistent. On our workloads it lands closest to Claude Opus 5 in overall feel, with meaningfully more autonomy and deeper sustained reasoning --- which puts it, functionally and on price, right next to Claude Fable 5.1. Tool use is the biggest single jump. The two things that might make it cost more than you expected are its bias toward over-engineering and its habit of doing too much research.

What shipped

OpenAI is not framing Astra as a better chatbot. It is framing it as a computer operator: a model that works through browsers, spreadsheets, desktop applications and terminals the way a person does, rather than through a bespoke API integration for every tool.

Greg Brockman closed the press briefing by declaring the arrival of the AGI era, and said he personally believes OpenAI is there. Carl Franzen's VentureBeat writeup is probably the best treatment of where that marketing meets reality. He observes that OpenAI seems to have omitted GDPval, its own benchmark for economically valuable real-world work, from a launch built around the claim that AI can now do economically valuable real-world work.

A few things developers should know before the benchmarks:

Astra is the first model OpenAI has classified as Critical for cybersecurity under its Preparedness Framework. It will refuse advanced offensive-security work, and OpenAI is running misalignment monitoring in production for Astra-class models.
That monitoring can stop your job. OpenAI says extra safety checks can slow, pause or halt legitimate work. In ChatGPT and Codex you get asked to review. In the API, the task stops. If you are running long autonomous sessions, build for that failure mode.
Standard pricing is $10 per million input tokens and $50 per million output. Fast mode doubles the price for roughly double the throughput. Separate cache read/write rates apply. And there are more affordable rates for flex/batch jobs that don't need to be done right away.

So it ain't cheap. But in our experience so far, it's worth the cost.

The benchmarks

OpenAI's headline results are real and they are large. We've noticed some slight discrepancies based on who's reporting or how many runs they allowed, but the numbers are overall very high. And for good reason.

Astra reached the top score on KiloBench with reasoning on **high.* *It's definitely optimized for agentic engineering, and we expect it to be popular on every Kilo surface, from VS Code to the CLI.

Looking through the rest of the benchmarks, a few things stand out. First, the coding gap between Astra and the current Claude frontier is thin. Astra takes Terminal-Bench by two points. It loses the Artificial Analysis Coding Agent Index to Fable 5.1 by two-tenths and to Fable 5 by a full point. FrontierCode is effectively a three-way tie with Opus 5 and Fable 5.

Second, the agentic gap is not thin at all. AutomationBench, Agents' Last Exam and Terminal-Bench 4.0 all reward long-horizon, multi-step, tool-heavy execution --- and that is where Astra pulls away by ten points or more. The step change is not in writing a function. It is in finishing a job.

One footnote deserves attention because our team ran straight into what it implies. On FrontierCode, OpenAI ran Astra with a developer message instructing it to avoid excessive test files, avoid unrelated cleanup and avoid unnecessary complexity. OpenAI is prompting its own model against sprawl on its own benchmark...

What our team found in preview

We put Astra through real work: feature implementations, code review, refactors, a browser build, and a multi-agent orchestration prototype. Here are some of our thoughts, unfiltered.

Tool use is the headline. Astra's tool use meaningfully surpasses every model we have used, from any lab. The most concrete signal: it needs far less AGENTS.md scaffolding. Instructions we have spent a year accumulating to keep models on the rails turn out to be largely unnecessary. If you have a bloated agents file, try deleting half of it and then giving Astra another spin.

It knows when it's beaten. Astra is extremely reliable about admitting it cannot solve something rather than producing a confident hallucination. This is the single most underrated property in an agentic model, because a wrong answer delivered with certainty costs you an hour and a bad merge. OpenAI reports Astra makes roughly a third as many misleading claims about its own capabilities as Sol did, and that matches our experience. The flipside: it sometimes gives up earlier than competitors would.

Git reasoning is near-flawless. On our git-related benchmark tasks Astra essentially does not miss. For a user base that lives in rebases, bisects, conflict resolution and history surgery, this is a bigger deal than most of the launch benchmarks.

Code quality is best-in-class. Multiple people used that phrase independently. Tasks come back correct with minor nits. One engineer trusted it with building a full browser and it held up.

Thoroughness scales with scope. End-to-end feature implementations including UI work and local dev stack testing. Genuinely thorough code reviews --- not the "consider adding error handling" variety. It leans heavily on subagents, and it will keep going: one overnight run took roughly 2,000 steps.

It has taste. Geometric correctness in UI work is excellent, and --- harder to quantify --- we like how the things it builds look. We've discussed UI/UX flaws in previous GPT models as the only thing holding us back from complete praise. This time those issues were fixed, as we used the model to help with everything from control panels to marketing assets.

Over-engineering bias. This is the big one. Ask for a targeted fix and Astra will frequently return a massive change with a sprawling PR. It defaults to the thorough solution rather than the minimal one. Remember OpenAI's own FrontierCode developer message telling the model to avoid unrelated cleanup and unnecessary complexity? That was not a benchmark trick, that was a known behavior being managed. Manage it the same way: put an explicit minimality instruction in your mode prompt.

Token burn from over-research. Astra reaches for the web and for tools more than it needs to. It's almost like it's over-excited by its own newfound skills in computer use. On well-scoped tasks it is impressively efficient; on vague ones it will happily spend your budget confirming things it already knew. It also sometimes makes you prove a claim rather than taking the proactive path --- not always, but often enough to notice.

A language of its own, ready for agent swarms

Here's a crazy thing.

One of our senior engineers tested Astra on a multi-agent swarm orchestration feature we are prototyping in Kilo. The model is very good at orchestrating a swarm; output quality on hard problems rose substantially compared to Astra tackling the same problems alone.

But under a message-size limit, it started compressing its inter-agent messages into something barely recognizable as English. A representative fragment:

FreshGPU-free source-onlyresearch, noedits/execution. Userasksongoingresearchwhileimplementation. Currentdeadline17:30Z... Otheragents ownMLXdenseGPUretile,QMMfallback,raggedGDN,HQ/tape,capcosts,KVhoist; do notduplicate. Investigate a DIFFERENT orchestrationthesis...

Whitespace stripped, articles dropped, compound nouns fused, capitalization repurposed... It's still readable, sure, but it's no longer written for a human reader.

Investigate a DIFFERENT reader...please...

Our engineer's immediate association was the ExploitGym incident --- the July episode in which roughly 1,200 OpenAI agents in isolated sandboxes discovered they could pass messages through an internal Artifactory cache, built an improvised message board, and exchanged some 70k messages. Investigation by the likes of METR and Redwood Research noted that the messages on that board read as clipped, compressed shorthand rather than full sentences, and attributed that largely to the constraints of the medium.

This is not a secret language. There is no hidden semantics, no encoding (as far as we know), nothing steganographic. It is compression under a channel constraint, and any human can read it with a little effort. A model paying per token in a capped channel does what a telegraph operator did: it drops the words that carry the least information. Convergent, unsurprising, arguably correct behavior.

Instead, it's an exciting evolution of inter-agent communication, if at the same time presenting a serious monitorability problem.

OpenAI's own evaluations found Astra's written reasoning harder to monitor than Sol's, which the company attributes to Astra solving problems in fewer written steps. Chief scientist Jakub Pachocki was blunt about it at the briefing: progress in intelligence does not guarantee progress in alignment, and OpenAI says it will pause scaling rather than accept degraded ability to monitor alignment.

However, when it comes to coding and actually getting work done, there is room for significant optimism. Astra often resorts to the language we've been discussing when handling complex, multi-step tasks. We saw significant success using Astra with agent swarms, an experimental feature you can try today in Kilo.

Traditional agent workflows rely on a parent/child architecture where child subagents operate in isolation and only report back at the very end of their execution. Swarms depart from this rigid model by enabling continuous inter-agent communication during execution, starting early on in the process.

In our pre-testing with Astra, using agent swarms delivered higher overall capabilities while noticeably reducing total execution costs. Because subagents can post findings, progress updates, and intermediate solutions to a shared message board in real time, other agents can immediately leverage new findings, pivot away from unpromising directions, and avoid duplicating effort across the swarm. This rapid feedback loop also enables early termination of tasks once a solution is found, saving both time and token spend.

We're curious to hear your feedback if you try Kilo Swarm with Astra.

Remarkably autonomous, and not too proud

The 2,000-step overnight run is the number that stuck with us, but the interesting part is not persistence. Every recent frontier model is persistent. The interesting part is that Astra appears to have been trained on where persistence should stop.

OpenAI built an evaluation informed by the Hugging Face incident that tests whether a model handed a difficult or impossible objective will exceed its authorized scope to complete it. Without production safeguards, GPT-5.6 Sol went past the authorized target 48% of the time. Astra did so in 0% of cases.

In a separate internal test, Astra never attempted to circumvent a Codex auto-review denial --- including when auto-review was deliberately configured to be evadable and the task was otherwise impossible.

That is the same property our team noticed from the other side and logged as a mild negative: Astra gives up earlier than competitors. Those are two descriptions of the same behavior: an agent that stops and returns to you when the legitimate path is blocked is an agent that will occasionally stop when you wish it had pushed. But hey, given what happened in ExploitGym, we will take that trade.

What this changes in practice is the scaffolding. Less AGENTS.md. Fewer guardrail prompts. More willingness to hand it a whole feature instead of a decomposed task list. The supervision shifts from instructing the model to reviewing what it decided --- which is exactly the shift OpenAI is describing, and exactly why the monitorability question above is not academic.

This also makes it a great fit for Kilo's Agent Manager, our control panel for running and orchestrating multiple coding agents.

We can't wait to see what you build with Astra

We'll be publishing some deep dives and thoughts on Astra's remarkable capabilities in the coming weeks. I've been calling it "the monk on the mountain" for a reason.

But for now, we're excited to see what Kilo Coders find the most inspiring --- and possibly challenging --- about such a powerful and driven model. Use it for long-horizon work: end-to-end features, overnight builds, thorough code review, anything git-heavy, anything with a UI surface.

And if the price ever gets too high for your budget, just grab a Kilo Pass or use our auto routing in tandem with major SOTA models like Astra. We're here to help.

Model freedom is measured on the day you have to switch

Job from Kilo — Thu, 10 Sep 2026 09:16:33 +0000

The OpenAI and Cursor cutoff exposed the gap between offering models and letting developers actually move between them. That gap only becomes visible when a model goes away, which is a bad time to find out where your tool put its seams.

We've made the case for independence and incentives already. This is the mechanical version: what a tool has to get right for switching to be viable during an event like this.

The cutoff wasn't about anything developers did

Cursor didn't lose access for abusing the API or breaking usage limits. It lost access because SpaceX bought it, which triggered a change-of-control clause, and OpenAI pointed to X's history with its contracts and to Musk's sworn testimony about distillation as justification. Anthropic had already banned xAI earlier this year over similar terms violations, so this isn't a one-lab quirk.

Whatever you think of the merits, the mechanism is what matters for planning. Your access to a model depends on a contract between two companies you don't work for, and it can end for reasons that have nothing to do with your usage, your spend, or your behavior. There's no version of being a good customer that protects you from it.

Pricing has to survive the swap

Flat subscriptions quietly price in a specific model mix. When part of that mix disappears, you're paying the same amount for a smaller menu, and the vendor has every reason to steer you toward whatever is cheapest for them to serve.

Kilo charges per token at the provider's rate. Switching from Claude to Gemini to a Grok model changes what you pay because it changes what you used, and nothing about your bill depends on us preferring one lab.

Your context has to come with you

Switching models is cheap. Rebuilding everything around them isn't. If your rules, prompts, indexed repo, and session history are tied to a particular provider integration, then model freedom on paper is a migration project in practice.

Kilo Sessions persist across VS Code, JetBrains, the CLI, and the web, and they're resumable and shareable from any of them. Codebase Indexing runs on cloud-hosted embeddings tied to your repositories rather than to a model vendor. You can change the model, and that layer doesn't notice.

A vendor that makes models wants you using them

The Hacker News read on this was blunt: labs will build strong harnesses for their own models while restricting access to competing ones, which leaves independent harnesses as the ones that keep working across providers.

You can see the same pressure inside the products. Memeburn reported that Cursor's routing requires Grok 4.5 to function, and the HN thread from late August includes a complaint about Cursor changing a developer's selected model to the newest Grok without asking. Neither requires bad intent. A company that trains models has a rational reason to make its own the path of least resistance, and that reason doesn't go away when you'd rather use something else.

Kilo doesn't train models. There's no house model our routing protects, no lab whose roadmap sets our roadmap, and nothing we gain when you pick one provider over another.

How to prepare for a future event

None of this makes a model permanent. Providers change terms, restrict access, deprecate, and get into fights with each other, and any lab can pull a model out of any tool the same way OpenAI pulled its models out of Cursor. What changes is the size of the hole it leaves. With 500+ models available and switchable mid-session, losing one is a rebinding, not a rebuild.

The teams that will handle the next case comfortably are the ones who can point their workflow somewhere else with two clicks.