Traycer Multi-Agent Test: Can Fable 5 Make a Local Qwen 27B Better?

Direct Answer

In this one flight-simulator task, Fable 5 made a local Qwen3.6 27B substantially more useful by managing the work around it. The orchestrated run produced a functioning browser game with throttle, pitch, roll, yaw, instruments, takeoff, stall and crash behavior, a runway, and a populated city. A solo Qwen run finished after roughly 32 minutes with more visible terrain but no useful throttle or flight controls.

That does not mean Fable changed Qwen's intelligence or that the pairing will win every task. It means a stronger planner-reviewer can turn one oversized request into bounded milestones, inspect the builder's output, catch mistakes, preserve state across a context reset, and decide what should happen next. The model stayed the same. The workflow improved.

Watch the Traycer Test

Video credit and disclosure: test, commentary, and results by Bijan Bowen. Watch the original video. Bijan discloses that Traycer supported the channel and sponsored this episode. This independent article is not sponsored; creator observations are separated from current official documentation and from my analysis.

What Traycer Actually Is

Traycer is not another foundation model. Its open-source desktop app is a control surface around coding agents. It can connect existing provider accounts, keep durable task context, create parent and child agents, route work to different runtimes, show transcripts and diffs, and run agents in isolated Git worktrees. The repository is published under the MIT License.

Traycer's current documentation lists Claude Code, Codex, OpenCode, Traycer, Cursor, Grok, Qwen Code, Kimi, Copilot, and several other paths. Availability depends on the installed CLI, provider account, model access, and selected interface. That moving capability matrix matters more than a static logo wall.

The Architecture Used in the Video

Human goal
   |
Traycer Task
   |
Fable 5 orchestrator in Epic mode
   |  plan one milestone + acceptance criteria
   v
OpenCode child agent
   |
Local Qwen3.6 27B BF16 server
   |  edit files + report result
   v
Repository / artifacts / syntax checks
   |
Fable review and correction
   |
Next milestone, fresh child agent, or human escalation

The main request was a realistic passenger-jet simulator in a browser: pilot view from a runway, interactive flight controls, cockpit instruments, detailed scenery, and plausible physics. Fable was told to guide the local model without doing the implementation itself. Traycer's structured workflow gave Fable a place to decompose the build and hand each bounded job to the Qwen-backed child agent.

This resembles a small engineering team more than a model council. Fable owned architecture and review. Qwen owned implementation. The files were the shared state. The next instruction depended on what the reviewer found in the actual code, not only on the builder's summary.

How the Build Unfolded

Fable's generated scorecard claimed roughly 30 substantive defects were found across four fix rounds and that none survived the final build. Treat that as a model-produced review artifact, not an independent audit. It is still useful because it shows the value of a durable defect log and explicit review rounds.

Orchestrated Qwen vs Qwen Alone

The comparison's most important lesson is not that a frontier model can rescue a small one. It is that visual completion is not task completion. The solo build looked like a flight scene. The orchestrated build passed more of the requested behaviors. Once acceptance criteria become explicit, the evaluator stops rewarding screenshots for work that does not function.

Why the Orchestration Helped

1. The first step was smaller than the product. Qwen did not have to design the world, physics, controls, instruments, audio, city, and failure states in one pass.
2. Each milestone had acceptance criteria. The planner could reject a visually plausible feature that did not actually work.
3. The reviewer inspected files. Fable caught event handling, key conflicts, and numeric precision risks that a status summary could hide.
4. Builder and reviewer had different incentives. Qwen tried to complete the bounded patch; Fable tried to find what remained wrong.
5. The handoff survived a context reset. A summary let a fresh agent continue without carrying the whole transcript.
6. The builder could disagree. Qwen corrected Fable's mistaken pitch instruction instead of following a bad plan blindly.

This is the same core idea behind graph engineering: make jobs, dependencies, state, checks, retries, and approvals visible. Traycer packages more of that graph into a desktop interface.

The Failures Matter as Much as the Working Demo

The run hit a configured context boundary. Qwen's official model card says Qwen3.6 27B supports 262,144 tokens natively and recommends retaining at least 128K for complex work. Bijan ran the server at 131,072. The overflow therefore describes this session's configuration and accumulated agent work, not the model's absolute maximum.

The local inference server also became stuck and cut off the builder during edits. Bijan explicitly frames this as a networking or server problem on his local AI machine rather than proof of a Traycer defect. That distinction is essential: a multi-agent UI can coordinate requests, but it cannot make a fragile model server reliable.

Traycer's Current Limits, Pricing, and Privacy Boundary

Traycer's current agent-to-agent documentation separates referencing, reading transcripts, and sending messages. On the Chat interface, supported agents can use all three. On the Terminal interface, only Claude Code currently receives agent-to-agent messages; Codex and OpenCode can be referenced and have their transcripts read on the owning Host, but they do not have an inbox for direct messages. Agent-to-agent delivery also requires the same user and the same reachable Host.

The free BYOA plan is documented as local-only and includes no cloud sync or sharing. Paid tiers add sync, collaboration, and optional Traycer inference credits. Using Claude Code, Codex, OpenCode, or Cursor follows those providers' billing; using Traycer's provider consumes Traycer credits with a documented markup.

Privacy is configuration-dependent. The repository says code is processed in memory and not stored or used for training. It also says prompts and conversations may be logged when Privacy Mode is off, while Sentry crash reporting and PostHog analytics may be enabled in release builds. Teams should verify Privacy Mode, provider retention, sync requirements, analytics settings, and the sensitivity of the repository before connecting real client or company code.

Local Qwen Is Not Free Compute

Qwen3.6 27B is genuinely open-weight under Apache 2.0, and its official model card documents vLLM, SGLang, Transformers, Docker, Qwen-Agent, and Qwen Code paths. But the video used the BF16 checkpoint on an NVIDIA RTX Pro 6000 Blackwell-class workstation. Raw 16-bit weight arithmetic for 27 billion parameters is roughly 54 GB before KV cache, runtime buffers, vision components, and serving overhead.

A local worker can reduce marginal API spend and keep model execution on hardware you control. It also creates capital cost, electricity use, setup time, driver and framework maintenance, heat, monitoring, and a single-machine failure domain. Compare cost per accepted task, not token price alone.

A Better Multi-Agent Evaluation Protocol

1. Freeze the task. Use the same repository commit, asset pack, requirements, and success rubric.
2. Run three conditions. Qwen solo, Fable directing Qwen, and Fable solo. Keep the harness and permissions as similar as possible.
3. Repeat each condition. Five runs begins to expose variance; one run mostly exposes a story.
4. Equalize budgets. Same wall time, retry limit, context ceiling, and maximum human interventions.
5. Separate planner, builder, and judge. The judge should not know which model produced the result.
6. Automate the rubric. Assert server startup, zero console errors, throttle response, takeoff, pitch, roll, yaw, stall, crash reset, and stable frame rate.
7. Record orchestration overhead. Planner tokens, child-agent tokens, GPU time, elapsed time, retries, handoffs, and human minutes all count.
8. Score accepted results. A pretty scene with broken controls is a failed flight simulator, not a partial win hidden inside an average.

Primary metrics
- functional acceptance rate
- regressions introduced
- human interventions
- retries and context resets
- elapsed time
- API cost or GPU energy
- reviewer false-pass rate
- cost per accepted build

Copy-Ready Orchestrator Brief

ROLE
You are the planner and reviewer. Do not implement product code.

GOAL
Deliver [product outcome] through a separate builder agent.

WORK METHOD
1. Inspect the repository and write a short state summary.
2. Split the work into the smallest useful milestones.
3. For each milestone, define:
   - exact files or surfaces in scope
   - constraints and non-goals
   - acceptance checks
   - maximum retries: 2
4. Delegate only one milestone at a time.
5. Read the actual diff and test output after every handoff.
6. If a check fails, send one bounded repair request.
7. If the same failure repeats, stop and escalate to the human.

ROLE BOUNDARY
You may read files, diffs, logs, and test results.
You may not edit code, change permissions, deploy, or access secrets.

STATE
After each milestone, update STATE.md with:
- completed work
- evidence
- open defects
- decisions
- next milestone

DONE
Finish only when every acceptance check passes and the human approves.

The read-only role boundary is deliberate. If the orchestrator can silently repair code, you lose attribution, separation of duties, and a clean measure of the builder's performance. Create a separately authorized rescue agent when takeover is genuinely needed.

Production Checklist for a Traycer Pilot

• Start with a non-sensitive repository and a reversible task.
• Use a fresh Git worktree for every agent run; Traycer supports local, new, and existing worktree locations.
• Give the planner read-only access and the builder write access only to its worktree.
• Keep provider credentials outside prompts, transcripts, repositories, and shared artifacts.
• Confirm Privacy Mode, cloud-sync needs, analytics, and each provider's retention policy.
• Define timeout, retry, token, API-cost, and GPU-time ceilings before the run.
• Add deterministic tests and a browser verifier before asking an agent to call the task complete.
• Require human approval before merge, deployment, package publication, data migration, or external communication.
• Inject one failure: stop the local server, break a test, or reject a permission request. Verify that the workflow stops safely.
• Compare the accepted-result rate with your existing single-agent workflow after one week.

Video Chapters

Bottom Line

The orchestrated run is the better product. It also required a frontier planner, multiple review rounds, a fresh context handoff, human browser testing, local-server troubleshooting, and a tiny breach of the no-code orchestrator rule. Those costs do not erase the win. They explain it.

Traycer is interesting because it makes that work visible: durable agents, explicit lineage, provider switching, transcripts, worktrees, shared task state, and review. The next step is to replace the creator's intuition with an external test harness. When planner, builder, verifier, retry policy, and human approval each have a clear contract, a local 27B model can become a useful worker without pretending it is a frontier model by itself.

Sources and Further Reading

• Bijan Bowen: Fable 5 & Qwen 27B - Traycer Multi-Agent Hands-On Test
• Traycer official GitHub repository, README, releases, privacy summary, and MIT license
• Traycer: supported coding agents and model selection
• Traycer: agent-to-agent capabilities and limits
• Traycer: isolated Git worktrees
• Traycer: Host boundaries, live surfaces, and cross-device behavior
• Traycer: BYOA, sync, inference credits, and provider billing
• Qwen3.6 27B official model card, Apache 2.0 license, context, serving, and agent guidance
• Qwen: official Qwen3.6 27B release post