---
title: "How Do Panda Code Agent Teams Work? Cheap, Balanced, Best"
url: "https://goremy.ai/blog/articles/panda-code-agent-teams-cheap-balanced-best"
author: Luis Chavez-Mattos
editor: Luis Chavez-Mattos
editor_title: Director, Product
published: "2026-11-03T14:00:10.634Z"
updated: "2026-11-03T14:00:10.634Z"
topic: Agent Harnesses and Skills
description: "Set up Panda Code agent teams: cheap, balanced and best modes, router-first dispatch, retries, harness failover, model pauses and the S-to-D tier list."
---

# How Do Panda Code Agent Teams Work? Cheap, Balanced, Best

> Set up Panda Code agent teams: cheap, balanced and best modes, router-first dispatch, retries, harness failover, model pauses and the S-to-D tier list.

Edited by Luis Chavez-Mattos, Director, Product · Published 2026-11-03

## How do Panda Code agent teams work?

Panda Code is an open-source workspace that runs coding agents such as Claude Code, Codex, Kimi and Open Code side by side. In a team, a lead agent (the architect) splits a task into assignments and hands them to parallel workers. A built-in router, Panda Router, picks each worker's model. In cheap and balanced modes, workers start on the cheapest model likely to pass. If review fails, the worker is replaced by a stronger model.

## TL;DR

- The **team button** in the prompt box offers four choices: no team, cheap team, balanced, and best team. Your last choice carries over to new tasks.
- Teams are **router first**. The architect only picks a model itself if you name one in your message, or if the router has nothing left.
- A failed review triggers a **retry on a stronger model**, never a weaker one, and the team stops after two retries instead of looping.
- A crashed CLI, rate limit or expired login triggers **harness failover** to the same model on another installed harness, not an escalation.
- Erroring models get a **health pause** of 10 minutes that doubles up to 2 hours, and paused models are hidden from the router and the architect.
- Your **S-to-D tier list** in settings steers the router with a weighted nudge, not a hard override.

## What do the cheap, balanced and best team modes do?

The team button gives you one menu. The modes differ in how the router weighs success against cost and speed.

| Mode | How the router picks a model |
|---|---|
| No team | Single agent, no dispatch |
| Cheap team | Cheapest model whose chance of success clears a minimum you set |
| Balanced | Weighs chance of success against cost and speed |
| Best team | Strongest fit for the task |

New tasks start on whichever mode you used last, so you set it once. The first time you enable a team, the app downloads the router's profiler model once (a small file, checked against a SHA-256 hash, never fetched at launch). While it downloads, a keyword fallback picks models, so the team never waits.

## What is Panda Router and how does it choose a model?

Panda Router is a small decision model, not a chatbot. It writes no code. Given a task and a list of runnable models, it outputs a category, a difficulty from 1 to 10, the skills needed, and flags such as whether tools or images are required.

Ordinary code, not a neural network, then scores every model against that profile on chance of success, cost and speed. The creator split it this way on purpose: judgment lives in the model, policy lives in testable code. If a pick looks odd, you can see why and change a rule without retraining.

Models are plain data. Each has a JSON card with skill levels, price, context window and latency. A new model release means adding a card. The router also sees every model from every coding tool you have installed. On the creator's machine that meant 45 rated models, up from an earlier cap of six per tool.

Two design choices matter for how it behaves:

- It decides on a lower bound of the success estimate, not the optimistic number.
- It compares expected cost, which includes the cost of a failed attempt. A cheap model that fails half the time is not cheap.

## How does the escalation ladder retry failed work?

Along with its pick, the router returns an ordered ladder of models. A worker starts on the first rung. The architect checks the result, ideally with tests, a type check or a review. On failure, the architect replaces the worker, and the router picks a model stronger than every model that already failed on that assignment. The ladder never steps down.

After two retries the team stops and reports the failure. The dispatch notes in the thread show where you are, for example "routed to haiku, ladder one of three," followed by a step-up note listing skipped models.

The creator's own evaluation used 150 held-out tasks with real attempts across a nine-model pool. These are self-reported numbers:

| Strategy | Tasks solved per 100 |
|---|---|
| Router single pick, default mode | about 77 |
| Always sending everything to one large model | about 79 |
| Router with up to two attempts | about 91 |
| Perfect per-task routing (best case) | 94 |

The single pick landed near the always-use-the-big-model baseline at lower cost. One retry closed most of the gap to perfect routing. The creator also notes that the model cards are still estimates for many coding-tool models, and that success numbers look low because a strict judge produced them. Compare models to each other, not to 100%.

Escalation is only as good as the check behind it. Give the architect real tests where you can.

## What happens when a harness breaks instead of a model?

Workers often fail because the harness broke, not because the model was weak. Rate limits, CLI crashes and expired logins all qualify. Panda Code handles these separately from bad answers.

1. The worker's model errors on a harness.
2. Panda Code moves the worker to the same model on another installed harness (for example, through Codex instead of a different CLI).
3. It reruns the work on a fresh session.
4. The architect receives a failover note containing the real error.

A crashed run no longer counts as a bad answer. Only a result that fails review moves the task up the ladder.

## How do model health pauses work?

When a model errors on a harness, Panda Code pauses it there for 10 minutes. The pause doubles on each repeat, up to 2 hours. If two models on the same harness are paused, the whole harness pauses until something on it works again.

Paused models never reach the router or the architect. Pauses survive restarts. Settings lists each one with the reason, time left and an "allow now" button.

You also get on/off switches per harness and per model under the models-for-teams settings. A switched-off model is skipped by the router, the fallbacks and failover. Harnesses with huge catalogs, such as Open Code or Kilo, only offer the 10 most recently used models plus any you add manually.

## How does the S-to-D tier list steer the router?

In settings you drag models into S, A, B, C and D rows. The ranking affects routing in three ways:

- For a ranked model, chance of success is weighted 70% your tier and 30% the router's own rating, at every difficulty.
- Your ranking sets the order on the escalation ladder and the floor for never stepping down.
- One rank covers that model on every harness.

A model the router has no card for becomes pickable once you rank it. The weight is strong but not absolute. To make your order win outright, rank both models you are comparing.

## What else changed in the orchestrator?

Several updates affect how teams behave day to day.

- **Subworkers.** A worker can start its own subworkers when a task splits. The limit is one level deep, three running at once and six total, confined to the worker's own files. A waiting worker is parked: its process exits, freeing roughly 250 to 390 MB, and it resumes with the results without using an attempt.
- **Messaging.** Team tool results carry a digest of unread messages, so agents don't poll. Messages can go to the whole team or reply to one, and urgent ones reach a worker mid-turn.
- **Shared notes.** A board holds up to 64 short facts, such as an API shape or a decision. Every new worker receives it at start.
- **A resting architect.** It wakes only for urgent messages, blockers, failures or finished results. Worker instructions are about 80% shorter, and review turns are about a third of their old size.
- **Readable threads.** Dispatches show as cards listing each worker's model, files and status. The changes view shows which worker changed which lines.

## Is the router-first setup worth using?

It fits if you run several coding agents and hit limits on trivial work. The practical gains are cheaper easy tasks, automatic recovery from breakage, and a record in the thread of every routing decision.

Know the limits. The profiler runs through an ONNX runtime, and Intel Mac and x86 Linux builds currently use the keyword fallback because no compatible runtime build exists. The creator also tested later router versions and kept version 4.3 as default because newer ones missed their pre-written pass rules.

## Frequently Asked Questions

### Can I force a specific model for part of a team task?

Yes. Name the model in your message, such as asking for a particular Kimi model on the front end. The architect uses it for that work and routes everything else.

### Does a crash count as a failed attempt?

No. Crashes, rate limits and expired logins trigger failover to the same model on another harness. Only a result that fails review moves the task to a stronger model.

### How many retries does a worker get?

Two. After that, the team stops and tells you the assignment failed, rather than burning limits in a loop.

### Does my task data leave my machine for routing?

The body does not state the profiler's speed or where it runs. It only says the profiler runs through an ONNX runtime, and that Intel Mac and x86 Linux builds currently use the keyword fallback.

### Does the tier list override the router?

Not fully. Your tier counts for 70% of the success estimate and the router's rating for 30%. Rank both models in a comparison if you want your order to win outright.