AIPETERLABRead the notes ↗

Codex Learning · September 20, 2026

Use Jev to Route Work Between Codex, Claude, Gemini, and Grok

Jev can choose which agent appears best suited to a task, but a local dispatcher—not Jev itself—must launch the selected agent.

If Codex and Claude Code are already installed on your PC, you may want one entry point that can also consider Gemini and Grok. The idea sounds simple: describe a task, let Jev classify it, and send it to the best agent.

The real architecture needs four separate layers:

Your task
   ↓
Jev returns a routing decision
   ↓
A local PowerShell dispatcher reads the decision
   ↓
Codex CLI | Claude Code | Gemini CLI | Grok Build
   ↓
The selected agent works with its own login and permissions

Jev is TypeSafe AI's decision model. It answers typed questions with choices, scores, or probabilities; it is not a universal chatbot launcher. A community Jev command-line wrapper can expose those decisions in the terminal, but the wrapper is unofficial and its current Windows guidance recommends using WSL. The routing script in this guide is therefore a transparent starting point, not an official TypeSafe product.

What this setup can and cannot do

This setup can:

It does not combine your ChatGPT, Claude, Gemini, and Grok accounts. It does not transfer chat history, subscriptions, memory, permissions, or credentials between them. It also does not guarantee that Jev's choice is correct. You define the routing criteria and remain responsible for reviewing the decision.

This guide routes coding-agent CLIs. It does not automate the ChatGPT website or desktop conversations. Codex CLI can use its own supported sign-in, while Claude Code, Gemini CLI, and Grok Build authenticate independently.

Before installing anything

Use a normal Windows account and keep every provider's credential separate. Do not put API keys in the routing prompt, the PowerShell script, Git, or a shared AGENTS.md. Confirm that you understand the billing and data-handling terms for every service you enable.

You will need:

Step 1: verify the agents already installed

Open PowerShell and check the commands you intend to route to:

codex --version
claude --version
gemini --version
grok version

A failed command means the dispatcher cannot launch that agent. Install only the agents you actually intend to use.

Codex CLI

OpenAI provides a Windows installer for Codex CLI:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
codex

Follow the sign-in flow and run one harmless task before adding routing.

Claude Code

Anthropic documents npm installation for Claude Code:

npm install -g @anthropic-ai/claude-code
claude

Claude Code on Windows requires a supported Windows environment such as WSL or Git for Windows, depending on the installation method.

Gemini CLI

Google's published package still installs Gemini CLI globally:

npm install -g @google/gemini-cli
gemini

Do not assume an ordinary personal Google sign-in will work. Google announced that, beginning June 18, 2026, Gemini CLI stopped serving free-tier, Google AI Pro, and Google AI Ultra individual accounts. Supported enterprise Gemini Code Assist licenses and API-key authentication were not affected. Individual users are directed to Google's successor Antigravity CLI. Before adding gemini to this router, confirm that your account and authentication method remain supported and test one harmless command.

Grok Build

xAI documents Grok Build as a coding agent with interactive and headless modes. On a Windows PC with Node.js, its official npm distribution can be installed with:

npm install -g @xai-official/grok
grok login
grok version

You can use browser login where supported or configure an xAI API key for headless automation. Treat API usage as separately billed unless your provider terms explicitly say otherwise.

Step 2: install WSL for Jev

The community jev CLI currently describes native Windows as untested and recommends WSL. In an elevated PowerShell window, Windows can install WSL with:

wsl --install

Restart if Windows requests it, open the installed Linux distribution, and finish creating the Linux username. The rest of the Jev installation in this section runs inside WSL, not ordinary PowerShell.

Step 3: inspect and install the community Jev CLI

The following wrapper is maintained by a community developer, not TypeSafe. Review its repository and release before installing it. The project's documented installation downloads the installer first so you can inspect it:

curl --proto '=https' --tlsv1.2 -fLsS   https://github.com/okooo5km/jev/releases/download/v0.3.2/install.sh   -o /tmp/jev-install.sh

less /tmp/jev-install.sh
sh /tmp/jev-install.sh
export PATH="$HOME/.local/bin:$PATH"
jev --version

Do not blindly reuse the version number months later. Check the project's releases and checksum instructions first. Pinning a reviewed version is safer than automatically downloading whatever happens to be latest.

Step 4: configure the Jev key privately

Create a TypeSafe API key in TypeSafe's console. Then, inside your own WSL terminal, run:

jev auth set
jev auth status
jev auth check

The community CLI's interactive command hides the input and stores it in its user configuration. Do not paste the key into Codex, Claude, Gemini, Grok, this blog, or the routing script.

Test a routing-style decision directly:

jev pick "Which agent should handle this task?"   codex="repository implementation, testing, and Codex workflows"   claude="long-form code analysis and an existing Claude Code workflow"   gemini="Google ecosystem work or Gemini-specific tools"   grok="xAI tools, X search, or an existing Grok Build workflow"   --other   -s "Inspect a Next.js repository and fix one failing test"

Jev can only choose from the meanings you provide. Those descriptions are your routing policy, not an objective ranking of the agents.

Step 5: create the PowerShell dispatcher

Save the following example as route-agent.ps1 in a private utilities directory. It sends the task description to Jev through WSL, validates the returned label, shows the route, and asks for confirmation before starting the selected agent.

param(
    [Parameter(Mandatory = $true)]
    [string]$Task
)

$jevArguments = @(
    'pick'
    'Which agent should handle this task?'
    'codex=repository implementation, testing, and Codex workflows'
    'claude=long-form code analysis and an existing Claude Code workflow'
    'gemini=Google ecosystem work or Gemini-specific tools'
    'grok=xAI tools, X search, or an existing Grok Build workflow'
    '--other'
    '-s'
    $Task
)

$decision = wsl jev @jevArguments

$route = ($decision | Select-Object -First 1).Trim().ToLowerInvariant()
$allowed = @('codex', 'claude', 'gemini', 'grok')

if ($route -notin $allowed) {
    throw "Jev returned an unsupported or uncertain route: $route"
}

Write-Host "Jev selected: $route"
$answer = Read-Host "Launch this agent? Type yes to continue"

if ($answer -ne 'yes') {
    Write-Host "Stopped without launching an agent."
    exit 0
}

switch ($route) {
    'codex'  { codex exec $Task }
    'claude' { claude -p $Task }
    'gemini' { gemini -p $Task }
    'grok'   { grok -p $Task }
}

This example intentionally avoids automatic approval flags. Every selected agent should retain its normal sandbox, permission prompts, and project instructions.

Step 6: test routing without real work

Before allowing the dispatcher to modify a repository, temporarily replace each launch command with a message:

'codex'  { Write-Host "Would launch Codex" }
'claude' { Write-Host "Would launch Claude" }
'gemini' { Write-Host "Would launch Gemini" }
'grok'   { Write-Host "Would launch Grok" }

Then test known cases:

.
oute-agent.ps1 -Task "Fix a failing unit test in this Codex project"
.
oute-agent.ps1 -Task "Use Google-specific tools to examine this project"
.
oute-agent.ps1 -Task "Review an xAI integration and verify Grok API usage"

Record whether each task reaches the intended label. If routing is inconsistent, improve the option descriptions and build a small set of expected examples before enabling real launches.

Step 7: protect project boundaries

The router chooses an agent; it does not choose safe permissions. Launch the dispatcher from the intended project directory and give the selected agent only the access needed for that project.

Routing decision
    does not grant permission

Selected agent
    still follows its own workspace,
    sandbox, approval mode,
    project instructions, and credentials

For a multi-project Control Center, use Jev first for read-only classification or routing. Perform write work in a narrowly scoped target project. Keep commit, push, deployment, deletion, and publication as separate approval decisions.

Privacy and security concerns

When this system is worth building

A Jev router is useful when you repeatedly receive many similar tasks, already maintain several authenticated agent CLIs, and can state a stable routing policy. It is unnecessary if you manually choose among two agents a few times per day. A menu may be simpler, cheaper, and easier to audit.

Start with recommendation mode:

Task
 ↓
Jev recommends an agent
 ↓
You approve or override
 ↓
Dispatcher launches the agent

Only consider automatic routing after you have a labeled test set, reliable confidence handling, logs that exclude sensitive content, and a safe response to uncertain decisions.

The central lesson

Jev should be the classifier, not the all-powerful controller. Codex, Claude Code, Gemini CLI, and Grok Build remain independent agents with separate accounts, permissions, context, and safety controls. The local dispatcher is the explicit bridge between the decision and the action.

Jev decides
Dispatcher validates
User confirms
Selected agent acts
Native permissions remain in force

Sources and further reading

More Codex Learning →