Updated 30 June 2026
First ran 16 June. Updated 20 June for Omnigent 0.2 (the Cursor and Antigravity harnesses, ACP wrapping, and the
credential_proxysecretless egress), and again on 30 June: added Zenith, an orchestrator on top of harnesses, and JetBrains Air to the editor's-cut family, and folded in Omnigent 0.3 (seven more harnesses, fleet-wide model switching, and an announced per-turn model router). The original argument is unchanged; each release has sharpened it rather than bent it.
On 1 June 2026, stopped charging by the seat and started charging by the token. Every plan moved to usage-based billing: the old premium-request quotas were replaced by metered drawn down at each model's published rate, and the fallback that used to drop you to a cheaper model when you ran out was quietly removed . The subscription prices themselves did not move. The incentive did. Once you pay for , you start caring a great deal about which model burns them.
That bill pushed me into a habit I had been circling for months: stop committing to one coding agent and spread the work across several. At work I have access to a cluster running open-weights models (Gemma, , gpt-oss) that costs me nothing per token once the hardware is sitting there. Through I have been routing tasks to 5.1, Kimi 2.6 and V4, and I still keep a little 3.1 on hand through my Google account for the things it is good at. A cheap local model drafts the boring parts, a gets the thorny architectural call, and a different one reviews the diff so it is not marking its own homework.
The result is a workbench, not a single tool.
The problem is that none of these tools knows the others exist. Each coding agent understands only its own sessions. I copy context between them by hand, paste a stack trace from one into another, and lose the thread every time I switch. The obvious fix is an orchestration tool, and I tried a few. Every one of them had an opinion about how I should work: a graph I had to author, a crew of roles I had to define, a particular notion of what an "agent" was. I wanted a layer that was neutral about the workflow and just let me treat the I already use as interchangeable parts. When open-sourced Omnigent on 13 June, that is the description that made me look .
A coordination layer above autonomous units is one of the oldest patterns in the field, and it has failed more often than it has worked. What makes this generation worth attention is not that it coordinates, but what it coordinates (other people's harnesses, as swappable parts) and how neutrally it does it. The open question underneath is whether that layer ends up a product someone owns or a protocol nobody does.
In this article
- A layer that keeps getting reinvented: the thirty-five-year pattern of bolting a coordination layer onto brittle autonomous units, and why the first serious attempt at it failed.
- What a is: the term, and how it differs from a , an orchestration framework, and an interoperability protocol.
- How Omnigent works: the runner-and-server architecture, the composition / control / collaboration triad, the built-in orchestrators and the , and the sandbox that holds your tokens for you.
- Omnigent and Oz: the two 2026 meta-harnesses, and the architectural choice that separates them.
- The editor's cut is different: how 's Agent Panel, 's Agents window and JetBrains Air chase the same goal from a different layer of the stack.
- Product, or protocol?: why an infrastructure company gives a coordination layer away, and what that tells you.
- When it pays off: the case against bothering, and where I have landed.
A layer that keeps getting reinvented
The idea that several autonomous units need a layer above them to cooperate is older than the language model by three decades. Multi-agent systems were a research field in the 1990s, and one of its first products was a way for agents to talk to each other. KQML came out of a DARPA programme around 1990, treating messages as speech acts (ask, tell, reply) drawn straight from the philosophy of language. The Foundation for Intelligent Physical Agents, founded in 1996, built on it with , ratified in 2000: twenty-odd formally defined performatives with semantics grounded in an agent's beliefs and intentions .
It was elegant, and it went almost nowhere outside the academy. A recent survey of agent interoperability protocols is blunt about why: FIPA's management was complex, its message encodings were verbose, and the whole apparatus stayed confined to research and defence rather than lightweight industrial use . The same survey frames today's protocols, and among them, as direct evolutionary responses to those documented limitations. The field is taking a second run at a problem it first defined in 1996, and what changed is that natural language now absorbs the semantic ambiguity that the old ontologies tried, and failed, to pin down formally.
What came between is a familiar shape. A new primitive appears. Someone tries to make one of them act alone. It proves brittle. So a layer goes on top to handle coordination, and then a standardisation effort tries to make those layers interoperate.
The 2023 autonomous-agent gold rush is the cautionary middle of that story. AutoGPT and BabyAGI chained model calls together and let them set their own subtasks; they looped, burned tokens, and wandered off, and the lesson the field absorbed was that autonomy without structure is not enough. The frameworks that followed (, , ) won by adding rails. The protocols that followed, MCP for tools and A2A for agent-to-agent, won by standardising the wires. Every step solved a real problem and created the next layer up.
What a meta-harness is
The vocabulary here is a mess. A harness is the wrapper around a model that turns it into an agent: the loop, the tool definitions, the context management, the approval gates. , and are harnesses. A meta-harness, the term Databricks uses for Omnigent and Warp for its own product, is a layer that sits above several harnesses and treats them as swappable parts. That is different again from an orchestration framework like LangGraph, which is the thing you build agents in, and from an interoperability protocol like MCP, which is the wire format an agent uses to reach tools. A meta-harness wraps agents that already exist rather than giving you a way to write new ones.
One more shape sits in this family, and it is easy to mistake for a meta-harness because it too wraps a finished agent rather than a raw model. Zenith, an open-source project from Emad Mostaque's Intelligent Internet, calls itself a small MCP/ACP harness that runs a coding agent as a multi-agent . You point it at Code or Codex over the and it drives that one agent through a long task: planning milestones, spawning worker and tester , lifting recurring fixes into reusable skills, and deciding when the work is genuinely done rather than stopping early. The underlying agent is swappable, which is the meta-harness move. But the ambition is narrower. A meta-harness is a control plane that makes many harnesses interchangeable and governs them; an orchestrator like Zenith drives one of them to completion. Its wager is that the control loop around the model decides more than the model does, and on the project's own a mid-tier model under Zenith outranked the same model on its default harness . Hold that number loosely, since it is self-reported, but the design point survives it: the loop is where the work now goes.
The load-bearing observation is small and, once you see it, obvious. However a harness calls its model internally, whatever its loop, its prompts, its tool catalogue, the interface it presents to a user is the same: messages and files go in, text streams and tool calls come out . If that is true, then a harness is a black box with a standard set of ports, and anything with standard ports can be standardised into an interchangeable part. That is the whole premise. The meta-harness puts a uniform API in front of every harness and lifts the problems that do not fit inside any single one of them up to that shared layer.
The object being coordinated changed
Frameworks coordinated agents you built. Protocols coordinate the wires between them. The meta-harness coordinates other people's finished harnesses (Claude Code, Codex, Pi) as parts you can mix and swap. That is a different altitude, and it only became necessary once engineers were routinely running four or five agents at once.
How Omnigent works
Omnigent is open source under Apache 2.0, in alpha, built by the Databricks AI team with , and published to on 13 June 2026 by Matei Zaharia, Kasey Uhlenhuth and Corey Zumar . The shape is two pieces. A runner takes any agent and wraps it in a sandboxed session behind the uniform API, so Claude Code, Codex, Pi and your own agents all present the same ports. A server holds the policies and the sharing, keeps the sessions, and exposes each one over the terminal, a web , mobile, a macOS native app and a . Everything else is built on those two pieces, and on the three problems that live above any single harness.
| Licence | Sits above | The layer adds |
|---|---|---|
| Apache 2.0 | Claude Code · Codex · Pi | Composition · control · collaboration |
| open, alpha | plus custom agents and SDKs | enforced at the meta-harness, not in prompts |
Composition is the part that maps onto my workbench. A custom agent in Omnigent is a short YAML file instead of a framework you subclass: you name a harness, a model, a or an AGENTS.md, the MCP servers and functions it may call, and any sub-agents it coordinates . Switching the harness or the model is a one-line change, so the same definition can run on Claude Code today and a local open-weights model tomorrow. The roster that can sit behind that one line keeps widening: alongside Claude Code, Codex and Pi, version 0.2 added (a first-party and a native cursor-agent harness) and Google Antigravity, itself a harness that runs Gemini 3 Pro, Claude or -OSS underneath . Version 0.3 widened it again, hard: seven more harnesses at once (Hermes, GitHub , OpenCode, Goose, Qwen Code, Kiro and Kimi Code), with Antigravity promoted to a full SDK and native . The list of interchangeable parts is now growing faster than any one person can track, which is the swappable-parts premise proving itself in real time. If hand-writing YAML is too much friction, you ask a coding agent to write it for you and it registers the result so you can reuse it .
Version 0.3 also moved the model choice itself into the layer. Every harness in the fleet gained in-session model switching, so you can swap the model under a running agent with a single command, and the 0.3 announcement leads with an intelligent model router that picks the right model per turn on your behalf . That sits on top of the routing policy Omnigent already had, the one that classifies a task as trivial or complex and pushes the cheap work off the expensive model. I have argued elsewhere that hand-routing models is a transitional skill, that the picker is being absorbed into the harness the way query planning was absorbed into the database. A layer that routes across both the models and the harnesses on its own is what that absorption looks like, one level up.
The built-in orchestrators show what that buys. Polly, the default agent, is a supervisor that never writes code itself. It breaks a task into sub-tasks, hands each to a sub-agent running on its own harness and its own worktree, and has a different vendor review what the first one wrote. Its /fanout skill runs independent tasks in parallel, /cross-review loops an implementer's diff back through a rival-vendor reviewer until it comes back clean, and /investigate farms out read-only debugging and synthesises the findings. Polly opens a pull request per sub-task and never merges; the human decides . Debby, the other one that ships, is a brainstorming partner that sends every question to both Claude and GPT and runs a /debate skill for multi-round critique . Polly and Debby are themselves only YAML. They are worked examples, not privileged internals, and you build your own the same way.
Control is what makes this more than a convenience layer, and the piece I find most interesting. Omnigent's policies are stateful and contextual: instead of a static allow-this-tool, deny-that list, each policy carries state across the whole session and decides, on every tool call, request and file operation, whether to allow it, pause for approval, or deny it . That makes things possible a per-request rule cannot express: a cost budget that warns at one threshold and blocks expensive models at another, a rate limit that counts tool calls and halts a runaway loop, a risk score that accumulates across sensitive operations and escalates to a human once it crosses a line, even a routing policy that pushes trivial work off the expensive model. The example I keep coming back to: after an agent installs a new npm package, it needs human approval before it can git push . Policies stack at three levels at once (an admin's server-wide caps, a developer's per-agent restrictions, an end user's extra approval gates) and you can add one mid-session just by asking for it in plain language .
Underneath the policies sits Omnibox, the OS sandbox. The kernel enforces the boundary, not the agent or its : bubblewrap and seccomp on Linux, Seatbelt on macOS, inherited by every process the agent spawns, so a prompt-injected agent cannot opt out . The filesystem is masked to the paths you grant, and granting your home directory still hides ~/.ssh and ~/.aws/credentials. Outbound traffic goes through a default-deny proxy that blocks private IPs and cloud metadata endpoints. And credentials never reach the agent directly: it holds a placeholder token, the proxy swaps in the real secret only for allow-listed requests, and only the placeholder ever appears in logs, transcripts or model context . The agent can use a credential it is never permitted to read. Version 0.2 ships this as a named feature, credential_proxy, or "secretless sandbox egress", injecting bearer or basic auth for allow-listed hosts so the secret never enters the sandbox at all .
A prompt is not a permission boundary
Asking a model nicely not to push to main is not security; it is a suggestion it can be argued out of. Omnibox moves the rule into the kernel, where the agent cannot see it, reason about it, or talk its way past it. A leaked token that only works through the proxy, against hosts you allowed, is worth nothing to whoever leaks it.
Collaboration is the one I underrated at first. You share a live session by URL, and a teammate can open it to watch the agent work, comment on files in its workspace, send it commands, and review code beside the agent that wrote it, all in a session reachable from the terminal, the web UI, mobile or the native app, with auth and once you run a shared server . The mundane win is the death of copy-paste: the session and its working directory become the place the work happens, instead of a thing you screenshot into Slack. You can host the runner on your own machine or on sandbox providers (Modal and Daytona at launch, with NVIDIA OpenShell, E2B, CoreWeave and Podman added in 0.2), and put the server on the usual platforms-as-a-service, with a deploy target as of 0.2 .
None of this is meant to be a finished list. Policies are pluggable Python, agents are YAML you write or generate, and the roadmap points at automatic prompt optimisation, in-agent memory, more harnesses, and an Omnigent Server MCP so agents can act across your sessions . Version 0.2 had already started down that list, widening the harness roster and threading MLflow tracing through omnigent run so a multi-agent run is observable in one place ; version 0.3, eight days later, went further still, with a desktop app that manages the server and runner for you, a Projects workspace, native Windows support, and new hosting targets including Databricks Apps, and on-demand . That a coordination layer added this much in eight days is its own small reading on where the energy is gathering. The wager is that the interesting work now happens at this layer, and that an open one will attract more of it than a closed one.
Databricks reaches for an analogy I think is right. Engineers used to manage individual servers and processes; now they manage fleets through Kubernetes and Terraform, a layer up . The claim is that agents are at the same point, and the layer you work at should not have to change every time the model or the harness underneath it does.
Omnigent and Oz
Omnigent is not first. Warp shipped Oz in February 2026 and, in a May update, called it the first truly multi-harness control plane for cloud agents, running Claude Code, Codex and Warp's own agent side by side, with cross-harness memory and automatic multi-agent orchestration . The two products are the same species. They differ in one architectural choice that tells you something about each company's instincts.
| Omnigent | Oz |
|---|---|
| Open source under Apache 2.0 from day one, in alpha. Any harness is an equal wrapped session; none is privileged as the mandatory parent. Heavy emphasis on real-time, multi-human collaboration, with the OS sandbox and contextual policies as the security story. | Closed source (Warp's terminal went open in April; Oz did not). Warp Agent is the default and, per Warp's own docs, the only harness that can act as a parent spawning cross-harness sub-agents, a more centralised design. Strong enterprise framing: audit logs, governance, cross-harness memory. |
That privileged-parent detail is the tell. In Oz, a Warp Agent run can spawn Claude Code or Codex sub-agents, but the others cannot return the favour; they cannot act as parents in a multi-harness run . It is a reasonable engineering choice, and it also happens to keep Warp's own agent at the centre of every orchestration. Omnigent's bet is the opposite: no native agent to privilege, because Databricks is not trying to sell you the agent.
Hold this loosely
Both launches lean on "first" and "only" language, and the 2026 detail here is days old, sourced largely from vendor posts. The competitive picture will sharpen with real use, and some of these firsts are positioning as much as fact. The architectural difference is real; the marketing around it is the usual marketing.
The editor's cut is different
Open Zed or VS Code today and you will find something that looks a lot like the same idea. Zed's Agent Panel hosts external agents (Claude Code, Codex, Gemini CLI, OpenCode) through the Agent Client Protocol, an open standard that does for editor-to-agent what the Language Server Protocol did for editor-to-language-tooling. You install an agent from a shared registry and start a thread with it; the agent keeps its own runtime, auth and billing while Zed supplies the editor, the codebase context and the review surface . VS Code leaned harder into the framing: its 1.109 release in January 2026 added a unified Agent Sessions view and a separate Agents window, so you can run Claude and Codex alongside Copilot, delegate a task from a local session to a cloud one, and track several agents across projects from one place . JetBrains made the same bet from its own corner. Air, in public preview since March 2026 and built on the codebase of the shelved Fleet editor, is a desktop environment for running Codex, Claude, Gemini CLI and JetBrains' own Junie side by side, one agent to a task, with the human defining each task against specific symbols and reviewing every diff [R13b]. It speaks the same Agent Client Protocol as Zed, which is not a coincidence: the protocol is co-sponsored by JetBrains and Zed, so the editor's cut is already converging on a shared wire even where the meta-harness layer has not.
So is a meta-harness just an editor panel without the editor? Not quite. The editor panels coordinate at the surface where you read and review code. What they share is the interface and the codebase context; the agents themselves stay whole, each owning its runtime and its keys. Zed's cut is a protocol: ACP standardises the wire between a client and an agent, the way MCP standardises the wire between an agent and its tools. The meta-harness cuts lower: it wraps the agent itself in a sandboxed session, puts stateful policy and a kernel boundary around it, and then exposes that over whatever surface you like, including, in principle, an editor speaking ACP. Version 0.2 makes the connection concrete from the other side: its native cursor-agent harness is wrapped over ACP, so the protocol is already a live wire the meta-harness mounts an agent on today, a capability shipping rather than promised .
Three seams, not one fight
ACP standardises the client-to-agent connection, the editor's cut. MCP standardises the agent-to-tool connection, the harness's cut. The meta-harness wraps the agent itself. They are layers of one stack: an Omnigent session could surface inside Zed through ACP, extending the editor instead of replacing it.
The editors are answering one question: where do I sit while several agents work? Omnigent is answering a different one: what runs, governs and composes the agents, wherever I happen to be sitting. I expect to use both, and to stop noticing the seam between them.
Product, or protocol?
The question I keep coming back to: why would Databricks build a coordination layer and then give it away under Apache 2.0 on the morning of its own conference, instead of selling it?
The answer is in the layer below. Through 2025 the field decided that the connective tissue of agents should be a commons rather than a moat. A2A, Google's agent-to-agent protocol, moved to the in June 2025 for vendor-neutral governance . In December 2025, donated MCP to a new Agentic AI Foundation under the Linux Foundation, alongside Block's goose and 's AGENTS.md, with Google, Microsoft and among the backers . Direct competitors agreeing on shared plumbing is rare, and it signals a collective decision that the wires should belong to no one.
If the coordination layer becomes a commons too, the durable value moves to what sits underneath it: the harnesses, the models, and the infrastructure that runs them. That is precisely the territory an infrastructure company occupies. Open-sourcing the meta-harness is a cold bet: that the layer above agents will not be where the money is, and that the company best served by commoditising it is the one selling the compute, the data platform and the governance the agents run on. Whether the meta-harness ends up a product a few vendors own or a standard interface nobody does is the same fork the protocols already took. Databricks has placed its chip on "nobody."
The commons bet
An open meta-harness only pays off for Databricks if it becomes common infrastructure. The day-one open-source posture and the neutral architecture both point the same way: make the layer worthless to own, so the value pools in the platform beneath it.
When it pays off
The strongest case against all of this is the same one that deflated AutoGPT. Most work does not need a meta-harness. A single well-prompted agent in a good loop, with decent tool access, handles the large majority of coding tasks with far less to break. The moment you add a layer that coordinates several agents, you take on coordination overhead, duplicated context, multiplied token bills, and failure modes that are harder to debug because no single transcript tells the whole story. A meta-harness pays off only when you are running multiple agents in anger.
It is easy to dress up a habit as a need, and I have to watch for it in my own case. Some days the workbench is real: a local model churning through a migration while a frontier model reviews, and the saved cost and the second opinion both matter. Other days I have five agents open because it feels productive, and a single Claude Code session would have finished sooner. The discipline a control layer imposes (budget caps, approval gates, a sandbox that holds the tokens) is more obviously worth it than the orchestration.
I would adopt the control before I adopted the choreography.
There is a quieter cost under the token bills, and the vendors have started to name it: my own attention. The bottleneck in running fifteen agent threads is the person trying to hold fifteen conversations at once, not the compute beneath them. The tooling is converging on that admission. Claude Code's next version runs its sub-agents in the background by default, so the main thread stays yours while they work ; Omnigent built Polly on the same premise, one supervisor dispatching the rest so you are not babysitting each one. The scarce resource was never the model.
The meta-harness is the right abstraction for the four-or-five-agents reality the vendors keep describing, and that reality is real for a growing number of people, including me on a good week. It is overhead for everyone else, and pretending otherwise is how the last autonomy hype cycle ended.
What it is, and what to watch
Omnigent is a meta-harness: a layer that sits above the harnesses you already use, wraps each one as a sandboxed session behind a uniform API, and lifts composition, control and collaboration up to that shared layer. It is open source under Apache 2.0, it is days old, and it is not the first: Warp's Oz got to the multi-harness idea earlier, with a more centralised design that keeps its own agent at the centre.
The pattern under it is thirty-five years old. A new primitive turns out to be brittle alone, a coordination layer goes on top, and a standardisation effort tries to make the layers interoperate. FIPA tried it for agent communication in the 1990s and failed on rigidity; the protocols of the last two years are taking a second run with natural language doing the work the ontologies could not. The meta-harness is the same move, one level higher.
Three things to watch. Whether Oz and Omnigent converge on a shared abstraction the way the frameworks did, and whether that abstraction becomes a protocol nobody owns rather than a product a few vendors do. With the editor panels in Zed and VS Code converging on the same goal from the surface down, the pressure toward a shared standard is already there. Whether the governance commons that swallowed MCP and A2A swallows this layer too.
Final thought
And the oldest question in the field, which has not changed since AutoGPT: whether you are running enough agents at once to need any of it, or whether one good agent in one good loop was the answer all along.
References17
- 1Mario Rodriguez, "GitHub Copilot is moving to usage-based billing", The GitHub Blog, 27 April 2026. github.blog ↗
- 2M. Zaharia, K. Uhlenhuth, C. Zumar, "Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents", Databricks Blog, 13 June 2026. databricks.com ↗
- 3Omnigent project, docs and source (Apache 2.0, alpha; built by the Databricks AI team with Neon; runner/server architecture, custom agents as YAML, interfaces). omnigent.ai ↗ · github.com ↗ Accessed 2026-06-16
- 4Warp, "A single pane of glass for managing all of your cloud agents" (Oz launched February 2026; multi-harness update May 2026). warp.dev ↗ Accessed 2026-06-16
- 5Warp, "Warp Agent with Oz" (Warp Agent is the only harness that can orchestrate sub-agents in a multi-harness run). docs.warp.dev ↗ Accessed 2026-06-16
- 6A. Ehtesham, A. Singh, G. K. Gupta, S. Kumar, "A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP", arXiv:2505.02279, 2025 (KQML/FIPA-ACL history and the framing of MCP/A2A as responses to FIPA's documented limitations). arxiv.org ↗
- 7Linux Foundation, "Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)… Including Model Context Protocol (MCP), goose and AGENTS.md", 9 December 2025. linuxfoundation.org ↗
- 8A2A Project (Agent2Agent), introduced by Google April 2025; transferred to the Linux Foundation June 2025 for vendor-neutral governance. a2a-protocol.org ↗ Accessed 2026-06-16
- 9Omnigent docs, "Polly" (multi-agent coding orchestrator: sub-agents in separate worktrees, cross-vendor review, supervisor never merges). omnigent.ai ↗ Accessed 2026-06-16
- 10Omnigent docs, "Omnibox" (kernel-enforced OS sandbox: filesystem and network isolation, credential injection via placeholder tokens; bubblewrap/seccomp, macOS Seatbelt). omnigent.ai ↗ Accessed 2026-06-16
- 11Omnigent docs, "Contextual Policies" (stateful allow/ask/deny policies; session/developer/admin levels; cost, rate-limit, risk-scoring and routing policies). omnigent.ai ↗ Accessed 2026-06-16
- 12Zed, "External Agents" and "Agent Client Protocol" (Agent Panel hosts external agents such as Claude Code, Codex, Gemini CLI and OpenCode via ACP; agents own their runtime and auth). zed.dev ↗ · zed.dev ↗ Accessed 2026-06-16
- 13Visual Studio Code, "Your Home for Multi-Agent Development" (1.109, January 2026) and "Use the Agents window (Preview)". code.visualstudio.com ↗ · code.visualstudio.com ↗ Accessed 2026-06-16
- 14Omnigent v0.2.0 release notes, GitHub, 19 June 2026 (Cursor via Python SDK and a native `cursor-agent` ACP harness; Google Antigravity running Gemini 3 Pro / Claude / GPT-OSS; secretless sandbox egress via `credential_proxy`; new sandbox providers NVIDIA OpenShell, E2B, CoreWeave, Podman and a Cloudflare Containers deploy target; MLflow tracing through `omnigent run`), and M. Zaharia, announcement post on X, 19 June 2026. github.com ↗ · x.com ↗ Accessed 2026-06-20
- 15Intelligent Internet, "Zenith" (project README) and "Zenith: frontier performance without Fable", ii.inc blog, 29 June 2026: an open-source MCP/ACP harness that runs a coding agent (Claude Code, Codex) as a multi-agent orchestrator for long-horizon tasks, with adaptive workers, testers, reusable skills and a principled stopping rule. Benchmark figures are self-reported on the project's own "Frontier SWE" set, not a public benchmark. github.com ↗ · ii.inc ↗ Accessed 2026-06-30
- 16Omnigent v0.3.0 release notes, GitHub, 27 June 2026 (seven new harnesses: Hermes, GitHub Copilot, OpenCode, Goose, Qwen Code, Kiro and Kimi Code, with Antigravity promoted to a full SDK and native CLI; fleet-wide native-harness parity including in-session model switching, cost and token tracking, resume and true fork; Omnigent Desktop managing the server and runner; a Projects workspace; native Windows support; and new deploy and sandbox targets including Databricks Apps with Lakebase Postgres, AWS Bedrock and an on-demand Kubernetes runner), and @omnigent_ai, v0.3.0 announcement on X, 27 June 2026, which leads with "an intelligent model router to pick the right model per turn". The automatic router is the announcement's framing; the release notes themselves itemise the manual in-session model switching and the contextual model-routing policy it builds on. github.com ↗ · x.com ↗ Accessed 2026-06-30
- 17Boris Cherny (Claude Code, Anthropic), preview post on X, 29 June 2026: in the next version of Claude Code, sub-agents run in the background by default so you can keep talking to Claude while they work, with a foreground option on request. Sabhya Chhabria (Omnigent), reply on X, 30 June 2026, ties the same idea to Omnigent's Polly: with ten to fifteen or more agent threads in flight, human attention is the bottleneck, so one interface should dispatch many agents rather than fragment your focus. x.com ↗ · x.com ↗ Accessed 2026-06-30