Perplexity Comet is capable inside a browser session. Aiden is being built as a device automation agent for work that moves across visible phone and computer interfaces — beyond what any browser session can reach.
Comet deserves the comparison
Perplexity positions Comet as an AI-first browser and personal assistant, available across Mac, Windows, iPhone, iPad, and Android, with a usable free tier. For research, page-level questions, tab-heavy synthesis, and supported web actions, that browser-native model is genuinely strong.
The distinction isn't that browser agents are less useful — it's that every agent works through a control surface. Comet's surface is the browser session: tabs, webpages, browser-accessible documents, web apps. Aiden's surface is the connected device itself.
This is a real, expanding category, not a single-product comparison:
- Fellou — explicit "self-driving browser" positioning for multi-step web tasks
- Dia (The Browser Company) — strong cross-tab context, though more suggestive than autonomous
- Opera Neon — experimental, agentic, broader creation-workflow emphasis
Each reflects the same direction: AI moving from answering questions to participating in interface work. The practical difference is where that participation can continue.
Where the browser boundary actually shows up
| Workflow moment | Browser-session strength | Where the boundary appears |
|---|---|---|
| Researching sources | Web search, reading, tab comparison | Task stays browser-contained |
| Filling a web form | Browser-rendered fields, on-page actions | External identity checks or system dialogs |
| Saving findings | Web notes, browser-accessible docs | Native notes/desktop app needs another path |
| Working with local files | Downloads, web uploads | File pickers, desktop software, permission prompts |
| Continuing on a phone | Mobile browser context | Native apps, device settings, cross-app handoffs |
flowchart LR
A[User instruction] --> B{Current control surface}
B --> C[Browser session]
C --> D["Tabs, webpages, web apps"]
D --> E[Browser-supported action]
E --> F[Review browser outcome]
B --> G[Connected device interface]
G --> H["Browser, native app, desktop app, or system dialog"]
H --> I[Observe visible state]
I --> J[Propose next action]
J --> K[User confirms, redirects, or stops]
K --> L[Execute supported interaction]
L --> M[Review outcome]
How Aiden actually works
Aiden's firmware repo documents a development-board implementation: HDMI-based screen capture, USB HID input. It observes a connected screen and sends keyboard, pointer, or touch-style input — no app-specific integration required on the target device.
That's evidence of a documented dev-board implementation. It's not a claim of universal compatibility, task-success guarantees, or consumer availability. Aiden's being developed for Android and iPhone workflows specifically, and the team is upfront that real-device interaction has real constraints — setup conditions, OS versions, accessibility settings, interface variability.
Choosing between the two isn't a category war
| Need | Browser-first (Comet) | Device-level (Aiden) |
|---|---|---|
| Research across webpages | Strong fit | Relevant only if research continues onto a device |
| Native mobile app handoff | Depends on integrations | Core workflow category Aiden targets |
| Desktop application interaction | Depends on external access paths | Relevant when visible desktop interfaces matter |
| Consequential decisions | User review required | User confirmation/interruption stays central |
Aiden isn't presented as a Comet replacement. Use a browser agent for web research and browser-native tasks; use the device-level approach when a real interface handoff becomes necessary.
Repo: github.com/AidenAI-IO/aiden-firmware
Discord: discord.com/invite/bcJavjcnYz — engineers active, technical questions welcome.
Top comments (0)