# traycer orchestrates other coding agents, and downloads the half that actually runs them

> A private TypeScript monorepo for a desktop orchestration app that drives coding agents you already subscribe to. The interesting part is the split: the clients are in the repository, the agent runtime and cloud backend are not, and the developer loop downloads the runtime from a release channel instead of building it.

**traycerai/traycer** — Traycer: Nerve Center for Agentic Coding

- Repository: https://github.com/traycerai/traycer
- Website: https://traycer.ai
- Stars: 1,627 · Forks: 212
- Language: TypeScript
- License: MIT
- Published: 2026-08-26 · Updated: 2026-08-26 · Language: en
- Canonical page: https://hysenlabs.com/projects/traycerai-traycer

## The clients are in this repository and the runtime is a downloaded release

The Makefile is explicit about what a contributor is working on. Its developer stack comment says the dev shell runs against production with the Traycer Host downloaded from GitHub Releases, and that the Traycer Host and the cloud backend are not part of this repository: the CLI provisions the real signed host release and the clients talk to the production cloud. Four targets implement that, and they are the only commands a newcomer needs:

```make
make dev-desktop                 # download + run against the LATEST host
make dev-desktop VERSION=1.2.3   # pin a specific host release
make host-stop                   # stop the dev host (leaves it installed)
make host-clean                  # deregister + remove the dev host
```

So the artifact that executes agent work is fetched, signed and verified rather than compiled from the checkout. The verification anchor is a signing public key committed in clients/traycer-cli/src/config.ts, which is why the comment says no key setup is needed. The downloaded host installs into an isolated slot at ~/.traycer/host/dev under the service label ai.traycer.host.dev, so a dev run never touches a production install, and Ctrl-C deregisters it while leaving ~/.traycer user data, credentials and config in place. host-stop leaves the host installed and host-clean removes it, which is the difference that matters when a dev host misbehaves.

## The default target takes whatever host release is newest

The recipe behind the first target is one line, and the version handling is conditional:

```make
dev-desktop:
	@bun run dev-desktop -- $(if $(strip $(VERSION)),--release $(VERSION),) $(ARGS)
```

With VERSION set, the flag reaches the CLI and it installs that host release. With VERSION empty, the shell function expands to nothing at all, no release flag is passed, and the comment above the target says the download then resolves to the latest host. That means the default developer experience couples your checkout to whatever was most recently uploaded, with no record in the repository of which version ran. Since the host is where agent execution happens, a behavior change can arrive between two runs of an unchanged working tree. The rest of the file fixes the toolchain expectations just as plainly: SHELL is set to /bin/bash, CLI is defined as bun clients/traycer-cli/src/index.ts, and the root manifest reaches the same script through bun scripts/dev-desktop.js. So the local stack is bun plus bash plus make, and a contributor without bun gets nothing from these targets at all.

## A private manifest at version 0.0.0 under three tags numbered 1.4.2

The root package.json declares the name traycer, the version 0.0.0 and private true, with two workspaces, protocol and clients/*. A version of 0.0.0 in a private root is a placeholder rather than a shipped number, so the manifest cannot answer what version anybody is running. The release tags do, and they answer three times over. The three most recent are cli-v1.4.2 at 00:10:37 on 2026-10-01, host-v1.4.2 at 00:40:55 on the same day and desktop-v1.4.2 at 00:40:56, one second apart. The last recorded push to the default branch is 2026-10-02, the day after all three tags. Three artifacts therefore carry the same 1.4.2 number in three separate tag namespaces, on three timelines, and the root manifest reflects none of them. A team pinning dependencies has to pick a namespace rather than a version: a desktop build at 1.4.2 says nothing about which host or CLI it expects, and nothing visible in the repository states the compatibility matrix that would tie the three together.

## The default build target skips the app it ships

Two nx scripts look almost identical and differ in one place:

```json
"build": "nx run-many --target=build --all --exclude=@traycer-clients/desktop --parallel=${NX_COMPILE_PARALLEL:-3} --tui=false"
```

The compile target has no exclusion, so compile covers every project while build deliberately leaves out the desktop client. Since the desktop client is the thing behind the six download rows in the README, the repository's own build command does not produce it, and the parallel fan-out is capped at three with a tui disabled so it can run in CI. The other scripts follow the same shape: lint and test both fan out across all projects, test:affected narrows to the nx affected set against HEAD, and test:project runs the target in the current project only. Formatting is separate again, with oxfmt for both format and format:check and the tui-free convention kept throughout. The practical consequence is that a green bun run build and test tells a contributor nothing about the desktop app; only the dev-desktop path and whatever release pipeline sits outside this repository exercise it.

## Six download rows, unversioned URLs, and no Linux arm64

The install table gives one row per platform and every row points at the same moving target, the releases/latest/download path: traycer-desktop-macos-arm64.dmg, traycer-desktop-macos-x64.dmg, traycer-desktop-linux-x86_64.AppImage, traycer-desktop-linux-amd64.deb, traycer-desktop-linux-x86_64.rpm and traycer-desktop-windows-x64.exe. The link text never changes and the bytes always do, so a saved link re-resolves to a newer build, and the table carries no checksum, no signature line and no version in any row. The platform coverage is also uneven in a way the naming makes visible: macOS gets both arm64 and x64, while Linux gets x86_64 for the AppImage and rpm and amd64 for the deb, so an arm64 Linux machine has no row at all. None of these rows is about the CLI or the Host, even though each release tags all three artifacts, which means the two components a contributor actually installs locally are documented somewhere other than the table a new user reads first.

## Twenty-one connectable agents and twenty-one missing setup commands

The Bring Your Own Agent table lists twenty-one names in seven rows of three: Claude Code, Codex, Cursor, OpenCode, Traycer, Grok, GitHub Copilot, Devin, Amp, Droid, Kiro, Kilo Code, Kimi, Qwen Code, OpenRouter, Pi, Hermes Agent, Hugging Face, Oh My Pi, Reasonix and Antigravity. Each cell is a link out, most of them to a vendor home page rather than to an integration, and not one row says what Traycer does with that agent. The setup commands and provider specific configuration are pushed to a documentation site. The list even includes Traycer itself among the agents it connects to, alongside gateways and model hosts rather than only editors. The two feature claims that rest on those connections are stated without numbers: Unified Context says a user can switch to another model inside the same agent with the context window shared across all providers, with no window size and no statement of what happens to provider side tool state, and the agent-to-agent bullet hedges itself by saying that referencing every agent is one capability while reading a transcript and delivering a message are narrower and depend on the user, the Host and the runtime.

## A lint stack decided by a catalog and a nightly TypeScript

The manifest splits its lint and format tooling unusually. Several devDependencies are not versions at all but the token catalog:, including @eslint/js, the typescript eslint plugin and parser, globals, esbuild, oxfmt and most of the react plugin family, which means the effective version of the lint stack is resolved somewhere outside this repository. Two entries are pinned hard: @typescript/native-preview at 7.0.0-dev.20260707.2, a dated nightly that puts a pre-release compiler in the toolchain, and eslint-plugin-oxlint at 1.80.0. TypeScript itself sits in dependencies rather than devDependencies at ^6.0.3, while typescript is also the language the project is written in, so the compiler version is a runtime contract as well as a build input. Alongside the manifest the tree carries .oxfmtrc.json for the formatter, .prettierignore, a separate eslint/ directory, .pre-commit-config.yaml, .gitleaks.toml for secret scanning and a patches/ directory for dependency patches. Two formatting configurations and a catalog-driven lint stack make the local gate reproducible only as long as the catalog stays put.

## Prompt logging is off only where the plan says so

The privacy section makes two promises and then qualifies both. Code is processed in memory and never stored or used for training, and requests for the CLI providers a user configures go directly to that provider, while Traycer's own inference is served by Traycer. Then comes the condition that decides how much the first promise is worth: Privacy Mode is on by default for Team plans and opt in for individuals, and with it off prompts may be logged to help improve the Services. The default for a solo user on an individual plan is therefore the state where logging is permitted. Switching to Traycer's own inference subscription also moves requests off the direct path, since that traffic is served by Traycer rather than by the provider the user configured. Two telemetry destinations are named as well, Sentry for crash reporting and PostHog for analytics, both described as possibly enabled in release builds. The claims that hold regardless of plan are the in-memory handling and the provider-direct routing; the claim that needs a setting turned on by hand is the no-logging one.

## Conclusion

Traycer is worth evaluating for a team that already pays for several coding agents and wants one place to run them in parallel, but it is an orchestration client, not the engine. Two facts decide whether it fits: the runtime you test against is whatever the latest signed Host release happens to be, and Privacy Mode, the setting that governs prompt logging, is on by default only for Team plans. Anyone on an individual plan has to turn it on before handing a repository to it. Pin a host version in the dev loop rather than taking the newest, read what the installer for the CLI providers writes locally, and treat the twenty-one agent names in the table as a promise to verify, since the repository documents the setup for none of them.

## FAQ

### traycer vs cursor

Traycer's own overview does not make the comparison. Cursor appears in the Bring Your Own Agent table as one of the coding agents Traycer connects to, alongside Claude Code, Codex, GitHub Copilot, Devin and Amp. What Traycer claims for itself is parallel agents over shared context, agent-to-agent communication, shareable boards with ticket assignment, and the same agent state on any device.

### traycer vs claude code

Claude Code is the first entry in the Bring Your Own Agent table, and Traycer describes that relationship as connecting agents you already pay for instead of locking you into one ecosystem, with Traycer's own inference subscription offered as the alternative. Traycer's stated additions are instant model switching inside one agent, shared context across providers, agent-to-agent loops and team boards.

### What is traycer, in its own terms?

Traycer describes itself as an open source AI orchestration app. It connects coding agents you already subscribe to, runs multiple agents in parallel without losing context, shares memory across models and providers, lets one agent reference another, and adds boards, real-time editing, ticket assignment and cross-device state. A native Traycer inference subscription is offered in place of a provider subscription.

### How do I install traycer, and what do the download rows give me?

Six rows cover macOS arm64 and x64 as dmg, Linux AppImage, Debian and Ubuntu deb, Fedora and RHEL rpm, and Windows x64 exe. Every row points at the releases/latest/download path instead of a versioned file, no row carries a checksum, and no Linux arm64 build is listed. Each release also tags a CLI and a Host artifact that the table does not cover.

### What is in the traycer repository and what is not?

The repository is a private bun workspace holding protocol/ and clients/*, the desktop client and the CLI. The Makefile states that the Traycer Host and the cloud backend are not part of it: the dev target downloads a signed host release from GitHub Releases, verified against a public key committed in clients/traycer-cli/src/config.ts, and the clients talk to the production cloud.

### Does traycer store my code or train on it?

The README says code is processed in memory, never stored and never used for training, and that requests for CLI providers you configure go directly to that provider. Privacy Mode is on by default for Team plans and opt in for individuals, and with it off prompts may be logged. Crash reporting through Sentry and analytics through PostHog may be enabled in release builds.

## Sources

- [Official documentation](https://traycer.ai)
- [Official README](https://github.com/traycerai/traycer#readme)
- [Project repository](https://github.com/traycerai/traycer)
- [Release notes](https://github.com/traycerai/traycer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/traycerai-traycer