Who Owns the Prompt?

I have reached the point where I no longer remember exactly why every AI coding tool is installed on my computer.

There is Codex, Claude, Cursor, Kiro, TRAE, Devin, GitHub Copilot and now Kilo Code. There are terminal agents, desktop apps, browser tools and extensions sitting inside other extensions. One is better at planning. Another moves quickly through a large repository. One gives me a few more free requests. Another can see local files. Sometimes one model gets stuck on a problem that another solves immediately, even though both have been given almost the same instructions.

My workflow has become a small informal marketplace. I move the same task between tools and watch how each one interprets it. I copy a failed attempt from one agent into another. I use up a quota and continue somewhere else. The process is occasionally absurd, but it also gives me a kind of power I did not have before.

The tools are competing for me.

For most of my working life, access to software has felt more fixed. You selected Adobe, Microsoft, Apple, Autodesk or another platform, then gradually rearranged your habits and files around its assumptions. Leaving later was possible, but it usually hurt. The software accumulated your work, your shortcuts and your memory.

AI coding feels unusually fluid by comparison. The code remains on my computer. The models can often be swapped. A prompt can be carried from one system to another in seconds. When one company raises its price, reduces its limits or produces a bad result, another tab is already open.

This is why Anaconda's acquisition of Kilo Code caught my attention.

On the surface, it looks like a familiar technology acquisition. An established Python company buys a fast-growing AI coding agent. Kilo continues operating. Its current repository remains open source and MIT-licensed. Developers still get access to many different models, providers and interfaces.

The announcement, however, describes a larger ambition. Anaconda wants one layer through which an organization can see AI development activity, control which models and providers are available, enforce policies and manage spending. Kilo brings the agent interface inside VS Code, JetBrains and the terminal. Anaconda already operates around packages, environments and models. Its earlier acquisition of Outerbounds added production orchestration and deployment workflows.

Placed together, these pieces begin to resemble a corridor through which AI-generated software can travel.

A person describes what they want. An agent reads the repository and modifies the code. A model is selected. Packages and environments are assembled. Security rules are applied. Costs are recorded. The resulting system is tested, deployed and monitored.

The coding agent is the front door.

The most durable position in AI may belong to whoever controls the traffic between the human request and the working product.

Freedom on one side, control on the other

Kilo's appeal is easy to understand from the developer's side. It promises access to many models without requiring a permanent commitment to one provider. It can use hosted models, personal API keys and local options. Its open-source code offers inspection, modification and the possibility of a fork.

The acquisition announcement frames the same landscape from the organization's side. Employees are already using personal accounts, private API keys and several agents. Company code and context can move through services that security teams cannot see. Spending is split across tools. Rules written in a policy document may have little connection to what developers are actually doing.

For the individual, moving between tools feels like freedom and experimentation. For the organization, the same behaviour appears as fragmentation, cost and risk.

For the platform in the middle, it is an opportunity.

Anaconda's answer is a shared control layer. Developers keep their preferred interfaces and model choices, while the company gains visibility, policy enforcement and centralized routing. This can be genuinely useful. A regulated organization should know where sensitive code is going. A security team should be able to prohibit a model that cannot meet its requirements. A finance team should not need to discover AI spending through dozens of unrelated credit-card charges.

The tension is that a layer created to preserve choice can become more powerful than the choices it connects.

The gateway sees which models developers choose for planning and which they use for debugging. It can observe where agents fail, how often they retry, what work consumes the most tokens and which providers are gaining practical trust. In a company, it can decide which models appear in the menu, what data may leave the organization and how much each team is allowed to spend.

The developer experiences variety. The organization experiences control. The platform experiences both.

The gateway does not need to own the models

Previous software platforms often became powerful by owning the application or the operating system. An AI infrastructure company may not need to own the model at all. It can become essential by organizing access to many models.

This is one reason the phrase model-agnostic deserves careful attention. It describes a real benefit. A model-neutral product can reduce dependence on OpenAI, Anthropic, Google or any other single provider. It can route different tasks to different systems and preserve some bargaining power when prices or capabilities change.

But neutrality can also become a business position. The more providers a gateway connects, the more valuable the gateway becomes. The more organizations build permissions, analytics, budgets and compliance processes around it, the harder it becomes to bypass.

The corridor does not need to own the rooms at either end. It gains power from becoming the easiest route between them.

Anaconda says Kilo orchestrates almost ten trillion tokens per month across more than three million developers. Kilo has separately described the milestone as three million downloads, which is a looser measure than active or paying users. The scale is still meaningful. A tool handling that much model traffic sits close to the daily decisions through which developers learn what each model is good for.

There is another unusual detail. A public GitLab filing shows that GitLab entered a right-of-first-refusal agreement with Kilo in November 2025. The agreement applied to qualifying acquisition proposals before August 24, 2026 and gave GitLab a period in which to pursue substantially matching terms. Anaconda announced its acquisition while that agreement was active. The public documents do not explain the private process that followed, but they show that Kilo's position had already become strategically important to another major developer platform.

Open source is necessary, but it is not the whole building

Kilo's active repository is MIT-licensed. That matters. Released open-source software cannot simply be recalled after an acquisition. People can inspect it, preserve it and fork it when company priorities diverge from community needs.

Modern software, however, rarely lives entirely inside the visible repository.

The commercially valuable layers increasingly sit around the code: cloud agents, hosted routing, identity, analytics, compliance, team administration, procurement and enterprise support. The front door can remain open while more of the building behind it becomes available through the company operating it.

This is not automatically a betrayal of open source. These services cost money to run, and companies need operational guarantees that a community repository alone cannot provide. The important question is whether the open path remains healthy enough to be a meaningful exit rather than a ceremonial one.

Can a developer still connect models directly? Can a team export its settings, logs and policy definitions? Can the agent work without the hosted gateway? Can another community maintain the code if the official product moves elsewhere? Can a company leave without rebuilding its entire AI development process?

Open source protects the possibility of exit. Product design, data portability and infrastructure choices determine whether that exit remains practical.

We have seen this organizing layer before

The internet begins with many independent sites, then search engines organize them. Mobile computing begins with thousands of developers, then app stores become the passage through which most people reach them. Online commerce begins with individual shops, then marketplaces manage discovery, payment and trust.

The organizing layer usually starts as a convenience. It reduces friction and makes a chaotic system usable. Over time, the convenience becomes infrastructure. Once enough activity passes through it, leaving becomes harder even when alternatives still technically exist.

AI development is early enough that we can watch this layer being assembled in public.

Almost every company currently promises choice: any model, any provider, any editor, any cloud. These promises can be sincere. They are also what an intermediary must offer while persuading everyone to travel through the same route.

I do not know whether Anaconda will become that route. The integrated platform it describes is still partly an ambition. Its reported token savings are company claims without enough public methodology to treat as a general benchmark. The acquisition may make Kilo more stable, more useful and easier for enterprises to adopt. It may also shift the product's center of gravity toward governance and paid organizational controls.

Both can be true.

Portability is a form of negotiating power

I began looking at Kilo because I wanted another coding tool and, honestly, another source of usable tokens. I was thinking as an individual trying to stretch access across several products. Anaconda is looking at the same fragmented landscape from the opposite direction. It sees thousands of employees moving between providers and wants to make that movement visible, governable and billable.

The freedom I currently feel comes partly from the fact that none of these systems has become fully unavoidable. My files remain local. The agents overlap. The models compete. I can abandon one product and continue working in another.

This condition may require active maintenance.

Keeping local repositories, portable files, independent API access and open formats can sound like technical housekeeping. It is also how individuals and organizations preserve negotiating power. Open-source code matters because it gives communities somewhere to continue when company priorities change. Multiple providers matter because no single company should decide the price and conditions of thinking with machines.

There is no need to reject the larger platforms. A well-designed control layer could make AI development safer, more understandable and less wasteful. The question is whether convenience leaves us with a genuine ability to move.

When every model is available through one gateway, the list of choices may grow even as the number of meaningful exits shrinks.

Perhaps this is the question I should ask whenever I install the next agent. What part of my work is it quietly becoming responsible for? What does it learn from the traffic passing through it? Which decisions can it make on my behalf? What survives if the company changes direction?

And how easily can I leave when responsibility becomes power?

AI authorship note

This essay began with Kris Haamer's own use of several AI coding agents and his questions about the Anaconda acquisition of Kilo Code. AI supported research, synthesis, drafting, illustration code and implementation. Kris is responsible for the framing, argument, source selection and decision to publish it.