A few things happened almost at the same time.

GitHub moved Copilot deeper into usage-based billing.

OpenAI kept pushing the Responses API as the default primitive for building agents.

Anthropic launched Fable/Mythos and then had to suspend access a few days later because of a U.S. government directive.

NVIDIA is putting “personal AI supercomputer” hardware into the market with DGX Spark and DGX Station.

Individually, each of those stories is easy to treat as separate news.

I do not think they are separate.

I think they are all pointing in the same direction:

AI coding is moving from a cloud feature into local infrastructure.

And that changes the question for developers.

Not just:

Which agent should I use?

But:

Where does the agent run?
Which models can it use?
Who owns the runtime? And who the compute?
What happens when pricing, policy, model access, or hardware changes?

That is the part I think matters.

What happened

GitHub announced that Copilot plans transition to usage-based billing on June 1, 2026. The old premium request unit model is being replaced by GitHub AI Credits, with usage calculated from token consumption: input tokens, output tokens, and cached tokens, priced according to the model used. GitHub also says this is because Copilot has moved from a simple in-editor assistant toward an agentic platform that can run long multi-step coding sessions across repositories. (The GitHub Blog)

There is an important detail here: GitHub says code completions and Next Edit suggestions remain included and do not consume AI Credits. So this is not “every ghost text completion is billed now.” The bigger point is that agentic usage, chat, long-running sessions, code review, and heavier model work are now part of a visible token economy. (The GitHub Blog)

OpenAI is moving in the same direction from the other side. The Responses API was introduced as a new primitive for building agents, combining Chat Completions-style simplicity with tool use from the Assistants API. OpenAI also added built-in tools like web search, file search, computer use, and an Agents SDK with tracing and observability. (OpenAI)

Then OpenAI expanded Responses further with remote MCP server support, Code Interpreter, improved file search, background mode for long-running tasks, reasoning summaries, and encrypted reasoning items. (OpenAI)

That is not just “new API features.”

That is model vendors moving up the stack into runtime, tools, state, observability, and orchestration.

Then the Anthropic Fable/Mythos story happened.

Anthropic said the U.S. government issued an export-control directive requiring suspension of access to Fable 5 and Mythos 5 by foreign nationals, including foreign-national Anthropic employees. Anthropic said the practical result was that it had to disable access for all customers to ensure compliance. (Anthropic) The Verge reported the same basic story: an export-control directive citing national security concerns required blocking access for foreign nationals, and Anthropic cut access for all customers. (The Verge)

You can argue about the policy. You can argue about the safety question. You can argue about whether the government overreacted.

But as a developer, the practical lesson is boring:

remote model access is not a stable primitive.

It can change because of price.

It can change because of policy.

It can change because of region.

It can change because of provider risk posture.

It can change because of model availability.

That does not mean “never use frontier models.” That would be stupid. Frontier models are extremely useful.

It means the runtime layer matters.

What this means for us as developers

For the last two years, a lot of AI tooling was sold like a product feature.

Install extension.

Sign in.

Get magic.

That worked for the first wave.

But serious AI coding work is not just a UI feature anymore. It is a stack.

You have model selection.

You have context management.

You have file search.

You have tool execution.

You have shell access.

You have policy.

You have logs.

You have long-running tasks.

You have cost.

You have rate limits.

You have model-specific quirks.

You have the question of where your source code, prompts, tool results, and traces go.

That is runtime territory.

The uncomfortable part is that a lot of developers are now using agents that can inspect repos, edit files, run commands, open PRs, call tools, and sometimes run for minutes or hours — while the execution layer underneath is still treated like a black box.

That is fine for experiments.

It is not fine as the default future.

If AI coding becomes part of normal development, then developers and teams need more control over the runtime.

Not because cloud is bad.

Because dependency without control is fragile.

The local compute trend is not a meme anymore

The other signal is hardware.

NVIDIA DGX Spark is a desktop AI system with a Grace Blackwell GB10 Superchip, 128 GB of coherent unified memory, and up to 1 petaFLOP of FP4 AI performance. NVIDIA says it can run AI development and testing workloads with models up to 200 billion parameters at the desktop, and two DGX Spark systems can connect for models up to 405 billion parameters. (NVIDIA)

DGX Station goes even further. NVIDIA describes it as a deskside AI supercomputer with 748 GB of coherent memory and up to 20 petaFLOPS of AI compute, supporting models up to 1 trillion parameters. NVIDIA also announced DGX Station for Windows as a system that can serve as a dedicated AI supercomputer for one developer or a shared local compute node for teams. (NVIDIA) (NVIDIA Newsroom)

Now, obviously, not everyone is buying a DGX Station.

That is not the point.

The point is the direction of travel.

For a while, local AI meant “maybe you can run a small model on your laptop if you are patient.”

Now the market is clearly moving toward a more serious local/on-prem/private-compute tier:

• laptop for small models and simple workflows
• workstation for serious local development
• rented GPU box for heavier workloads
• team-local node for shared inference
• cloud frontier model when needed
• data center or cluster later

That is a very different world from “all useful intelligence lives behind one vendor API.”

And once local or rented compute becomes powerful enough, the missing piece is not only the model runner.

It is the runtime around it.

Routing.

Compatibility.

Policies.

Tools.

Logs.

Editor integration.

The boring stuff.

The stuff that makes it usable.

The ecosystem is already forming

This is where I think people should not be tribal.

If you want to start today, there are already good projects.

Kilo Code is an open-source AI coding agent across VS Code, JetBrains, CLI, and cloud. It supports many models, bring-your-own-key usage, multiple agent modes, autocomplete, and a full agentic coding experience. (Kilo)

OpenCode is another important piece. It is an open-source coding agent available as a terminal interface, desktop app, or IDE extension. It is model-agnostic and clearly sits in the “developer agent” category. (OpenCode)

Ollama is probably the easiest starting point for local models. It gives developers a simple way to run and manage open models locally, and it exposes a REST API for chat and generation on localhost:11434. (Ollama) (GitHub)

If you are more advanced, or responsible for a team, vLLM is the next layer to understand. It is a high-throughput and memory-efficient inference and serving engine. The docs highlight Hugging Face integration, streaming outputs, tool calling and reasoning parsers, distributed inference features, and OpenAI-compatible API serving. (vLLM)

That rough map matters:

• want to just run a local model: start with Ollama
• want an open-source coding agent: try Kilo Code or OpenCode
• want serious serving for a team: look at vLLM
• want editor-native workflows: look at the VS Code/JetBrains/CLI agent space
• want policy, runtime, compatibility, local tools, and owned compute to become one layer: that is the gap I care about

I do not see these projects as enemies.

Actually the opposite.

They form the market.

They teach users what is possible.

They normalize local models, open-source agents, model routing, self-hosting, and running AI outside a single cloud product.

That makes the next layer possible.

What this changed for Contenox

This is also why I changed the shape of Contenox.

For a while it was too easy to describe Contenox as “another agent runtime” or “a local agent framework.”

That framing is too small.

The direction is now clearer:

Contenox should be a local-first AI runtime for top-tier agent work without giving up control.

The agent is still important.

But the agent is the proof workload.

The deeper product is the runtime layer underneath it:

• run on compute you control
• use local, rented, or provider-backed models
• expose compatibility surfaces existing tools understand
• route across providers and models
• understand model capabilities
• execute tools safely
• keep policy and approvals visible
• log what happened
• support editor workflows
• avoid turning every local experiment into a fragile pile of glue scripts

That is also why the VS Code extension matters.

Not because VS Code is the whole product.

Because editor AI is where the runtime has to prove itself immediately.

Autocomplete has to be fast.

Chat has to stream.

Tool calls need approvals.

Filesystem and shell access need boundaries.

Model/provider selection must be understandable.

The user should not need to run a whole browser control panel or expose a random HTTP server just to use local/editor AI.

The editor is the pressure test.

If the runtime can support a good VS Code experience, it becomes much more than a CLI experiment.

The goal: local-first, but not limited

When I say local-first, I do not mean “local only.”

That would be another trap.

A local-first top-tier AI agent should be able to use:

• a small local model when that is enough
• a bigger local model on a workstation
• Ollama for simple local model management
• vLLM for team-grade serving
• OpenRouter or provider APIs when frontier capability is the right tradeoff
• future local/team GPU boxes when they make sense

The point is not purity.

The point is control.

You should be able to choose where the model runs.

You should be able to move workloads.

You should be able to see what tools the agent called.

You should be able to approve dangerous actions.

You should be able to keep logs.

You should be able to switch from one backend to another without rewriting your whole workflow.

That is the “without compromises” part for me.

Not “everything is free.”

Not “local models beat every frontier model.”

Not “cloud is bad.”

The compromise I do not want is this one:

To get a good AI coding experience, you must give up ownership of the runtime.

I think we can do better.

Conclusion

The recent news is not one story.

Copilot metering shows that agentic coding work has real variable cost.

OpenAI’s Responses API shows that model providers are turning tools, state, tracing, and orchestration into platform primitives.

The Anthropic Fable/Mythos disruption shows that access to frontier capability can change suddenly because of policy.

NVIDIA’s DGX Spark and DGX Station show that local and team-local AI compute is becoming a serious product category, not just a hobby setup.

And the open-source ecosystem around Kilo Code, OpenCode, Ollama, and vLLM shows that developers are already moving toward a world where AI coding is not one cloud feature, but a stack.

That is the world I want Contenox to fit into.

Not as another random agent.

As a local-first runtime for serious agent work on compute you control.

The agent is what proves the product.

The runtime is the product.

Contenox: Free and OpenSource forever.

Ctrl + P
> ext install contenox.contenox-runtime