Vix
A multi-provider coding agent that uses programmable workflows and compact code views to reduce token use and task time.
Per-dimension scores and reasoning
The README claims sandboxed execution and identifies model providers, configuration locations, and the ANTHROPIC_API_KEY requirement; go.mod pins dependency versions, while LICENSE clearly states the license and copyright attribution. Deductions apply because the supplied files do not document default permissions, confirmation before commands or file edits, network and telemetry flows, credential safeguards, dependency scanning, external-effect controls, or recovery. Bash steps, self-written scheduled jobs, code editing, and a daemon can all create material effects, yet consent boundaries are unspecified. A PostHog dependency is present without disclosure of whether, when, or what telemetry is transmitted. No red-line behavior is demonstrated, but the safety controls cannot be established from this evidence.
Dependencies are recorded at specific versions, and the installation methods, daemon startup, and supported providers are described well enough for ordinary dependency-availability credit. Deductions apply because no failure-handling behavior or diagnostic-message examples are shown. There is also a scope inconsistency: scheduled jobs are advertised as a current self-evolving feature, while cron tasks remain on the roadmap. The benchmark candidly calls itself non-scientific and identifies one weaker task, but the supplied material contains no implementation or runtime evidence with which to assess operational reliability.
The product is clearly aimed at software developers and names concrete scenarios including greenfield work, bug fixing, refactoring, test coverage, and localization. It states the macOS/Linux restriction, daemon and API-key requirements, and support for several hosted and local providers. Deductions apply because capability boundaries remain mostly high-level, with no precise triggering rules for workflow phases, branches, parallel steps, tools, or self-evolving tasks. Windows support, offline behavior, resource requirements, and provider-specific constraints are also incomplete.
The README has a useful structure covering features, benchmarks, installation, configuration, design rationale, philosophy, and roadmap. Names such as vix, vixd, providers.json, and settings.json are used consistently, and the installation commands and platform warning are clear. The complete AGPL-3.0 text justifies full license credit. Deductions apply for the absence of an FAQ, complete workflow examples, troubleshooting guidance, a changelog, and an explicit compatibility policy; settings.json documentation is described as forthcoming. The repository organization, Discord, and releases offer a limited maintenance path, but no responsible maintainer, support commitment, or security-reporting route is identified, and publisher identity remains unknown as stipulated.
Stem Agents, a Tree-sitter virtual filesystem, and programmable multi-phase workflows present concrete differentiation from a generic coding agent. The seven-task cost and time table offers useful cost-benefit evidence, and the authors disclose the informal methodology and an unfavorable result. Deductions apply because the supplied files do not show representative generated outputs, a complete interaction example, or a quality-acceptance method. Claims of zero meaning loss and comparable quality are not adequately substantiated here, and the benchmark is small and self-reported.
The README points individual benchmark tasks and plan results to specific artifacts and distinguishes several observations, personal judgments, and future plans. go.mod, LICENSE, and README also corroborate the module identity, dependencies, and license. Deductions apply because the linked evaluation materials, implementation, tests, transcripts, and release history are not included in the supplied evidence, leaving most feature and performance claims supported principally by repository assertions. The phrases “benchmark-backed” and “zero loss of meaning” are stronger than the README's later admission that the evaluation is non-scientific and lacks a meaningful quantitative quality measure.
- The installation command pipes a remote script directly into a shell; download and inspect a revision-pinned script and its payload sources before use.
- Before exposing private code, verify the actual data flows, telemetry defaults, retention policies, and opt-out controls for every model provider and PostHog.
- Test bash execution, code edits, daemon behavior, and self-generated jobs in an isolated repository, confirming per-action consent and a version-control or equivalent rollback path.
- Do not treat the seven self-reported plan-mode benchmarks as independent evidence of implementation quality, safety, or performance across broader workloads.
- AGPL-3.0 can create source-availability obligations for network deployment of modified versions; assess compliance before adoption.
What does this agent do, and when should you use it?
Vix is an AI coding agent for macOS and Linux, delivered as a vixd background daemon with isolated vix CLI instances. It explores repositories, develops plans, and executes coding work through configurable multi-phase pipelines containing agent, bash, and tool steps, with templating, branching, parallelism, and history forking. Its Tree-sitter virtual filesystem presents minified code to the model, which the project says cuts token usage by 20–50%, while stem agents preserve cache reuse between phases. The product also includes whiteboard planning with a voice walkthrough, skills, subagents, MCP servers, LSP-backed code intelligence, and sandboxed execution. Built-in providers include Anthropic, OpenAI, OpenRouter, OrcaRouter, AWS Bedrock, Ollama, and llama.cpp, with provider overrides supplied through providers.json. It is a plausible fit for teams that want a self-hosted command-line agent with workflow control and provider choice, but it lacks Windows support and its speed and cost claims come from a seven-task, explicitly non-scientific plan-mode evaluation.
After vixd is started, users launch one or more isolated vix instances. Vix reads project files and uses a Tree-sitter virtual filesystem to expose compact code representations to the model, while its LSP integration supplies code intelligence. A task can run as a JSON-defined pipeline of agent, bash, and tool steps with templates, branches, parallel execution, and conversation-history forks. Its stem agent keeps one generic conversation across exploration, planning, and execution, then uses “agent specialization” to assign the next phase, increasing prompt-cache reuse. Execution can run sandboxed commands, call configured model providers, use MCP servers or subagents, and read or modify code. Whiteboard Mode presents the plan on a visual canvas with a voice AI walkthrough so the user can challenge it before proceeding.
- A developer starting a feature from scratch can have Vix explore the repository, produce a phased implementation plan, and proceed to execution.
- A team maintaining a large codebase can use the Tree-sitter compact view and LSP-backed intelligence for cross-file investigation and edits.
- An engineer refactoring under an existing test suite can organize exploration, planning, shell commands, and code changes into a programmable workflow.
- A maintainer addressing a compiler error or defect can use the agent to inspect code and logs, run shell steps, and implement a correction.
- A team mixing hosted and local models can configure Anthropic, OpenAI, Bedrock, Ollama, llama.cpp, or the other documented providers.
- A technical lead who wants review before execution can inspect the proposed approach in Whiteboard Mode and challenge its voice-guided walkthrough.
What are this agent's strengths and limitations?
- Stem agents reuse conversation cache across phases such as exploration and planning, directly targeting duplicated context cost.
- The Tree-sitter virtual filesystem gives models a minified code view; the project reports token reductions of 20–50%.
- JSON workflows offer concrete orchestration features: agent, bash, and tool steps plus templates, branches, parallelism, and history forks.
- Built-in support spans Anthropic, OpenAI, OpenRouter, OrcaRouter, AWS Bedrock, Ollama, and llama.cpp, covering hosted and local model paths.
- The feature set combines LSP code intelligence, sandboxed execution, MCP, skills, subagents, and a visual review surface for plans.
- Only macOS and Linux are supported at present, leaving Windows users without a documented installation path.
- The quick-start path explicitly requires ANTHROPIC_API_KEY, and hosted providers introduce external API availability and usage costs.
- The comparison covers only seven coding scenarios and is explicitly described by the authors as non-scientific, so it is not a general performance guarantee.
- Vix was slightly slower and more expensive than Claude Code on the third benchmark; the project attributes this to a file exceeding 3,000 lines and regular read/edit tools being used during execution.
- Cron tasks and a full “project brain” remain roadmap items and should not be treated as available features.
- The supplied material does not document Windows support, a complete permission model, or production failure-recovery procedures.
How do you install or deploy this agent?
Vix currently supports macOS and Linux only. Install it with:
curl -fsSL https://getvix.dev/install.sh | bashAlternatively, use Homebrew:
brew tap get-vix/vix
brew install vixThe installation section requires ANTHROPIC_API_KEY to be defined in the environment. Credential instructions for the other built-in providers are not included in the supplied installation excerpt.
How do you use this agent?
Start the daemon first:
vixd
Then launch an isolated agent instance in the project environment:
vix
Additional vix instances can be started and are described as isolated from one another. Provider settings can be placed in ~/.vix/providers.json for user-level configuration or ./.vix/providers.json for a project; entries are merged over embedded defaults, appending new providers and patching existing ones by field. Custom multi-phase workflows are defined in JSON and may contain agent, bash, and tool steps, although the supplied material does not include a complete copyable workflow definition.
How does this agent compare with similar options?
The project compares Vix plan mode with Claude Code on seven tasks using the same prompts and identifies Claude Opus 4.6 as the model. Its table reports totals of $6.64 and 38m30s for Vix versus $12.44 and 64m6s for Claude Code; Vix was slightly slower and more expensive on the third, long-file task. The authors explicitly call the exercise non-scientific and say plan quality appeared similar but was difficult to quantify reliably. The stated architectural distinction is that Vix uses a stem agent to preserve cache across exploration and planning and a Tree-sitter virtual filesystem to provide minified code, instead of relying on multiple exploration agents.