Web vs. App Capability Comparison

Overview

The GPTBots workspace offers two ways to use it: the Web client (browser access) and the desktop App (macOS/Windows/Linux desktop client). Both clients share the same core UI components and backend APIs, but they differ fundamentally in where the Agent actually executes.

In short:

Web is the brain — it starts conversations, manages the space, and shows results
App is the hands and feet — it actually executes tasks, operates on files, runs commands, and connects to IMs

Distinguishing Them in One Sentence

User question	Answer
Is the browser alone enough for me?	It is enough for viewing Work / Search / workflows / agents / space management — but actually executing tasks requires at least one App node online
Can the desktop App be used standalone without the Web?	Yes. The App client is a complete workspace, with the Agent engine running locally
Does everyone on the team need to install the App?	No. As long as any one person has the App online, team members can dispatch tasks to that App through the Web (the node must be set to enterprise)
Where are the settings I can't find on the Web?	In the desktop App's "Settings" — model keys, skills, tools, scheduled tasks, channels, sub-agents, memory, and runtime security

Feature Matrix Comparison

Capability	🌐 Web client	🖥️ App client
Work conversation	Connects to a remote Agent node via the Gateway	Executes directly through the local Sidecar
Agent Loop	Relies on a remote node to execute	Local autonomous loop of 25 rounds
Context compression	Handled by the remote node	Local 5-layer compression strategy
File system	❌ No local file access	✅ Full local file read/write and search
Sandbox execution	❌ Not supported	✅ Isolated execution in VirtIO micro-VMs
MCP tools	❌ Not supported	✅ Three transports: stdio / SSE / HTTP
Skills	❌ Local skills not supported	✅ 21 built-in + custom + enterprise skills
Channels (IM)	❌ Configuration not supported	✅ 14+ platforms (Telegram, WhatsApp, DingTalk, etc.)
Scheduled tasks	❌ Not supported	✅ One-time / recurring / Cron
Sub-agents	Relies on a remote node	✅ Create locally + dispatch across nodes
Memory management	✅ Enterprise memory (admin interface)	✅ Full scope: account + enterprise + session
Model configuration	❌ Local configuration not supported	✅ Multi-provider API key management
Settings panel	None (equivalent features live in space management)	✅ Full settings
AI Search	✅ Supported	✅ Supported
Agents	✅ A2A agent management + conversation	✅ A2A agent management + conversation
Workflow	✅ Workflow list + details + execution	✅ Workflow list + details + execution
Space management	✅ Full admin features	✅ Accessible through an embedded window
Multimodal preview	✅ Preview of 9 file types	✅ Preview of 9 file types

Architecture Differences

Web client: Gateway connection model

浏览器 ──WebSocket──► Gateway ──WebSocket──► 远程 APP 节点 │ 智能路由 (LLM → BM25 → 兜底)

                      
                      浏览器 ──WebSocket──► Gateway ──WebSocket──► 远程 APP 节点
                        │
                    智能路由
                 (LLM → BM25 → 兜底)

This code block in the floating window

The Web client itself does not run the Agent Engine
All conversation execution relies on at least one online remote App node
The Gateway handles node discovery, smart routing, and message forwarding
Best for: lightweight browsing, space management, remotely starting tasks

App client: local three-process model

React UI ──IPC──► Tauri Rust ──stdio──► Node.js Sidecar (Agent Engine)

                      
                      React UI ──IPC──► Tauri Rust ──stdio──► Node.js Sidecar (Agent Engine)

This code block in the floating window

The App client runs the complete Agent engine locally (the Sidecar process)
Has full access to the local file system
Can register as a Gateway node for remote invocation by the Web client or other Apps
Best for: deep development, automation tasks, local tool execution

The core components of the conversation interface are shared between Web and App through the PlatformAdapter + sibling-repo path aliases — the Web repo and the App repo sit side by side in the same workspace directory, and the App references the Web repo's source code directly through the Vite/tsconfig alias ~/*.

Layer	Description
Shared layer (claw-shared)	40+ components such as WorkPage, PromptInput, SessionList, and Preview, originating in the Web repo
Web adapter	`webPlatformAdapter.ts` — maps the Redux Store to WorkState
App adapter	`appPlatformAdapter.ts` — maps Redux + coworkService to WorkState

This means the Work conversation interface you see on the Web is exactly the same as the one you see in the App — the same code, the same set of components, only the underlying execution differs.

Selection Recommendations

Your scenario	Recommended	Reason
Occasionally chatting with AI or asking a question	Web client	No installation needed; accessible right in the browser
Managing the workspace (members, permissions, usage)	Web client	Space management has the best experience on the Web client
Working with local files or writing code	App client	Requires local file system access + Bash tools
Having AI automate my repetitive daily work	App client	Scheduled tasks are supported only in the App
Connecting AI to the team's IM (Telegram, DingTalk, etc.)	App client	Channel configuration is supported only in the App
Multi-device collaboration (home + office)	Web + multiple Apps	Web starts, App nodes execute
I'm an enterprise admin who wants to manage everyone's AI usage	Web client	Space management interface

Typical Multi-Device Collaboration Usage

"You start a conversation from your Web browser at home → the Gateway routes it to that always-on App in the office → the office App reads local files and completes the task → the results display in real time in your browser."

In this scenario:

The office computer: install the App, log in to your account, and set the node to account (visible only to you) or enterprise (usable by colleagues too)
The home browser: log in to the same account, open Work, and when you send a message the input box automatically selects that App node below it
Task execution: all commands run on the office App, and the results stream back to the home browser through the Gateway