Factory AI

What Is Factory AI?

Factory is a software-development platform whose agents, called Droids, can inspect a repository, propose a plan, change files, run checks and prepare a pull request, the reviewable package of changes you merge into your codebase. You use them through a terminal, an integrated development environment (IDE), or Factory's desktop and web surfaces. “Agent-native development” means assigning an outcome and reviewing the resulting work, rather than requesting each individual edit. The product is a layer around models and development tools, not a new programming language or a model you train yourself. Factory's product page describes that scope.

Verified on October 21, 2026, against Factory's live pricing and documentation. This is a documentation-based evaluation with worked examples and computed costs; no coding benchmark or hands-on trial is claimed.

Who Should Use Factory, and Who Should Keep Their Current Agent?

Factory fits an engineering lead who wants a consistent delegation process across developers who use different editors, or who wants to change model providers without rebuilding every workflow. It is less compelling for a founder whose existing agent already handles the repository, tests and review process with little supervision.

The shortlist is Anthropic Claude Code, Anthropic's development agent; OpenAI Codex, OpenAI's coding agent; and Cursor, an editor and agent platform. The useful comparison is the operating change each purchase makes.

These are buying judgments, not benchmark rankings. Claude Code, Codex and Cursor already extend beyond a single chat box or terminal. Factory does not win merely by having multiple interfaces.

Factory AI vs Claude Code

Factory is worth considering when you want Claude models to be one option inside a broader workflow. Claude Code is the simpler choice when your organization already has useful instructions, integrations and review practices around it. Running a Claude model inside Droid does not reproduce Claude Code: the surrounding tools, context selection and execution behavior belong to the agent product.

For example, a lead with backend developers in JetBrains and frontend developers in Cursor could introduce Factory for one shared maintenance queue. That is a coherent reason to add it. Asking everyone to switch because a different model produced an impressive demo is not.

Skip Factory for now if your main problem is vague requirements, unreliable tests or a pull-request queue nobody reviews. Those problems also constrain Droids. Keep Claude Code, Codex or Cursor while you make work easier to verify. The Codex vs Claude Code comparison covers that narrower choice; the AI coding-agent shortlist covers the broader field.

The evaluation below turns on four criteria: context quality, control over execution, continuity between interfaces, and the cost of getting a change accepted.

Factory AI Droid: Keep Your Editor, Make the Work Explicit

Factory Droid can work inside an existing editor, which makes a small pilot possible without an editor migration. In VS Code, Cursor and Windsurf, the integration supplies the active file, selected text, open files and diagnostics, the editor's error and warning messages. It also supports native diff viewing. Run droid in the integrated terminal, then use /ide to inspect the connection. Factory's IDE documentation explains the setup.

Imagine a backend lead changing how an application validates account permissions. The useful task is not “refactor auth.” It is: identify every call site, preserve the existing behavior for current users, propose the migration sequence, and identify the tests that would catch an accidental privilege change.

That description gives the agent a boundary and gives the reviewer something to reject. A large diff alone cannot show that the migration is correct.

What Does Factory AI Do With a Spec?

Factory's Spec Mode separates investigation and planning from implementation. It reads relevant context and proposes a plan before asking for approval; in the CLI, Shift+Tab switches between Normal and Spec modes. Autonomy level is a separate setting that determines which actions can proceed without another confirmation. The mode documentation makes this distinction explicit.

For the permissions migration, start in Spec Mode and require the plan to name affected files, compatibility assumptions and verification steps. Reject a plan that proposes changing access rules without explaining how existing behavior will be preserved. Approve implementation only after those decisions are clear.

A practical sequence is:

1. Ask Droid to locate the authorization entry points and relevant tests.
2. Request a plan that preserves current behavior and identifies any uncertain requirements.
3. Review the plan, then choose an autonomy level suited to the permitted work.
4. Inspect the diff and test evidence before opening or accepting the pull request.

The benefit is a review checkpoint before the agent creates a large amount of code. The limitation is that a plausible plan can still be wrong. Your acceptance criteria must include behavior, not just the presence of tests.

There is also an editor-specific catch: Factory documents that its JetBrains integration does not automatically share open files, selections, diagnostics or native Droid diffs. A mixed-editor rollout must account for that difference rather than assuming the VS Code experience applies everywhere.

Model Choice Without Rebuilding the Workflow

Factory lets you choose among model families while keeping the Droid interface and task structure. That is useful when a team wants a consistent way to delegate work but does not want every workflow tied to one model provider.

The live Factory model catalog lists, among others:

• Anthropic Claude Opus 5.5 and Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol and GPT-6 Astra.
• Google Gemini 3.1 Pro and xAI Grok 4.7.
• Open models including Mistral Large 4, Kimi K3 and DeepSeek V4.1 Flash.

This is a sample of supported models, not a quality ranking or a promise that every account's policy permits every model.

Consider a queue of dependency updates. Give each candidate the same dependency change, test instructions and definition of done. Record whether it completes the update, whether checks pass, and how much reviewer intervention it needs. A model that needs less supervision may justify higher consumption; a cheaper model that repeatedly leaves broken tests may not.

The comparison should hold the task and environment constant. Changing the model, repository instructions and autonomy setting together makes the result impossible to interpret. Factory's catalog includes different usage multipliers and reasoning settings, so “the same number of prompts” is not a reliable consumption comparison.

Bring your own key (BYOK) means configuring your own model-provider credentials or compatible endpoint. Factory supports personal custom models, including local configurations, but its BYOK documentation places an important limit on portability: those personal models are available in the CLI and desktop app, not the hosted web or mobile interfaces.

The buying implication is specific. Factory can reduce the effort of changing models inside a workflow, but you still need to check that the intended model is available on the interface where the work will run. A local-model pilot does not automatically prove the web delegation path.

Desktop and Web Make Delegated Work Reviewable

Factory's desktop app is useful when the output needs visual inspection alongside the conversation. Its product page lists code diffs, documents, presentations, spreadsheets, PDFs and live websites as previewable outputs, plus comments attached to code lines or selected elements. It is available for macOS and Windows. Factory Desktop also describes session continuity across desktop, web, mobile and CLI.

For a technical founder changing an account settings page, the workflow is straightforward: describe the behavior, inspect the rendered result, attach feedback to the relevant element, and review the code changes before release. Visual feedback helps localize a request such as “this error belongs beside the email field.” It does not establish that the server rejects an invalid update or that another user's settings remain inaccessible.

That distinction matters for delegation. The person approving the interface and the person checking application behavior may be different. Ask for both the visible change and the evidence that the underlying behavior works. A convincing preview should not be the only completion criterion.

Factory also lists connectors for tools such as GitHub, Linear, Slack and Sentry. These can supply approved context, but connecting a tracker does not make an ambiguous ticket precise. The task still needs an owner, a scope and a clear result.

Remote execution introduces a second distinction: the interface where you review work is not the computer running it. Factory-managed Droid Computers are persistent environments that retain files, installed packages, services and configuration across sessions. Factory documents a separate Remote Control option for a machine you already manage. Droid Computers documentation describes both.

Persistence is helpful when setup is expensive. It also means environment state needs an owner. Factory explicitly says that rebuilding an Environment does not update a Droid Computer previously created from its snapshot. A platform lead should therefore verify the machine's state before treating a successful run as reproducible elsewhere.

An AI Software Factory Starts With One Repeatable Job

Factory becomes more interesting when Droid handles a defined queue of work without a developer manually starting every conversation. Droid Exec is its headless mode: a noninteractive command that runs a task and returns output for a script or continuous integration (CI) system. It defaults to read-only behavior; edits and broader commands require explicit autonomy settings. The Exec documentation covers output formats, working directories and isolated Git worktrees.

A good first workflow is a repository analysis that produces evidence a maintainer can check. After installing and authenticating Droid, run this from a repository:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

This is an example invocation, not a run performed for this review. It does not prove coverage by itself: dynamic calls, integration tests and generated code can make a simple conclusion wrong. Its output is a candidate work list for the maintainer.

The next step is to let Droid implement an approved, bounded test change on a separate branch or worktree, then run the repository's checks. Keep the acceptance check outside the agent's own prose. Your CI result and reviewer decision should determine completion.

A subtle automation wall is easy to miss: an effective command-policy ask still requires approval at High autonomy, and a one-shot job cannot collect an interactive approval. Raising autonomy therefore does not necessarily make a blocked automation run. Factory documents droid rules check for previewing policy decisions before execution. This is a configuration problem to resolve deliberately, not a reason to disable every permission check.

For larger work, Mission Mode coordinates workers and validation. It requires High autonomy or the documented unsafe override, and individual-plan Missions can pause at rate limits. Start with ordinary scoped tasks before promising unattended completion of a large migration.

The payoff is repeatability: the same intake, permission boundary and evidence package each time. The wall is operational ownership. Someone must maintain dependencies, credentials, task scope and failure handling. The software-factory platform comparison is the next decision if that operating layer matters more than the individual coding session.

Factory AI Pricing: Buy the Workflow You Need

Factory Teams is the straightforward small-team choice when centralized billing is the requirement. Business is the relevant conversation when you need shared contractual usage, identity management or administrative policy. Do not assume that moving from an individual plan to Teams buys those controls.

These are the monthly terms on Factory's live pricing page, verified October 21, 2026:

The pricing page publishes no token allowances. Usage is stated only as multiples of Pro. Those multiples are not guaranteed task counts, and there is no sound conversion to accepted pull requests. The organization-plan docs clarify that each Teams seat has Pro Rate Limits; Business and Enterprise use shared usage governed by contract terms.

Five Teams seats cost $260 a month: $60 + 5 × $40. Ten cost $460. If a five-seat team hypothetically accepted 20 Droid pull requests in a month, its subscription component would be $13 per accepted pull request. That is arithmetic, not a capacity forecast; extra usage, compute and reviewer time must be added before comparing total cost.

The plan below the workflow is often the problem. Pro does not provide the company controls listed under Business. Teams is not advertised as Plus usage for every seat. And the individual-plan docs list managed Droid Computers under Pro, while the commercial pricing page adds them under Plus. For budgeting, use the pricing page and confirm the actual entitlement before depending on managed compute.

The Limitations That Can Block a Rollout

Factory's most consequential limitations concern consistency across interfaces and plans. They can stop a rollout even when an individual coding session looks good.

Editor support is not feature parity. JetBrains lacks the automatic file, selection and diagnostic sharing described for VS Code-family editors. Zed's Agent Panel does not restore previous Factory Droid sessions. A team standardizing on Droids still needs editor-specific onboarding and a plan for restoring context. Factory documents these differences.

Personal BYOK does not follow you into hosted web or mobile. A locally configured model may be central to your cost or data-handling decision. That configuration is not available on every Factory surface. Validate the intended remote path before buying on the strength of a local demo. The restriction is explicit.

Usage multiples do not establish dependable capacity. The individual-plan docs describe independent 5-hour, 7-day and 30-day rolling windows. A larger subscription does not turn those windows into a published token allowance or a completion guarantee. If a customer deadline depends on unattended execution, discuss contractual capacity rather than extrapolating from a short pilot. Factory's individual usage rules also say Missions pause when a rate limit is reached.

The managed-compute entitlement needs confirmation. The Pro-versus-Plus discrepancy is material for a founder expecting work to run away from a laptop. The live pricing page is the basis for this review's plan table; the conflicting documentation is not evidence of a free upgrade. Also check compute terms separately from model usage instead of treating “cloud agents” as a complete infrastructure allowance.

Permission rules are not operating-system isolation. Factory's own autonomy documentation makes this point. A command being permitted does not prove it is harmless, and a natural-language instruction to avoid production is not a network boundary. For a pilot, use the access and environment appropriate to that task; for organizational enforcement, evaluate the controls in the quoted plans.

These limits favor a narrow adoption path. Put Factory on a workflow where the environment, model, permissions and reviewer are known. Expanding across all repositories before those choices are settled creates coordination work that can erase the benefit of delegation.

Factory AI Review: The Decision Rule

Factory earns a place when it reduces the human work required to turn a defined task into an accepted change. Model choice, multiple interfaces and remote execution are useful only when they improve that result.

Add it beside your current agent when a shared maintenance queue, cross-editor workflow or deliberate model comparison has no satisfactory home today. Replace the incumbent for that task class only after comparable work shows less reviewer effort or lower total cost without weaker acceptance checks. Skip it when it duplicates a workflow that Claude Code, Codex or Cursor already handles well.

The Monday move is a small evaluation with a lead who owns the result:

Factory is a credible candidate for this evaluation. Its documentation supports a broad, configurable agent system. It does not establish that your engineers will ship better work simply by substituting Droid for the agent they already know.

FAQ

Get the AI Business Workflow Audit Checklist through the newsletter to map the task, permissions, review owner and operating cost before expanding an agent rollout.