| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| harnesses [2026/04/09 15:43] – [Zed Agent] xenolandscapes | harnesses [2026/04/11 15:13] (current) – beeg brane amolith |
|---|
| ====== Harnesses ====== | ====== Harnesses ====== |
| |
| ==== Claude Code ==== | <WRAP tip center> |
| | We have a [[:skill|self-updating agent skill]] that will tell an agent how to reference the Synthetic docs, this wiki, and how to use the Synthetic API. |
| <WRAP center round alert 60%> | |
| It is highly recommended **not** to use Claude Code as a coding harness with Synthetic due to excessive token bloat caused by its poor infrastructure. | |
| </WRAP> | </WRAP> |
| |
| Claude Code, from Anthropic, is perhaps the most popular agentic coding harness currently. However, it is not really designed to be used with anything other than Anthropic's own Claude subscriptions. | {{namespace>harnesses}} |
| | |
| To use Claude Code with Synthetic, you will need to use something like [[https://musistudio.github.io/claude-code-router/|Claude Code Router]], a custom script, or a tool provided by the community, as described [[https://dev.synthetic.new/docs/guides/claude-code|here in the official documentation]]. | |
| | |
| * **Pros**: Very popular, actively maintained by a large team at Anthropic. Has many advanced features such as [[https://code.claude.com/docs/en/agent-teams|Agent Teams]] and [[https://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode|auto permissions mode]]. | |
| | |
| * **Cons**: Very poorly vibe-coded: updates often break things; TUI is slow, flickers a lot, and does not support terminal scrollback; extreme token bloat in the system prompts, tool prompts, and feedback to the models; extreme request bloat, in terms of making a lot of requests with the various models you've specified as haiku/sonnet/opus alternatives. Requires custom scripts or wrappers to work with anything but Anthropic's API. | |
| | |
| ==== Pi ==== | |
| | |
| The [[https://pi.dev/|Pi agent]] is minimal, lightweight, and extremely opinionated. It prioritizes an extremely polished and reliable implementation of the absolute basics of an agent harness over any more advanced features, and ruthlessly eschews features that are just popular in favor of a specific design philosophy ([[https://mariozechner.at/posts/2025-11-30-pi-coding-agent/|source]]). Whether this works for you, as a result, will be highly hit-or-miss. | |
| | |
| However, Pi is also extremely extensible — moreso than basically any other polished, ready to use out of the box agentic harness. For instance, [[https://lucumr.pocoo.org/2026/1/31/pi/|it is the agent at the core of OpenClaw]], which is much more featurful and complex, and extension collections/frameworks like [[https://github.com/can1357/oh-my-pi?tab=readme-ov-file#highlights|Oh My Pi]], which extends it to be perhaps the //most// powerful agent harness. Additionally, extending Pi is extremely easy — models running in Pi have immediate access to the full Pi documentation and source code, and extending it is as simple as dropping a TypeScript file in a specific directory, and the codebase is designed to be easily hooked-into and overridden. | |
| | |
| To use with Synthetic, you can follow the [[https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/models.md|Custom Model instructions]] using the information from [[https://dev.synthetic.new/docs/api/overview|the Synthetic developer docs]]. | |
| | |
| * **Pros**: Extremely extensible. Self-documenting and self-extending. Very polished and reliable implementation (e.g., flicker-free, extremely fast, and scrollback-supporting TUI, or seamless provider switching within one session). Small and fast. Has powerful extension collections. Very popular. Minimal request and token usage by default. Very transparent introspection into what the harness is using from your provider. | |
| | |
| * **Cons**: The default experience is very barebones, and opinionated. It might be useless for you, or the opinions might rub you the wrong way. As always with adding features to something minimal via extensions, this adds yak shaving potential, possible instability, the possibility of overcomplicated, buggy, overbearing additions being the only options besides extending it yourself — in general, the NeoVim or Emacs experience. | |
| | |
| ==== Zed Agent ==== | |
| | |
| The Zed Agent is the built-in agentic harness integrated with the Zed editor — not to be confused with the agents Zed has the capability to use through the [[https://zed.dev/acp|Agent Client Protocol]]. | |
| | |
| To configure use of Synthetic with Zed, you can configure it as an ''OpenAI API Compatible'' Provider ([[https://zed.dev/docs/ai/llm-providers#openai-api-compatible|source]]) in "~/.config/zed/settings.json" using the information from [[https://dev.synthetic.new/docs/api/overview|the Synthetic developer docs]]. You'll then have to set your API Key either in the agent sidebar > three dots > Settings > Synthetic > API key, or as an environment variable. (The former is recommended, so you don't run into strange env issues). | |
| | |
| * **Pros**: | |
| * [[https://zed.dev/blog/crdts|CRDT]] based collaborative editing with the agent means that you can: edit files at the same time it edits them, or before you've accepted/rejected proposed changes from the agent; edit a file while the agent is in the process of editing it to propose changes; see the agent's proposed changes in-line in the actual buffer you'd use to edit the file, instead of in a separate interface; and accept and reject proposed changes by hunk without confusing the model. | |
| * [[https://zed.dev/docs/multibuffers|Multibuffer support]] means that when you look at the unified (live updating) view of all of your agent's proposed changes as it makes them, you can actually edit that collected buffer. | |
| * Zed [[https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-operation-level-version-control|DeltaDB]] also allows agent suggested edits to not have to be accepted or rejected before it can move on to the next turn of reading source code and editing, meaning that you are not forced to accept all changes in one diff just to see where the agent is going, allowing you to let the agent build up a "stack" of changes for a complete feature on autopilot, without actually finally accepting those edits; and allowing the agent to iteratively //refine proposed changes// by writing the change, then looking at the resulting file with its changes in it — although you haven't permanently accepted them yet — seeing problems, and iterating again. | |
| * Agent proposed edits are //actually in the file//, DeltaDB just records the information needed to perfectly revert those changes at the text edit operation level if you reject the changes, meaning that LSP diagnostics, compilation, benchmarks, test suites, fuzzing and son on can be run on an agent's proposed changes all before accepting the agent's changes. In fact, the Zed system prompt encourages the agent to run its LSP diagnostic tool on its edits after making them before they are accepted, feeding into the iterative process. | |
| * Zed uses a custom "intent to edit file with goal" tool call, and then runs a separate request with the same chat history and model to actually generate the code, and live-generates the diff from the agent's search and replacement code, so that you can see the agent moving around and editing the file in real time, token-by-token. | |
| * Zed allows you to "follow" agents, so you can watch which files they're currently reading, searching in, or editing. | |
| | |
| * **Cons**: In-file live diff generation is laggy. The Zed Agent has subagents, but they're forced to use the same model as the parent thread. The Zed Agent doesn't currently have a todo list tool (although that is on the HEAD branch). It also doesn't have Claude Code style templated slash commands or Agent Skills. Additionally, the "intent to edit" system means you'll use 2x the input tokens and 2x the requests for edits. | |