Repos Worth Reading · 2026-09-05 · 1,321 words · 6 min read

Omnigent explained: the fastest-rising agent toolkit, read at v0.12.0

How I picked this month's fastest-rising agent repo with a GitHub search, what Omnigent's README says it is, its policy and sandbox model, and what is unverified.

omnigent meta-harness github search policies

The launch slate asked for the fastest-rising agent toolkit this month, read at its current release. This piece shows the method I used to pick it, because the method has limits worth stating, then reads the winner's README and release at a named commit. The winner is Omnigent, a repository created on 2026-06-11 that had 9,725 stars by 2026-09-05. I did not install or run it, and the piece says so where it matters.

The method, and its limits

I ran the GitHub repository search endpoint through a small research script, sorted by stars descending, with five queries that each carried a creation-date filter. The queries and the top results are in the shipped dataset, 66 rows in all. The one that decided it was coding agent framework created:>2026-06-01, where the first result had 9,725 stars and the second had 538. The other queries (coding agent created:>2026-07-15, agent created:>2026-08-01, agent toolkit created:>2026-06-01, llm agent sdk created:>2026-06-01) surfaced repositories with between 119 and 4,963 stars, most of them skill packs, chat clients, or vision helpers rather than toolkits for running coding agents.

Three limits. First, "rising" here means stars accumulated since creation, filtered to repositories created after a date; it is not a velocity measure, and a repository created in June with 9,725 stars may have gained most of them in one week or spread over twelve. The search API does not return star history. Second, star counts are a popularity signal that can be bought or campaigned, and I have no way to audit that from the API. Third, the query words matter: "framework" pulled in Omnigent, while "toolkit" pulled in a different population. I chose the query that matched the slate's phrase "agent toolkit" most closely in spirit, and I show the others so you can disagree.

The dataset ships every row I saw, with the query, the rank within the query, the repository, stars, the last push date, the license, and a truncated description, all stamped with the read date.

_README for omnigent-meta-harness-explained.csv
query                 the GitHub search query string, including the created:> filter
rank_in_query         1-based position in that query's result list (sorted by stars, descending)
repo                  owner/name
url                   the repository URL
stars                 stargazer count returned by the API on read_at
pushed_at             date of the last push returned by the API
license               SPDX id as returned, or NOASSERTION / empty when GitHub could not detect one
description_truncated the repository description, first 120 characters
read_at               2026-09-05 for every row

The repository at a named commit

Read on 2026-09-05, omnigent-ai/omnigent had 9,725 stars, 1,514 forks, and 1,305 open issues, an Apache-2.0 license, Python as its top language, and topics including agent-framework, agent-governance, claude-code, codex, coding-agents, and sandbox. The latest release was v0.12.0, published 2026-09-01. The latest commit on main was 83cc3e7113df, dated 2026-09-05, with the message "fix(native): fold gateway-namespace model pins onto the launch catalog's spelling (#6052)". The README carries a "Status: alpha" badge. That issue count and the alpha badge together say what kind of project this is: large, fast, and unfinished, and any reading of it is a snapshot.

The repository description: "Omnigent is an open-source AI agent framework and meta-harness: orchestrate Claude Code, Codex, Cursor, Pi, and custom agents — swap harnesses without rewriting, enforce policies and sandboxing, and collaborate in real time from any device."

What the README says it is

The README's own definition is "an open-source meta-harness that gives you a common orchestration layer over Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, and the agents you write yourself: swap or combine harnesses without rewriting, enforce policies and sandboxing, and collaborate in real time from any device — terminal, browser, phone, or the native desktop app." The phrase meta-harness is precise if you accept the definition in what a coding-agent harness actually is: a harness wraps a model with tools, a loop, and a permission gate; a meta-harness wraps several harnesses with a shared session, a shared policy layer, and a shared sandbox.

The "Why Omnigent?" list gives five capabilities: sessions that "follow you: start in your terminal, continue in the browser, pick it up on your phone"; supervising multiple agents, where you can "Mix Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, and custom agents (defined in YAML) together in the same session"; any model, via "A first-party API key, a Claude/ChatGPT subscription, or any compatible gateway"; collaboration, by sharing a session; and cloud sandboxes, "disposable Modal, Daytona, Blaxel, Islo, E2B, CoreWeave, Kubernetes, OpenShell, Boxlite, or Databricks sandboxes."

Install is a curl-to-shell script, with uv tool install omnigent or pip install "omnigent" as the manual route, and the README states "Omnigent needs Python 3.12+." The prerequisites list is where the sandbox model shows. tmux is "required by the native omnigent <harness> terminal wrappers." And on Linux, bubblewrap is required: "The native omnigent <harness> terminal wrappers and the pi harness wrap each agent terminal in a bwrap OS-sandbox; on Linux that isolation is mandatory, so a missing bwrap binary makes those terminals fail to start." macOS "uses the built-in seatbelt". Those are the same two mechanisms that Claude Code's own sandbox documentation names for Linux and macOS, so a meta-harness on top of Claude Code is wrapping a sandbox around a tool that can already sandbox itself, and the README does not say how the two interact. That is a question I would put to the project before relying on either layer.

After install, the entry points are one command per harness:

omnigent            # picks a model with you and starts a session
omnigent claude     # Claude Code
omnigent codex      # Codex
omnigent cursor     # Cursor
omnigent opencode   # OpenCode
omnigent hermes     # Hermes Agent
omnigent pi         # Pi

Policies: the governance layer

The section the README calls "Govern your agents with policies" is the part I find most interesting, because it is a permission model expressed as data rather than as flags. The README's one-line definition: "Policies decide what an agent may do: run shell commands, edit files, spend tokens." The example configuration:

policies:
  approve_shell:
    type: function
    handler: omnigent.policies.builtins.safety.ask_on_os_tools
  cap_calls:
    type: function
    handler: omnigent.policies.builtins.safety.max_tool_calls_per_session
    factory_params:
      limit: 50
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [3.00]

Read the three policies against the per-harness controls in permission models compared. ask_on_os_tools is an ask rule on shell and file tools. max_tool_calls_per_session with limit: 50 is a step limit of the kind mini-swe-agent hard-codes in its config. cost_budget with max_cost_usd: 5.00 and ask_thresholds_usd: [3.00] is a spend cap with a warning threshold, comparable to a headless budget flag, except that here it applies across whichever harness is running. The README says policies "apply to the whole server, one agent, or a single chat." A policy layer that sits above the harness is the one thing a single harness cannot give you, and it is the strongest argument for the meta-harness idea.

Custom agents are YAML too, with an executor that names the underlying harness and tools of three types:

name: my_agent
prompt: You are a helpful data analyst.

executor:
  harness: claude-sdk

tools:
  word_count:
    type: function
    callable: mypackage.mymodule.word_count

  docs:
    type: mcp
    url: https://example.com/mcp

  researcher:
    type: agent
    prompt: Search for relevant information and summarize it.
    tools:
      word_count: inherit

The type: mcp line means the toolkit speaks the protocol described in the MCP tutorial, and type: agent with inherit is a subagent that borrows a parent's tool. Which MCP protocol revision it implements is not stated in the README, and I did not read the source to find out.

What I could not verify

I did not install Omnigent, did not start a session, did not test a policy, and did not open a cloud sandbox. Everything above is the README and the API metadata at the named commit. The README's claims about session sync across devices, real-time collaboration, and sandbox providers are claims. The alpha badge and the 1,305 open issues are the project's own signal that behavior may differ from the README on any given day. The star-based selection method is documented above with its weaknesses, and the dataset lets you rerun the comparison against the snapshot.

What I can say from the reading: the project has picked the right layer to work at. Harnesses are now plentiful and similar, and the differences that matter to a team are cross-cutting: who approves what, how much is spent, where the process runs. Omnigent puts those three in one YAML file above the harness. Whether it does so reliably is the question a run would answer, and this piece did not run it.