Refact.ai vs Tabby (2026)

Acts across GitHub, GitLab, PostgreSQL, MySQL, Docker, shell, the Python debugger, browser tools, MCP servers and CI/CD.

Tabby has a real integration surface for ingesting context and serving suggestions, including GitLab SSO and self-hosted GitHub and GitLab integrations, but it does not call tools to act on the customer's systems: no MCP client, tool-calling loop, source control write path or CI action is documented. That is an architectural property of an assistant-first product.

Plans, edits, tests and iterates up to thirty actions per task with planning and debugging sub-agents, from prompt to pull request.

The Agent promoted on the homepage was announced as a private preview waitlist on 25 May 2025, and no shipped agent capability is documented. The planning and executing teammate TabbyML now markets is Pochi, a separate cloud product.

A durable per-project cron scheduler fires tasks into the agent, alongside five IDE plugins, a CLI, a TUI and a browser GUI.

Five editor families plus a web interface is real breadth of surface. What holds it short of Full: every path is developer-initiated inside an editor or the web app, with no event trigger, no schedule and no inbound channel; background jobs for indexing are internal maintenance rather than agent invocation.

A local engine keeps AST and vector indexes of the codebase current and exposes symbol and semantic search to the agent.

A persistent repository index with embeddings, re-indexed in the background and extended to multiple branches, is a maintained retrieval structure over the customer's code.

Typed task memories and a knowledge graph with staleness tracking persist per project in the .refact directory, with a cleanup pass.

Persistent shareable Pages and shared threads are durable state that persists across sessions and across a team. They are a knowledge artifact the customer creates deliberately, though, with no mechanism by which the assistant carries learned context, preferences or corrections into later interactions, and no per-user or per-repository memory.

Confirm rules pause the agent for approve or reject on destructive tools, shell and integrations carry allow, ask and deny rules, and tasks cap at thirty actions.

Oversight here is structural rather than mechanical: every output is a suggestion the developer accepts or rejects, and there is no autonomous action to gate. What holds it short of Full: no shipped approval or guardrail mechanism is documented, because none is needed for a product that only proposes.

File and project restriction and zero-telemetry self-hosting, but no attestation, SSO, SAML or organization-level roles.

Two named authentication mechanisms, LDAP directory authentication and generic OAuth (new in v0.32.0), plus an admin dashboard for user accounts and per-developer API tokens. What holds it short of Full: no certification of any kind is documented, and the posture rests on self-hosting, which counts toward Deployment.

Chat trajectories and tool runs persist locally and patches are inspectable, but there is no team audit log or run analytics.

Usage analytics and background job notifications are real operational visibility, and shared threads plus persistent Pages give a durable record of Answer Engine work. What holds it short of Full: none of it traces agent execution, and there is no agent to trace.

Open source and local-first, running on the customer's machine or servers with zero telemetry; hosted Refact Cloud is being retired.

The product is only self-hosted: there is no managed path, no region question and no vendor-side inference. The self-contained design with no external database is what makes it operable offline.

An extensions marketplace installs skills, commands and subagents from bundled and GitHub sources.

Context Providers and the model registry are configuration surfaces rather than adoptable assets: a customer points them at their own documentation and repositories, and there is no vendor-supplied catalog to browse. The registry-tabby repository is a model registry rather than an agent or template library, and it has not been updated since May 2025.

Runs only on the customer's own keys across seven named providers or local runtimes such as Ollama, LM Studio and vLLM.

Two forms of control are present: the customer chooses the model at launch through a serve flag and can pair a different chat model with the completion model, and the model set spans multiple open families plus commercial APIs through Codestral and Mistral embeddings. Because the whole server is self-hosted, model choice is unconstrained by the vendor. The limit: the named default models are an older generation and no per-task routing gateway exists.

The local engine exposes a documented v1 HTTP API that the IDE plugins and GUI use, and configured MCP servers extend the agent.

An OpenAPI-documented REST interface plus a documented path for adding custom documentation over REST is a real extensibility surface, and Apache 2.0 means the whole server can be forked and extended. What holds it short of Full: the direction is inward and narrow. The API serves completion, chat and answers to clients, with no SDK, no MCP server exposing Tabby to other agents, and no webhook surface.

Runs the project's tests and a debugging sub-agent to check its own work; no customer-facing evaluation harness.

Tabby is explicitly a completion, answers and chat product; auto-generated commit messages are the only generation beyond code itself, and there is no agent loop that could run or verify tests.

A built-in Chrome tool lets the agent launch, navigate and interact with pages, extract data and take screenshots.

Everything documented is programmatic: completions, answers and chat over REST, editor plugins and repository indexing. The vercel-labs/agent-browser fork in the TabbyML GitHub organization is unconnected to any documented Tabby capability and sits with the separate Pochi line.