Claude Computer Use в 2026 году: когда выбирать API, Cowork или Claude Code

Сегодня Claude Computer Use означает два разных контракта исполнения. На стороне API Anthropic дает разработчикам beta-инструмент для скриншотов, действий мышью, ввода с клавиатуры и автоматизации рабочего стола внутри песочницы, которую контролируете вы. На стороне продукта Cowork и Claude Code означают, что Claude работает на вашем собственном компьютере, а настольный продукт Anthropic ведет сессию и оставляет вам контроль над доступом, подтверждениями и эскалацией.

Самый короткий и полезный ответ такой: если вы встраиваете автоматизацию в продукт, вам нужен API-путь; если вы хотите, чтобы Claude выполнял работу на вашем собственном компьютере, вам нужен Cowork или Claude Code. Главный вопрос здесь не "умеет ли Claude кликать", а "кто владеет средой исполнения, кто владеет инструментальным циклом и внутри какой границы разрешений и хранения данных вы готовы работать".

“

Примечание по источникам: материал основан на текущих документах Anthropic по computer use API, статье справки по Cowork, странице продукта Cowork и политике обработки данных для computer use, проверенных 28 марта 2026 года.

TL;DR

• Anthropic API computer use нужен разработчикам. Вы включаете beta-инструмент, запускаете Claude внутри своей VM или контейнера, исполняете действия сами и возвращаете tool_result в цикл.
• Cowork и Claude Code нужны для делегирования работы на вашем собственном компьютере. Настольный продукт Anthropic управляет сессией, а вы контролируете папки, коннекторы, подтверждения и то, будет ли Claude подниматься от файлов и браузера к управлению экраном.
• Если нужен самый быстрый старт, на стороне API лучше идти от reference implementation Anthropic, а на стороне настольного продукта начинать с Claude Desktop -> Cowork.
• Эти пути не делят один универсальный контракт по настройке, разрешениям и хранению данных. Их нужно рассматривать отдельно.
• Самое безопасное правило по умолчанию: сначала коннекторы или локальные файлы, затем браузер, и только потом полноценное управление экраном.
• Если задача связана с чувствительными аккаунтами, платежами, согласием с условиями или чем-то, где нужна идеальная точность, человек должен оставаться в контуре подтверждения независимо от выбранного пути.

Что на самом деле означает Claude Computer Use сейчас

Когда этот термин только появился, он был ближе к одной конкретной способности для разработчиков: Anthropic дал Claude возможность смотреть на экран, вызывать действия мышью и клавиатурой и пошагово выполнять задачи в контролируемой среде. Для тех, кто строит агентные продукты, это по-прежнему главный путь.

Путаница возникла потому, что Anthropic теперь использует ту же семью идей и в продуктовой истории про Cowork и Code. На текущей странице Cowork сказано, что Claude может продолжать одну и ту же задачу между телефоном и десктопом, использовать коннекторы, работать в Chrome и, при необходимости, использовать сам компьютер. Страница справки делает картину еще практичнее: Cowork работает внутри Claude Desktop, выполняет работу на вашем компьютере и позволяет вам вмешиваться, пока задача идет. Вместе эти страницы показывают, что один и тот же термин теперь указывает на две разные модели исполнения.

Из этого вырастает вполне практическая ошибка: разработчик может переоценить, сколько Anthropic берет на себя на API-стороне, а пользователь десктопа - недооценить важность настройки доступа, границ и подтверждений на собственной машине. Надежный способ понять тему - смотреть на владельца среды исполнения. Если ваш код получает tool_use, исполняет действие и возвращает результат, это API-путь. Если сессию ведет настольный продукт Anthropic на вашем собственном компьютере, это путь Cowork или Claude Code.

Еще одна вещь, которую важно прояснить сразу: работа через браузер и полноценное управление компьютером - это не одно и то же. Из текущего текста Anthropic вытекает полезная иерархия: если можно использовать коннектор, надо использовать коннектор; если задачу можно решить в Chrome, лучше оставаться в браузере; к управлению экраном стоит переходить только тогда, когда прямой интеграции нет. Эта лестница полезнее, чем общая фраза "Claude умеет пользоваться компьютером", потому что она сразу задает правильный порядок выбора.

Путь 1: API-инструмент Anthropic для управления компьютером

Если вы строите продуктовую автоматизацию, внутреннего агента или рабочий процесс, который действительно должен действовать в интерфейсе как человек, смотреть нужно именно на API-путь. В текущей документации Anthropic computer use описан как beta-инструмент с захватом скриншотов, управлением мышью, вводом с клавиатуры и общей настольной автоматизацией. Самая важная часть примеров не в том, что Claude "умеет кликать", а в контракте: Claude возвращает tool call, ваше приложение исполняет действие внутри VM или контейнера, затем отправляет tool_result, и цикл повторяется до завершения задачи.

Именно эта часть "вы владеете циклом" меняет все. Anthropic не управляет машиной за вас. Системным интегратором являетесь вы. Вы выбираете, как выглядит дисплей, как делать скриншоты, как пересчитывать координаты при масштабировании, как реально исполняются клики и нажатия клавиш и какие ограничения не позволяют модели выйти за пределы нужной среды. То есть на API-стороне computer use - это не магический переключатель, а инструментальный контракт, который вы должны правильно встроить в свою инфраструктуру.

Текущие beta-заголовки тоже подчеркивают, что это именно инструмент, а не "общая автономность по умолчанию". Сейчас Anthropic указывает:

• computer-use-2025-11-24 для Claude Opus 4.6, Claude Sonnet 4.6 и Claude Opus 4.5
• computer-use-2025-01-24 для Sonnet 4.5, Haiku 4.5, Opus 4.1, Sonnet 4, Opus 4 и устаревшего Sonnet 3.7

Минимальный каркас запроса выглядит так:

bash
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: computer-use-2025-11-24" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "tools": [
      {
        "type": "computer_20251124",
        "name": "computer",
        "display_width_px": 1024,
        "display_height_px": 768,
        "display_number": 1
      }
    ],
    "messages": [
      {
        "role": "user",
        "content": "Open the browser and summarize the dashboard."
      }
    ]
  }'

Этот пример важен не как "готовый рецепт", а как напоминание о настоящем характере функции. Вы не включаете абстрактную автономность. Вы задаете конкретный beta-контракт, конкретный инструмент и конкретную среду, а затем сами обеспечиваете исполнение.

Лучше всего этот путь работает там, где интерфейс действительно является системой учета. Старые корпоративные приложения, внутренние инструменты без нормального API, RPA-подобные сценарии, end-to-end тесты - все это разумные области применения. Но если у системы уже есть API, CLI, webhook или нормальный экспорт данных, экранная автоматизация почти всегда будет худшим инженерным выбором. Не потому, что computer use плох, а потому, что вы используете самую хрупкую прослойку там, где есть более прямой машинный интерфейс.

Модель затрат только усиливает этот вывод. Anthropic сейчас прямо пишет, что beta computer use добавляет 466-499 токенов к system prompt, а на моделях Claude 4.x еще и 735 входных токенов определения инструмента, не считая стоимости скриншотов и возвращаемых результатов. То есть вы платите дополнительный накладной слой только за то, чтобы держать модель "привязанной" к визуальной среде. Это оправдано тогда, когда интерфейс действительно является реальным входом в систему. И это напрасно, когда вы автоматизируете UI у системы, у которой уже есть нормальная интеграционная поверхность.

Самая ценная часть документации Anthropic здесь - не код, а меры безопасности. Компания рекомендует запускать computer use в выделенной VM или контейнере с минимальными привилегиями, ограничивать доступ к доменам и требовать подтверждения человека для действий с реальными последствиями. Отдельно Anthropic предупреждает о prompt injection через веб-страницы и изображения. Это не декоративный список рисков, а инженерная суть задачи. Как только модель может читать экран и действовать по увиденному, среду нужно рассматривать как потенциально враждебную, а не как красивую demo-сцену.

Есть и более приземленный нюанс, который легко пропустить: пересчет координат. В текущих документах Anthropic указывает, что изображение, которое анализирует модель, может быть меньше реального экрана, по которому вы кликаете. Если вы сами не масштабируете скриншот и не переводите координаты обратно, модель может промахиваться даже при правильном рассуждении. И это еще один аргумент в пользу того, что API-путь - это путь разработчика, а не "чуть более умный макрос".

Путь 2: Cowork и Claude Code на вашем компьютере

Когда большинство людей говорят, что хотят "чтобы Claude управлял компьютером", они на самом деле имеют в виду именно этот настольный путь. Ключевое различие здесь в том, что вы не встраиваете инструмент в свой продукт, а пользуетесь настольной средой Anthropic для делегирования работы на своей собственной машине. Текущая страница справки по Cowork говорит, что для него нужен Claude Desktop на macOS или Windows, он доступен только на платных планах и сам по себе не является веб- или мобильной поверхностью исполнения. Пока Claude работает, настольное приложение должно оставаться открытым.

Это уже делает путь совершенно непохожим на API. API - это контракт интеграции. Cowork - это продуктовый рабочий режим. Anthropic описывает его ближе к модели "передайте Claude задачу и вернитесь к готовому результату". У приложения есть доступ к папкам, которыми вы делитесь, к коннекторам и локальным файлам; оно может вести более длинные задачи. Та же страница справки отдельно подчеркивает, что вы можете продолжать общение с телефона, пока задача идет на десктопе. Это совсем другой тип удобства. На API-пути вы строите среду. Здесь вы управляете уже готовым продуктовым контуром.

Страница продукта Cowork добавляет еще одну важную деталь, которую многие вторичные объяснения игнорируют. Anthropic пишет, что Claude выбирает самый быстрый путь: сначала коннектор, затем Chrome для веб-задач и только потом экран, если прямой интеграции нет. Это гораздо полезнее, чем кинематографичная фраза "Claude может пользоваться вашим компьютером". На практике это означает простую вещь: управление экраном должно быть резервным уровнем, а не первым шагом.

Формулировки Anthropic об общей доступности тоже достаточно осторожны. Страница справки говорит, что Cowork в целом работает в Claude Desktop на macOS и Windows в рамках платных планов. Но более сильная фраза на продуктовой странице - "Anything you can do on your computer, Claude can do" - сейчас отмечена как доступная на macOS. Самый безопасный вывод здесь - не пытаться сплющить эти формулировки в одну универсальную. Надо говорить так, как сказано в документах: настольный рабочий режим Cowork шире, а явно обозначенный путь компьютерного управления на странице продукта сейчас привязан к macOS.

Важно и то, что Anthropic на той же продуктовой странице говорит о persistent conversation и computer-use update как о функции, которая охватывает и Cowork, и Code. Но если вам нужен наиболее понятный и публично документированный путь запуска, документация сегодня все еще заметно более Cowork-центрична, чем Code-центрична. Поэтому безопаснее формулировать так: Code и Cowork входят в один настольный рабочий контур, но если вам нужен конкретный стартовый сценарий, опирайтесь на документацию Cowork, а Code воспринимайте как родственную, но не идентично описанную поверхность.

Границы разрешений здесь тоже намного ближе к продуктовой модели. По справке Cowork требует отдельного подтверждения перед постоянным удалением файлов. На странице продукта говорится, что Claude сначала показывает план, ждет одобрения и дает вам выбрать, к каким папкам и коннекторам у него будет доступ. Это совсем не то же самое, что API-путь, где песочницу и механику подтверждений проектируете вы. Настольный путь - это управляемый интерфейс делегирования, а не низкоуровневый инструментарий автоматизации.

Для огромного числа неразработческих сценариев это именно то, что и нужно. Разобрать папку Downloads, собрать отчет из заметок, превратить скриншоты чеков в таблицу, подготовить повторяющийся дайджест - все это гораздо больше похоже на задачу Cowork, чем на задачу для API computer use. Даже в задачах рядом с разработкой правильный вопрос остается прежним: вам нужен программируемый runtime для агента или вы просто хотите, чтобы Claude сделал работу на вашем компьютере, а вы контролировали процесс? Если второе, то Cowork или Claude Code - более естественная отправная точка.

Если вас сейчас интересуют именно подписки и доступ, стоит параллельно прочитать наш гид по ценам Claude Code. А если вам на самом деле не нужен широкий "computer use", а нужна более безопасная автономность в кодовой среде, гораздо полезнее окажется разбор Claude Code Auto mode.

Самый быстрый старт для каждой поверхности

Если вы не хотите сначала разбираться во всей экосистеме, а потом только пробовать, начните так.

Для API-пути берите за основу reference implementation Anthropic, а не пишите с нуля "исполнитель кликов". Настройте текущий beta-header, поднимите среду в отдельной VM или контейнере, передайте Claude инструмент computer use и задачу, выполните возвращенное действие и отправьте tool_result назад. Ключевой момент здесь не в первом запросе, а в том, насколько правильно вы изолировали среду вокруг него.

Для настольного пути откройте Claude Desktop, переключитесь в Cowork, выберите рабочую папку или файлы, к которым Claude должен получить доступ, сформулируйте желаемый результат, просмотрите план и только потом запускайте выполнение. Пока задача идет, настольное приложение должно быть открыто. Если хотите продолжить с телефона, используйте мобильное продолжение, которое Anthropic описывает для Cowork, но помните: реальное исполнение все равно остается на десктопе.

Какой путь выбрать именно вам?

Если вы внедряете агентную возможность в продукт, выбирайте API.
Если вы делегируете задачу Claude на собственном компьютере, выбирайте Cowork или Claude Code. В более прикладном виде это выглядит так:

Самая полезная ментальная модель проста: API-путь нужен тем, кто строит инструмент, а настольный путь - тем, кто делегирует работу. Важно не делать возможность визуально "больше", а сначала разделить владельца среды исполнения. Только так можно правильно развести риски, стоимость настройки, поток подтверждений и реальные сценарии использования.

История с приватностью и хранением данных зависит от поверхности

Это один из самых частых источников неправильных формулировок. У Anthropic сейчас нет одной универсальной фразы про хранение данных, которая одинаково и без остатка описывала бы все варианты computer use.

Для API-инструмента документация пишет, что это client-side tool и что при наличии ZDR-соглашения функция может работать без хранения данных после возврата ответа. Но статья в privacy center про commercial products говорит, что скриншоты по умолчанию удаляются из backend через 30 дней, если не согласованы другие условия. А страница Cowork делает акцент на том, что история задач хранится локально, если вы сами не отправляете обратную связь или диагностику.

Из этого не следует вывод "Anthropic противоречит сам себе". Следует более точный вывод: computer use теперь существует более чем на одной поверхности, и у каждой поверхности своя контекстная модель данных. Для разработчика правильный ход - читать retention как часть контракта реализации и смотреть на точный план и режим, в котором вы работаете. Для пользователя настольного продукта правильнее отталкиваться от локальной истории, разрешений рабочего стола и продуктовых границ доступа, а не слепо переносить на себя формулировки из API-страниц. Чего точно не стоит делать - брать одну фразу про retention с одной страницы и объявлять ее универсальным правилом для всех сценариев.

Когда не стоит использовать полный computer control

Из текущих формулировок Anthropic вытекает правильное практическое правило: используйте самый "узкий" уровень контроля, который действительно решает задачу. Если можно взять данные через коннектор, делайте так. Если Claude может справиться через локальные файлы, это обычно надежнее, чем заставлять его кликать по окнам приложений. Если задача по сути браузерная - исследование, форма, навигация по dashboard, - путь через Chrome обычно лучше, чем "весь экран". И только если прямой интеграции и более узкой веб-поверхности нет, управление экраном становится последним резервным уровнем.

Это важно и для безопасности, и для надежности. Коннекторы и файлы проще ограничить по области доступа, проще аудировать и сложнее случайно превратить в источник лишнего риска. Браузерные сценарии все еще более хрупкие, чем прямой API, но они обычно менее открыты, чем полный контроль над рабочим столом. Экранная автоматизация - это самый мощный и самый трудный для анализа слой. Поэтому именно он и должен оставаться последней ступенью, а не default-путем.

Есть и отдельный класс задач, где "Claude может" не означает "Claude должен". Anthropic прямо требует человеческого подтверждения для действий с реальными последствиями, и это правильный стандарт. Согласие на cookies, платежи, юридические подтверждения, разрушительные операции, доступ к чувствительным аккаунтам, любая работа, где нужна идеальная точность, - все это должно оставаться под прямым человеческим контролем. Даже если модель в большинстве случаев справляется, цена ошибки здесь слишком высока.

То же относится и к задачам, у которых уже есть лучший интерфейс. Если у вас есть API, экспорт CSV, SQL-запрос или webhook, а вы все равно автоматизируете экран, проблема не в том, что computer use плох. Проблема в том, что вы выбрали самый хрупкий уровень там, где существовал более прямой. Computer use ценен потому, что часть программ по-прежнему устроена "для человека", а не потому, что клик мышью сам по себе является самым продвинутым способом интеграции.

FAQ

Claude Computer Use - это только API-инструмент Anthropic?

Нет. Для разработчиков это по-прежнему основной смысл термина. Но текущие страницы Anthropic про Cowork и Code тоже помещают похожую способность в настольный рабочий контур. Поэтому сегодня термин покрывает больше одной поверхности.

Нужно ли самому реализовывать цикл инструмента?

Только на API-пути. Текущая документация Anthropic прямо говорит, что ваше приложение извлекает tool call, исполняет действие в VM или контейнере и возвращает tool_result. На настольном пути этот оркестрационный слой берет на себя продукт Anthropic.

Cowork работает в вебе? Телефон может сам исполнять задачи?

Нет. По текущей справке Cowork требует Claude Desktop на macOS или Windows и не является отдельной веб- или мобильной поверхностью исполнения. С телефона можно продолжать общение, но сама работа все равно привязана к настольному приложению.

Если Cowork доступен, значит и полноценное управление компьютером доступно так же широко?

Не стоит так предполагать. Страница справки описывает Cowork шире, а продуктовая страница более узко помечает явный путь компьютерного управления как Available on macOS. Безопаснее придерживаться именно такой, более конкретной формулировки.

Дорог ли API-путь?

Он заметно дороже обычного текстового использования, потому что к модели добавляется стоимость инструмента и скриншотов. Anthropic сейчас перечисляет накладные расходы в виде 466-499 токенов beta system prompt, 735 токенов определения инструмента на Claude 4.x и дополнительных токенов от скриншотов и результатов инструментов. Именно поэтому этот путь стоит оставлять для случаев, где UI-автоматизация действительно необходима.

Anthropic хранит скриншоты?

Отвечать нужно по поверхности, а не одной универсальной фразой. В API-документации речь идет о ZDR-режиме. В privacy-статье для commercial products - об удалении по умолчанию через 30 дней. На стороне Cowork основной акцент сделан на локальном хранении истории. Если этот вопрос критичен для вашего сценария, проверяйте именно ту поверхность и тот договор, по которым вы реально работаете.

Полезный вопрос здесь не в том, умеет ли Claude кликать

Claude умеет кликать. Это уже не самая важная часть истории.

Полезный вопрос - какую систему вы строите и какой уровень контроля готовы доверить модели. Если вы делаете продукт, относитесь к API-инструменту как к настоящему runtime для автоматизации и помещайте его в реальную песочницу с реальными границами подтверждения. Если вы хотите, чтобы Claude работал на вашем собственном компьютере, используйте Cowork или Claude Code и позвольте настольному продукту Anthropic вести сессию, а сами контролируйте папки, коннекторы и ключевые одобрения.

Когда тема сформулирована именно так, Claude Computer Use перестает быть туманным обещанием и превращается в конкретный выбор маршрута. А качество этого выбора и определяет, будет ли у вас реальная автоматизация или просто впечатляющая, но хрупкая демо-картинка.