Back to the Finder

Happy

Open-source desktop app for Mac, Windows and Linux. Agents run on your computer or on your own server.

Product websitehappy.engineering Compare with others Missing or wrong data?

Happy product interface, supplied by its publisher
Desktop app
Mac, Windows and Linux
Browser
Yes
Phone
IPhone, Android and phone browser
Command line
Yes
Agents
Claude Code, Codex, OpenCode and Antigravity
Your subscription
Works with your own plan
Agents run
On your computer and on your own server
Laptop closed
Keeps going
Isolation
Worktree and Container
Parallel agents
Yes
Scheduled runs
Yes
Coordinator agent
Yes
Built-in issues
Yes
Pull requests
No
Review screen
Yes
Team
Shared sessions, roles and SSO
Self-hosting
Yes
Licence
MIT
Price from
Free
How it charges
Free plan, subscription and bring your own key
Paid plans from
Not listed

Receipts

Checked
· oldest answer 2026-11-08
Findings
39 published · 32 cross-checked by a second agent · read them all
Sources
48 public pages on 2 sites: github.com, happy.engineering
Screenshot
happy.engineering, retrieved · first party release · shows appearance, not capability
Method
Same rules for all 103 researched ADEs. How we check · Report wrong data

What it does

Where you use it

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

Source and scope for Where you use it

Agents it runs

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

Source and scope for Agents it runs

Accounts and subscriptions

Happy reuses existing Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP agents use their own login. Bedrock API keys or the AWS credential chain are supported.

Source and scope for Accounts and subscriptions

Where agents run

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

Source and scope for Where agents run

How work is kept apart

Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

Source and scope for How work is kept apart

Parallel work

Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.

Source and scope for Parallel work

Scheduled runs

Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.

Source and scope for Scheduled runs

Git and pull requests

The pinned runtime and clients manage Git workspaces and file changes. They have no built-in PR creation or management path; users can ask a coding agent to use external shell or MCP tools.

Source and scope for Git and pull requests

Licence and source

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Source and scope for Licence and source

Price

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Source and scope for Price

JSON for agentsMarkdown for agents

Report wrong dataSuggest a missing ADE

Typed filters

Every value links to its receipt below. Read plan and surface restrictions before using a filter to decide.

Typed filter values
FilterValue
Desktop OS: macOSYes
Desktop OS: WindowsYes
Desktop OS: LinuxYes
Web clientYes
Phone access: Native iOSYes
Phone access: Native AndroidYes
Phone access: Phone browserYes
CLIYes
Coding agents: Claude CodeYes cross-checked
Coding agents: CodexYes cross-checked
Coding agents: Cursor AgentUnknown
Coding agents: Gemini CLIUnknown
Coding agents: OpenCodeYes cross-checked
Coding agents: PiUnknown
Coding agents: GrokUnknown
Coding agents: AiderUnknown
Coding agents: AntigravityYes cross-checked
Use my subscriptionYes cross-checked
Where agents run: On your computerYes cross-checked
Where agents run: On your own serverYes cross-checked
Where agents run: In the vendor's cloudNo
Workspace isolation: Git worktreeYes
Workspace isolation: ContainerYes
Workspace isolation: VM or microVMNo
Parallel runsYes cross-checked
CoordinatorYes cross-checked
Native issue trackingYes
Unattended triggersYes cross-checked
Shared promptingYes cross-checked
Team rolesYes cross-checked
SSOYes cross-checked
Pull request workflowNo
Review interfaceYes cross-checked
Product license: Apache-2.0No. MIT cross-checked
Product license: MITYes. MIT cross-checked
Product license: GPL-3.0No. MIT cross-checked
Product license: GPL-3.0-or-laterNo. MIT cross-checked
Product license: AGPL-3.0No. MIT cross-checked
Product license: AGPL-3.0-or-laterNo. MIT cross-checked
Product license: Elastic License 2.0No. MIT cross-checked
Product license: Custom termsNo. MIT cross-checked
Product license: ProprietaryNo. MIT cross-checked
Self-hostingYes cross-checked
Telemetry opt-outYes cross-checked
Free accessYes cross-checked
Starting price: FreeYes. Free cross-checked
Starting price: Up to $20/monthNo. Free cross-checked
Starting price: $21–40/monthNo. Free cross-checked
Starting price: $41–100/monthNo. Free cross-checked
Starting price: Over $100/monthNo. Free cross-checked
Starting price: Contact for pricingNo. Free cross-checked
Pricing model: Free, no paid planNo
Pricing model: Free planYes cross-checked
Pricing model: SubscriptionYes
Pricing model: Per seatNo
Pricing model: Usage-basedNo
Pricing model: Per machine or computeNo
Pricing model: Bring your own keyYes cross-checked
Pricing model: One-time purchaseNo
Paid plans from: No paid planUnknown
Paid plans from: $10 or less/monthUnknown
Paid plans from: $11–20/monthUnknown
Paid plans from: $21–40/monthUnknown
Paid plans from: $41–100/monthUnknown
Paid plans from: Over $100/monthUnknown
Paid plans from: Contact salesUnknown
Lifecycle status: ActiveUnknown
Lifecycle status: SunsettingUnknown
Keeps going with laptop closedYes cross-checked
Open-source licenseYes. MIT cross-checked
Any desktop appYes
Paid plan up to $20/monthUnknown
Paid plan up to $40/monthUnknown
Any phone clientYes

Filter receipts

Desktop OS: macOS: Yes

Desktop OS: macOS

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Desktop OS: Windows: Yes

Desktop OS: Windows

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Desktop OS: Linux: Yes

Desktop OS: Linux

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Web client: Yes

Web client

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Phone access: Native iOS: Yes

Phone access: Native iOS

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Phone access: Native Android: Yes

Phone access: Native Android

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Phone access: Phone browser: Yes

Phone access: Phone browser

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

CLI: Yes

CLI

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Coding agents: Claude Code: Yes cross-checked

Coding agents: Claude Code

Typed value: Yes.

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

  • Harnesses: Happy's own harness by default; claude_code and codex_cli harness options run Claude Code and Codex CLI themselves; Antigravity and OpenCode or other ACP agents (beta). The original CLI wraps Claude Code and Codex. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.
  • Custom adapters: Any Agent Client Protocol agent can be added on its own login (beta).
  • Session integration: The claude_code and codex_cli harnesses run those agents' own loops on their accounts inside Happy sessions.
  • Mixed harness operation: Subagents pick their own model, and harness options sit alongside Happy's own loop; no mixed-harness run was observed.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  • Antigravity is a beta foreign-harness integration using a community ACP adapter and its own login; new sessions are serialized to avoid conversation binding collisions.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Harnesses: Claude Code, Codex CLI, Antigravity, OpenCode, and ACP agents

    Finding: Happy's own harness runs the loop by default; the claude_code harness runs Claude Code itself on a claude account and codex_cli does the same for Codex, while Antigravity, OpenCode and other ACP agents sign in themselves. Grok is not listed as a harness.

Coding agents: Codex: Yes cross-checked

Coding agents: Codex

Typed value: Yes.

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

  • Harnesses: Happy's own harness by default; claude_code and codex_cli harness options run Claude Code and Codex CLI themselves; Antigravity and OpenCode or other ACP agents (beta). The original CLI wraps Claude Code and Codex. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.
  • Custom adapters: Any Agent Client Protocol agent can be added on its own login (beta).
  • Session integration: The claude_code and codex_cli harnesses run those agents' own loops on their accounts inside Happy sessions.
  • Mixed harness operation: Subagents pick their own model, and harness options sit alongside Happy's own loop; no mixed-harness run was observed.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  • Antigravity is a beta foreign-harness integration using a community ACP adapter and its own login; new sessions are serialized to avoid conversation binding collisions.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Harnesses: Claude Code, Codex CLI, Antigravity, OpenCode, and ACP agents

    Finding: Happy's own harness runs the loop by default; the claude_code harness runs Claude Code itself on a claude account and codex_cli does the same for Codex, while Antigravity, OpenCode and other ACP agents sign in themselves. Grok is not listed as a harness.

Coding agents: OpenCode: Yes cross-checked

Coding agents: OpenCode

Typed value: Yes.

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

  • Harnesses: Happy's own harness by default; claude_code and codex_cli harness options run Claude Code and Codex CLI themselves; Antigravity and OpenCode or other ACP agents (beta). The original CLI wraps Claude Code and Codex. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.
  • Model providers: Claude, Codex and Grok models on existing CLI sign-ins, Gemini through Antigravity, and Bedrock.
  • Custom adapters: Any Agent Client Protocol agent can be added on its own login (beta).
  • Session integration: The claude_code and codex_cli harnesses run those agents' own loops on their accounts inside Happy sessions.
  • Mixed harness operation: Subagents pick their own model, and harness options sit alongside Happy's own loop; no mixed-harness run was observed.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  • Antigravity is a beta foreign-harness integration using a community ACP adapter and its own login; new sessions are serialized to avoid conversation binding collisions.
  1. Happy: Supported providers; Switch models

    Finding: Happy runs Claude, Codex and Grok on the user's existing Claude Code, Codex or Grok CLI sign-ins, Gemini through Antigravity, and OpenCode or other ACP agents on their own login (beta). Model or effort can change mid-session without discarding the transcript.

  2. Happy: Harnesses: Claude Code, Codex CLI, Antigravity, OpenCode, and ACP agents

    Finding: Happy's own harness runs the loop by default; the claude_code harness runs Claude Code itself on a claude account and codex_cli does the same for Codex, while Antigravity, OpenCode and other ACP agents sign in themselves. Grok is not listed as a harness.

Coding agents: Antigravity: Yes cross-checked

Coding agents: Antigravity

Typed value: Yes.

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

  • Harnesses: Happy's own harness by default; claude_code and codex_cli harness options run Claude Code and Codex CLI themselves; Antigravity and OpenCode or other ACP agents (beta). The original CLI wraps Claude Code and Codex. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  • Antigravity is a beta foreign-harness integration using a community ACP adapter and its own login; new sessions are serialized to avoid conversation binding collisions.
  1. Happy Antigravity support at v2026.11.4

    Finding: Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

Use my subscription: Yes cross-checked

Use my subscription

Typed value: Yes.

Happy reuses existing Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP agents use their own login. Bedrock API keys or the AWS credential chain are supported.

  • Agent subscriptions: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Api accounts: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Account switching: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Provider restrictions: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Models and Subscriptions

    Finding: Happy uses existing Claude Code, Codex and Grok CLI sign-ins, so no Happy plan or pasted key is needed for model access; Antigravity and ACP agents use their own login. Bedrock works with an API key or the AWS credential chain.

Where agents run: On your computer: Yes cross-checked

Where agents run: On your computer

Typed value: Yes.

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

  • Local: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Byo remote: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Self hosted: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Hybrid: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Payer: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Client disconnect: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Other device continuation: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Remote server

    Finding: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

Where agents run: On your own server: Yes cross-checked

Where agents run: On your own server

Typed value: Yes.

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

  • Local: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Byo remote: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Self hosted: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Hybrid: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Payer: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Client disconnect: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Other device continuation: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Remote server

    Finding: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

Where agents run: In the vendor's cloud: No

Where agents run: In the vendor's cloud

Typed value: No.

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

  • Local: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Byo remote: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Self hosted: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Hybrid: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Payer: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Client disconnect: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Other device continuation: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Remote server

    Finding: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

Workspace isolation: Git worktree: Yes

Workspace isolation: Git worktree

Typed value: Yes.

Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

  • Branch: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Worktree: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Container: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Os sandbox: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Filesystem: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Network: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Secrets: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Code separation: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Security boundary: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • The scoped first-party source pass does not establish checkout, process. No hands-on scenario was run.
  1. Happy: How Happy creates a workspace

    Finding: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.

  2. Happy: What the OS sandbox enforces

    Finding: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.

Workspace isolation: Container: Yes

Workspace isolation: Container

Typed value: Yes.

Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

  • Branch: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Worktree: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Container: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Os sandbox: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Filesystem: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Network: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Secrets: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • Code separation: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.
  • Security boundary: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.
  • The scoped first-party source pass does not establish checkout, process. No hands-on scenario was run.
  1. Happy: How Happy creates a workspace

    Finding: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.

  2. Happy: What the OS sandbox enforces

    Finding: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.

Workspace isolation: VM or microVM: No

Workspace isolation: VM or microVM

Typed value: No.

Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

  • Vm: No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.
  • The scoped first-party source pass does not establish checkout, process. No hands-on scenario was run.
  1. Happy execution configuration at v2026.11.4

    Finding: The scoped runtime config and runner implementation provide host process execution and optional Docker image/container execution, with OS sandbox restrictions. No VM or microVM isolation backend is implemented in the inspected release. A user provisioning a host VM is separate.

Parallel runs: Yes cross-checked

Parallel runs

Typed value: Yes.

Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.

  • Concurrent sessions: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.
  • Concurrent tasks: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.
  • Quotas: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.
  • Status visibility: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Subagents; What Happy Desktop shows

    Finding: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.

Coordinator: Yes cross-checked

Coordinator

Typed value: Yes.

Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.

  • Roles: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Model harness effort: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Messages: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Results return: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Cross harness: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Activation: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Retained results: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Followup: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Subagents; How agents message each other

    Finding: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.

Native issue tracking: Yes

Native issue tracking

Typed value: Yes.

Happy creates persistent task records through its API, agent tool and Desktop UI. Native task operations rename task records. Creating a task without opening text stores an idle draft. The task catalog has a task ID separate from its linked agent and workspace IDs; each task has one root conversation. Task state is persisted as active or archived with restoration and versioned updates. Task archival persists and stops the task agent and descendants. Native unarchive restores an archived task.

  • Create: Happy creates persistent task records through its API, agent tool and Desktop UI.
  • Edit: Native task operations rename task records.
  • Archive: Task archival persists and stops the task agent and descendants.
  • Reopen: Native unarchive restores an archived task.
  • Idea parking: Creating a task without opening text stores an idle draft.
  • Task session separation: The task catalog has a task ID separate from its linked agent and workspace IDs; each task has one root conversation.
  • Durable states: Task state is persisted as active or archived with restoration and versioned updates.
  • The scoped first-party source pass does not establish discuss, prioritize, label, assign, search, filter, project_epic_views, explicit_dispatch, metadata, external_tracker_requirement. No hands-on scenario was run.
  1. Happy task catalog schema at v2026.11.4

    Finding: Task records have independent task, agent and workspace IDs, owner and creator fields, versioned active/archived state and timestamps. Creation accepts no opening text, allowing an idle draft before work starts.

  2. Happy native task operations at v2026.11.4

    Finding: The TasksModule creates distinct task and agent records, supports rename, join, reorder, archive and unarchive, and persists catalog state. The API and Desktop task creation surface expose the task catalog.

Unattended triggers: Yes cross-checked

Unattended triggers

Typed value: Yes.

Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.

  • Schedules: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.
  • Scheduler location: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.
  • Client independence: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Durable waits and scheduled messages

    Finding: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.

Shared prompting: Yes cross-checked

Shared prompting

Typed value: Yes.

Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.

  • Visibility: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.
  • Coprompting: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.
  • Attribution: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.
  • Permissions: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Shared work

    Finding: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.

Team roles: Yes cross-checked

Team roles

Typed value: Yes.

Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.

  • Organization roles: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.
  • Membership: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.
  • Plan scope: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Owner; Sign-in; Leaving

    Finding: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.

SSO: Yes cross-checked

SSO

Typed value: Yes.

Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.

  • Sso: Team mode can replace Happy's WorkOS accounts with the organization's own identity provider through an organization-run OAuth authorization server whose JWTs the daemon verifies (Agent v2026.11.4; desktop v0.0.103 discovers sign-in methods). Documented and source-inspected, not tested; the deployer must operate the authorization server.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy website source: Set up enterprise JWT sign-in

    Finding: Recipe for a team-mode Happy Agent whose members sign in through the organization's own identity provider (Okta, Entra ID, Google Workspace, Keycloak or internal SSO) instead of Happy's WorkOS accounts; the daemon verifies JWTs from an organization-owned OAuth authorization server and needs an Agent release with enterprise JWT authentication.

  2. Happy Agent TeamJwtConfig at release v2026.11.4

    Finding: The released Happy Agent v2026.11.4 parses a [feature.team.jwt] machine configuration with an authorization URL and exactly one of a JWKS URL, public key or secret, used to verify organization-issued team tokens.

  3. Happy Desktop server sign-in discovery at release v0.0.103

    Finding: The released desktop app v0.0.103 queries a Happy Agent server's v0/authentication endpoint to discover its sign-in methods.

Pull request workflow: No

Pull request workflow

Typed value: No.

The pinned runtime and clients manage Git workspaces and file changes. They have no built-in PR creation or management path; users can ask a coding agent to use external shell or MCP tools.

  • Pull requests: The inspected release has no built-in PR create/manage interface. External shell or MCP tools remain possible.
  • The scoped first-party source pass does not establish branches, worktrees, commits, comments, ci_response, rebase, conflicts, product_state. No hands-on scenario was run.
  1. Happy Git module and bounded PR integration inspection

    Finding: The pinned runtime Git module and clients provide file changes, branches and workspaces, but no product-owned pull-request creation or management path was found. PRs can still be operated through an external shell command or MCP service; that is not a built-in Happy PR workflow.

Review interface: Yes cross-checked

Review interface

Typed value: Yes.

The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.

  • Change understanding: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.
  • Evidence navigation: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Initial core release; Current interface

    Finding: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.

Product license: Apache-2.0: No. MIT cross-checked

Product license: Apache-2.0

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: MIT: Yes. MIT cross-checked

Product license: MIT

Typed value: Yes. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: GPL-3.0: No. MIT cross-checked

Product license: GPL-3.0

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: GPL-3.0-or-later: No. MIT cross-checked

Product license: GPL-3.0-or-later

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: AGPL-3.0: No. MIT cross-checked

Product license: AGPL-3.0

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: AGPL-3.0-or-later: No. MIT cross-checked

Product license: AGPL-3.0-or-later

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: Elastic License 2.0: No. MIT cross-checked

Product license: Elastic License 2.0

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: Custom terms: No. MIT cross-checked

Product license: Custom terms

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Product license: Proprietary: No. MIT cross-checked

Product license: Proprietary

Typed value: No. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Self-hosting: Yes cross-checked

Self-hosting

Typed value: Yes.

The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.

  • Self hosting: The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.
  • Vendor dependencies: The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: How a Happy team server works

    Finding: The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.

Telemetry opt-out: Yes cross-checked

Telemetry opt-out

Typed value: Yes.

Happy apps send pseudonymous usage events to PostHog, excluding message content, prompts, code and file names, and offer a Settings opt-out that stops them; the desktop app has its own switch. Happy Agent itself sends no analytics.

  • Telemetry disclosure: Happy apps send product usage events to PostHog and offer a Settings opt-out that stops analytics events. Happy Agent itself sends no analytics. Provider/model work still follows provider policies.
  • Telemetry defaults: Happy apps send product usage events to PostHog and offer a Settings opt-out that stops analytics events. Happy Agent itself sends no analytics. Provider/model work still follows provider policies.
  • Telemetry controls: Happy apps send product usage events to PostHog and offer a Settings opt-out that stops analytics events. Happy Agent itself sends no analytics. Provider/model work still follows provider policies.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Analytics: PostHog

    Finding: Happy apps send pseudonymous product usage events to PostHog, excluding message content, prompts, code and file names, and offer a Settings opt-out that stops them; the desktop app has its own switch. Happy Agent itself sends no analytics.

Free access: Yes cross-checked

Free access

Typed value: Yes.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: Free: Yes. Free cross-checked

Starting price: Free

Typed value: Yes. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: Up to $20/month: No. Free cross-checked

Starting price: Up to $20/month

Typed value: No. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: $21–40/month: No. Free cross-checked

Starting price: $21–40/month

Typed value: No. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: $41–100/month: No. Free cross-checked

Starting price: $41–100/month

Typed value: No. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: Over $100/month: No. Free cross-checked

Starting price: Over $100/month

Typed value: No. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Starting price: Contact for pricing: No. Free cross-checked

Starting price: Contact for pricing

Typed value: No. Free.

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Ongoing free: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Self host cost: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Free scenarios: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

Pricing model: Free, no paid plan: No

Pricing model: Free, no paid plan

Typed value: No.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Free plan: Yes cross-checked

Pricing model: Free plan

Typed value: Yes.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Subscription: Yes

Pricing model: Subscription

Typed value: Yes.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Per seat: No

Pricing model: Per seat

Typed value: No.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Usage-based: No

Pricing model: Usage-based

Typed value: No.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Per machine or compute: No

Pricing model: Per machine or compute

Typed value: No.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Pricing model: Bring your own key: Yes cross-checked

Pricing model: Bring your own key

Typed value: Yes.

Happy reuses existing Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP agents use their own login. Bedrock API keys or the AWS credential chain are supported.

  • Agent subscriptions: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Api accounts: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Account switching: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Provider restrictions: Happy reuses Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP use their own login. Bedrock API keys or the AWS credential chain are supported. Happy does not proxy these provider requests.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Models and Subscriptions

    Finding: Happy uses existing Claude Code, Codex and Grok CLI sign-ins, so no Happy plan or pasted key is needed for model access; Antigravity and ACP agents use their own login. Bedrock works with an API key or the AWS credential chain.

Pricing model: One-time purchase: No

Pricing model: One-time purchase

Typed value: No.

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Included usage: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Model cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Compute cost: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

Keeps going with laptop closed: Yes cross-checked

Keeps going with laptop closed

Typed value: Yes.

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

  • Local: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Byo remote: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Self hosted: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Hybrid: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Payer: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Client disconnect: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Other device continuation: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Remote server

    Finding: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

Open-source license: Yes. MIT cross-checked

Open-source license

Typed value: Yes. MIT.

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Client license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Server license: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source visibility: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Source revision: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.
  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

Any desktop app: Yes

Any desktop app

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

Any phone client: Yes

Any phone client

Typed value: Yes.

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • Desktop os: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile apps: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Browser: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Mobile browser: The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.
  • Cli: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.
  • Task actions: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • Cross device continuity: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.
  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

All public findings

Findings may summarize a source. They are not presented as verbatim statements.

happy:ACC-01: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

happy:ACC-01

Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams. Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop. The first-party repository describes the mobile app as available on iOS, Android and web. This establishes the phone web client, not desktop parity.

  • The scoped first-party source pass does not establish editor_extensions, notifications. No hands-on scenario was run.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Mobile access

    Finding: Paired phone apps continue the same encrypted sessions and allow users to read work and respond away from the desktop.

happy:ACC-02: Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI. cross-checked

happy:ACC-02

Happy Agent runs its own loop by default and calls Claude, Codex and Grok models on existing CLI sign-ins. Optional harnesses run Claude Code itself (claude_code) and Codex CLI itself (codex_cli); Gemini runs through Antigravity and OpenCode or other ACP agents through ACP (beta). Grok is a model choice, not a separate harness. Model and effort can change mid-session without discarding the transcript. The original happy CLI wraps Claude Code and Codex directly. Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  • Antigravity is a beta foreign-harness integration using a community ACP adapter and its own login; new sessions are serialized to avoid conversation binding collisions.
  1. Happy: How Happy fits together; Original Happy CLI

    Finding: Happy provides Desktop for macOS, Windows and Linux; mobile iOS, Android and web; and its original happy CLI wrapping Claude Code or Codex. Desktop uses a separate Happy Agent runtime for multi-model sessions and teams.

  2. Happy: Supported providers; Switch models

    Finding: Happy runs Claude, Codex and Grok on the user's existing Claude Code, Codex or Grok CLI sign-ins, Gemini through Antigravity, and OpenCode or other ACP agents on their own login (beta). Model or effort can change mid-session without discarding the transcript.

  3. Happy: Harnesses: Claude Code, Codex CLI, Antigravity, OpenCode, and ACP agents

    Finding: Happy's own harness runs the loop by default; the claude_code harness runs Claude Code itself on a claude account and codex_cli does the same for Codex, while Antigravity, OpenCode and other ACP agents sign in themselves. Grok is not listed as a harness.

  4. Happy Antigravity support at v2026.11.4

    Finding: Happy Agent v2026.11.4 runs the Antigravity whole-agent harness through antigravity-acp@1.2.0, a community ACP adapter driving the signed-in agy CLI.

happy:ACC-03: Happy reuses existing Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP agents use their own login. Bedrock API keys or the AWS credential chain are supported. cross-checked

happy:ACC-03

Happy reuses existing Claude Code, Codex and Grok CLI sign-ins and their subscriptions; Antigravity and ACP agents use their own login. Bedrock API keys or the AWS credential chain are supported.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Models and Subscriptions

    Finding: Happy uses existing Claude Code, Codex and Grok CLI sign-ins, so no Happy plan or pasted key is needed for model access; Antigravity and ACP agents use their own login. Bedrock works with an API key or the AWS credential chain.

happy:ACC-04: Importing registers an existing folder without moving, copying or initializing Git. A project without Git uses a plain folder copy when a workspace is needed. cross-checked

happy:ACC-04

Importing registers an existing folder without moving, copying or initializing Git. A project without Git uses a plain folder copy when a workspace is needed.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Add a project

    Finding: Importing registers an existing folder without moving, copying or initializing Git. A project without Git uses a plain folder copy when a workspace is needed.

happy:ACC-05: Happy Agent exposes a token-authenticated REST API for sessions, streaming events and control on user infrastructure. The original happy CLI is a separate product-owned terminal entry point. cross-checked

happy:ACC-05

Happy Agent exposes a token-authenticated REST API for sessions, streaming events and control on user infrastructure. The original happy CLI is a separate product-owned terminal entry point.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: REST API

    Finding: Happy Agent exposes a token-authenticated REST API for sessions, streaming events and control on user infrastructure. The original happy CLI is a separate product-owned terminal entry point.

happy:ACC-06: Skills are SKILL.md files and MCP servers are mcp.toml entries; agents can write both. MCP tools need Auto or Full access, every Auto call is reviewed, and MCP servers run outside the OS sandbox.

happy:ACC-06

Skills are SKILL.md files and MCP servers are mcp.toml entries; agents can write both. MCP tools need Auto or Full access, every Auto call is reviewed, and MCP servers run outside the OS sandbox.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Skills and MCP

    Finding: Skills are SKILL.md files and MCP servers are mcp.toml entries, shared by every model; an agent can write both. MCP tools need Auto or Full access and every Auto call is reviewed. MCP servers from Codex or Claude Code configuration are not imported.

  2. Happy: What the OS sandbox enforces

    Finding: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.

happy:PLAN-01: The built-in Chief of Staff handles setup and task creation through ordinary conversation, including projects, remote hosts and teams. Persistent standalone issue metadata is not established. cross-checked

happy:PLAN-01

The built-in Chief of Staff handles setup and task creation through ordinary conversation, including projects, remote hosts and teams. Persistent standalone issue metadata is not established.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Chief of Staff

    Finding: The built-in Chief of Staff handles setup and task creation through ordinary conversation, including projects, remote hosts and teams. Persistent standalone issue metadata is not established.

happy:PLAN-03: Subagent trees are capped at depth three and at most five agents including finished children. Sessions have exact agent IDs for messaging and retained follow-up. This is session hierarchy, not verified issue dependency enforcement. cross-checked

happy:PLAN-03

Subagent trees are capped at depth three and at most five agents including finished children. Sessions have exact agent IDs for messaging and retained follow-up. This is session hierarchy, not verified issue dependency enforcement.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Subagents

    Finding: Subagent trees are capped at depth three and at most five agents including finished children. Sessions have exact agent IDs for messaging and retained follow-up. This is session hierarchy, not verified issue dependency enforcement.

happy:PLAN-04: AGENTS.md files in the project tree are read by each agent and reread when they change; global AGENTS.md applies across projects. cross-checked

happy:PLAN-04

AGENTS.md files in the project tree are read by each agent and reread when they change; global AGENTS.md applies across projects.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Add a project

    Finding: AGENTS.md files in the project tree are read by each agent and reread when they change; global AGENTS.md applies across projects.

happy:PLAN-06: Happy creates persistent task records through its API, agent tool and Desktop UI. Native task operations rename task records. Creating a task without opening text stores an idle draft. The task catalog has a task ID separate from its linked agent and workspace IDs; each task has one root conversation. Task state is persisted as active or archived with restoration and versioned updates. Task archival persists and stops the task agent and descendants. Native unarchive restores an archived task.

happy:PLAN-06

Happy creates persistent task records through its API, agent tool and Desktop UI. Native task operations rename task records. Creating a task without opening text stores an idle draft. The task catalog has a task ID separate from its linked agent and workspace IDs; each task has one root conversation. Task state is persisted as active or archived with restoration and versioned updates. Task archival persists and stops the task agent and descendants. Native unarchive restores an archived task.

  • The scoped first-party source pass does not establish discuss, prioritize, label, assign, search, filter, project_epic_views, explicit_dispatch, metadata, external_tracker_requirement. No hands-on scenario was run.
  1. Happy task catalog schema at v2026.11.4

    Finding: Task records have independent task, agent and workspace IDs, owner and creator fields, versioned active/archived state and timestamps. Creation accepts no opening text, allowing an idle draft before work starts.

  2. Happy native task operations at v2026.11.4

    Finding: The TasksModule creates distinct task and agent records, supports rename, join, reorder, archive and unarchive, and persists catalog state. The API and Desktop task creation surface expose the task catalog.

happy:COORD-01: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded. cross-checked

happy:COORD-01

Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Subagents; What Happy Desktop shows

    Finding: Subagents run in the background by default and return completion to the parent. Desktop displays subagents and running tools; tree size is bounded.

happy:COORD-02: Bots and their subtasks may create a full conversation in a new workspace, with the creator as coordinator. Only the creating session may archive that workspace. cross-checked

happy:COORD-02

Bots and their subtasks may create a full conversation in a new workspace, with the creator as coordinator. Only the creating session may archive that workspace.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: How agents work in another workspace

    Finding: Bots and their subtasks may create a full conversation in a new workspace, with the creator as coordinator. Only the creating session may archive that workspace.

happy:COORD-03: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines. cross-checked

happy:COORD-03

Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Subagents; How agents message each other

    Finding: Agents delegate bounded work, choose each child model and effort, receive background completion notices and send follow-ups to finished children with retained context. Exact IDs route messages across projects or machines.

happy:COORD-04: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler. cross-checked

happy:COORD-04

Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Durable waits and scheduled messages

    Finding: Primary sessions can schedule messages to known agent IDs, list or cancel them and survive intervening runtime restarts. Durable waits end early on new input. This establishes scheduled work, not an unrestricted external-event scheduler.

happy:COORD-05: Agent questions remain in the conversation and experimental Inbox; answering on one device closes the shared state. Away presence instructs agents to continue with notes instead of waiting indefinitely. cross-checked

happy:COORD-05

Agent questions remain in the conversation and experimental Inbox; answering on one device closes the shared state. Away presence instructs agents to continue with notes instead of waiting indefinitely.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Inbox and presence

    Finding: Agent questions remain in the conversation and experimental Inbox; answering on one device closes the shared state. Away presence instructs agents to continue with notes instead of waiting indefinitely.

happy:COORD-06: Per-session UI shows phase, tools, background processes, subagents, waiting state, whole-tree token usage and changed files. Fleet navigation has not been measured. cross-checked

happy:COORD-06

Per-session UI shows phase, tools, background processes, subagents, waiting state, whole-tree token usage and changed files. Fleet navigation has not been measured.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What Happy Desktop shows

    Finding: Per-session UI shows phase, tools, background processes, subagents, waiting state, whole-tree token usage and changed files. Fleet navigation has not been measured.

happy:COORD-07: The built-in Chief of Staff configures accounts, imports projects, pairs phones, deploys remote agents and creates teams through conversation. cross-checked

happy:COORD-07

The built-in Chief of Staff configures accounts, imports projects, pairs phones, deploys remote agents and creates teams through conversation.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What you get

    Finding: The built-in Chief of Staff configures accounts, imports projects, pairs phones, deploys remote agents and creates teams through conversation.

happy:RUN-01: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute. cross-checked

happy:RUN-01

Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Remote server

    Finding: Happy Agent can run on an always-on user server while Desktop connects over Tailcat and phones connect through an encrypted relay. Closing the controlling laptop does not stop work on that reachable host. Users supply host compute.

happy:RUN-02: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

happy:RUN-02

Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy. The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container. No VM or microVM isolation backend exists in the inspected runtime; local OS sandboxing and Docker are separate options.

  • The scoped first-party source pass does not establish checkout, process. No hands-on scenario was run.
  1. Happy: How Happy creates a workspace

    Finding: Parallel workspaces use Git worktrees on branches cut from the remote trunk. File sync and setup commands run per workspace; nongit projects use a plain copy.

  2. Happy: What the OS sandbox enforces

    Finding: The documented OS sandbox uses macOS Seatbelt or Linux namespaces and seccomp. Shell writes, network and host sockets are restricted; file tools can still read credential folders, and MCP servers run outside the sandbox. Docker-backed sessions nest that sandbox inside the container.

  3. Happy execution configuration at v2026.11.4

    Finding: The scoped runtime config and runner implementation provide host process execution and optional Docker image/container execution, with OS sandbox restrictions. No VM or microVM isolation backend is implemented in the inspected release. A user provisioning a host VM is separate.

happy:RUN-03: Conversations and child sessions persist across window closure and runtime restart; finished children accept follow-ups with their full context. This is a documentation claim, not a crash test. cross-checked

happy:RUN-03

Conversations and child sessions persist across window closure and runtime restart; finished children accept follow-ups with their full context. This is a documentation claim, not a crash test.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Agents That Never Die

    Finding: Conversations and child sessions persist across window closure and runtime restart; finished children accept follow-ups with their full context. This is a documentation claim, not a crash test.

happy:RUN-04: New workspaces copy configured sync files and run setup_commands. They start with a cold build cache. A failed setup command logs a warning while checkout and file sync determine readiness. cross-checked

happy:RUN-04

New workspaces copy configured sync files and run setup_commands. They start with a cold build cache. A failed setup command logs a warning while checkout and file sync determine readiness.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: How Happy creates a workspace

    Finding: New workspaces copy configured sync files and run setup_commands. They start with a cold build cache. A failed setup command logs a warning while checkout and file sync determine readiness.

happy:RUN-05: Smart provider pools can rotate same-provider accounts after authentication or quota-exhaustion errors. Provider quotas are polled about every fifteen minutes and are observations rather than billing records. cross-checked

happy:RUN-05

Smart provider pools can rotate same-provider accounts after authentication or quota-exhaustion errors. Provider quotas are polled about every fifteen minutes and are observations rather than billing records.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Use several accounts; Provider usage and quotas

    Finding: Smart provider pools can rotate same-provider accounts after authentication or quota-exhaustion errors. Provider quotas are polled about every fifteen minutes and are observations rather than billing records.

happy:RUN-06: Session status includes active tools, background work, subagents, waiting state, tokens and changed files. Deliberate failure and approval consistency after reconnect remain untested. cross-checked

happy:RUN-06

Session status includes active tools, background work, subagents, waiting state, tokens and changed files. Deliberate failure and approval consistency after reconnect remain untested.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What Happy Desktop shows

    Finding: Session status includes active tools, background work, subagents, waiting state, tokens and changed files. Deliberate failure and approval consistency after reconnect remain untested.

happy:RUN-07: Provider quotas are polled about every fifteen minutes and shown in the app; they are observations, not billing records.

happy:RUN-07

Provider quotas are polled about every fifteen minutes and shown in the app; they are observations, not billing records.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Provider usage and quotas

    Finding: Provider quotas are polled about every fifteen minutes and shown in the app; they are observations, not billing records.

happy:TEAM-01: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal. cross-checked

happy:TEAM-01

Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Shared work

    Finding: Team members see the same projects and sessions and can speak to the agent. Changes in speaker include the member name/email; per-member drafts and task ordering stay personal.

happy:TEAM-02: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet. cross-checked

happy:TEAM-02

Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Owner; Sign-in; Leaving

    Finding: Team mode verifies per-user WorkOS tokens. The owner alone renames the installation, toggles global skills or archives others tasks; members otherwise have equal access and can select Full access. A remove-member action is explicitly not built yet.

  2. Happy website source: Set up enterprise JWT sign-in

    Finding: Recipe for a team-mode Happy Agent whose members sign in through the organization's own identity provider (Okta, Entra ID, Google Workspace, Keycloak or internal SSO) instead of Happy's WorkOS accounts; the daemon verifies JWTs from an organization-owned OAuth authorization server and needs an Agent release with enterprise JWT authentication.

  3. Happy Agent TeamJwtConfig at release v2026.11.4

    Finding: The released Happy Agent v2026.11.4 parses a [feature.team.jwt] machine configuration with an authorization URL and exactly one of a JWKS URL, public key or secret, used to verify organization-issued team tokens.

  4. Happy Desktop server sign-in discovery at release v0.0.103

    Finding: The released desktop app v0.0.103 queries a Happy Agent server's v0/authentication endpoint to discover its sign-in methods.

happy:TEAM-03: Read only, Workspace write, Auto and Full access share a permission model. Auto sends boundary-crossing actions to a separate read-only reviewer and grants only that execution if allowed. Reads and workspace edits are not reviewed. cross-checked

happy:TEAM-03

Read only, Workspace write, Auto and Full access share a permission model. Auto sends boundary-crossing actions to a separate read-only reviewer and grants only that execution if allowed. Reads and workspace edits are not reviewed.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Four permission modes; Auto review

    Finding: Read only, Workspace write, Auto and Full access share a permission model. Auto sends boundary-crossing actions to a separate read-only reviewer and grants only that execution if allowed. Reads and workspace edits are not reviewed.

happy:TEAM-04: Session transcripts retain provider-specific opaque data; compaction creates a visible message describing replaced content. No immutable audit retention guarantee was verified. cross-checked

happy:TEAM-04

Session transcripts retain provider-specific opaque data; compaction creates a visible message describing replaced content. No immutable audit retention guarantee was verified.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Switch models; How compaction works

    Finding: Session transcripts retain provider-specific opaque data; compaction creates a visible message describing replaced content. No immutable audit retention guarantee was verified.

happy:TEAM-05: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established. cross-checked

happy:TEAM-05

The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Initial core release; Current interface

    Finding: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.

happy:TEAM-06: Named teammates operate on shared sessions and projects on the same team server. This is not a verified transfer preserving every permission and runtime detail after owner disconnect. cross-checked

happy:TEAM-06

Named teammates operate on shared sessions and projects on the same team server. This is not a verified transfer preserving every permission and runtime detail after owner disconnect.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Shared work

    Finding: Named teammates operate on shared sessions and projects on the same team server. This is not a verified transfer preserving every permission and runtime detail after owner disconnect.

happy:SHIP-01: Happy Desktop shows files and diffs with conversations, and its documentation includes a recipe for a live, shared HTML artifact. No exact-revision cross-task gallery test was run.

happy:SHIP-01

Happy Desktop shows files and diffs with conversations, and its documentation includes a recipe for a live, shared HTML artifact. No exact-revision cross-task gallery test was run.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Initial core release; Current interface

    Finding: The desktop interface has conversations, files, diffs and an attachable terminal; current docs describe changed files beside each conversation. Guided batch review was not established.

  2. Happy: Artifacts

    Finding: The Chief of Staff documentation links a recipe for building a live, shared HTML artifact. No exact-revision cross-task gallery test was run.

happy:SHIP-03: The pinned runtime and clients manage Git workspaces and file changes. They have no built-in PR creation or management path; users can ask a coding agent to use external shell or MCP tools.

happy:SHIP-03

The pinned runtime and clients manage Git workspaces and file changes. They have no built-in PR creation or management path; users can ask a coding agent to use external shell or MCP tools.

  • The scoped first-party source pass does not establish branches, worktrees, commits, comments, ci_response, rebase, conflicts, product_state. No hands-on scenario was run.
  1. Happy Git module and bounded PR integration inspection

    Finding: The pinned runtime Git module and clients provide file changes, branches and workspaces, but no product-owned pull-request creation or management path was found. PRs can still be operated through an external shell command or MCP service; that is not a built-in Happy PR workflow.

happy:OWN-01: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate. cross-checked

happy:OWN-01

The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: MIT License

    Finding: The mobile app, original CLI and relay repository has the MIT license. Happy Desktop documentation also explicitly describes its app/runtime as MIT. Hosted and provider services remain separate.

happy:OWN-02: The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies. cross-checked

happy:OWN-02

The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: How a Happy team server works

    Finding: The core Happy Agent runs self-hosted on user machines or servers, with Desktop connecting remotely. Happy Social/WorkOS team sign-in and the mobile relay are distinct service dependencies.

happy:OWN-03: Happy apps send pseudonymous usage events to PostHog, excluding message content, prompts, code and file names, and offer a Settings opt-out that stops them; the desktop app has its own switch. Happy Agent itself sends no analytics. cross-checked

happy:OWN-03

Happy apps send pseudonymous usage events to PostHog, excluding message content, prompts, code and file names, and offer a Settings opt-out that stops them; the desktop app has its own switch. Happy Agent itself sends no analytics.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: Analytics: PostHog

    Finding: Happy apps send pseudonymous product usage events to PostHog, excluding message content, prompts, code and file names, and offer a Settings opt-out that stops them; the desktop app has its own switch. Happy Agent itself sends no analytics.

happy:OWN-04: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate. cross-checked

happy:OWN-04

Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: Happy is free and MIT licensed. Model use is paid through existing subscriptions and user compute. Phone voice has twenty free minutes per thirty days and an optional paid allowance; custom ElevenLabs use is separate.

happy:OWN-06: Happy Agent v0.4.108 adds GPT-6.1 Terra and stop-state persistence; Desktop v0.0.102 has opt-in beta Stem cells. Current release activity does not imply all experimental UI is enabled by default. cross-checked

happy:OWN-06

Happy Agent v0.4.108 adds GPT-6.1 Terra and stop-state persistence; Desktop v0.0.102 has opt-in beta Stem cells. Current release activity does not imply all experimental UI is enabled by default.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: October 26, 2026

    Finding: Happy Agent v0.4.108 adds GPT-6.1 Terra and stop-state persistence; Desktop v0.0.102 has opt-in beta Stem cells. Current release activity does not imply all experimental UI is enabled by default.

happy:OWN-08: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance. cross-checked

happy:OWN-08

The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The desktop application and self-hosted runtime are free. Model subscriptions and host compute are separate costs; optional phone voice has its own allowance.

happy:OWN-09: The core ADE has no software subscription charge; coding-model subscriptions, host resources and optional voice are separately scoped. No standardized task-scenario total was invented. cross-checked

happy:OWN-09

The core ADE has no software subscription charge; coding-model subscriptions, host resources and optional voice are separately scoped. No standardized task-scenario total was invented.

  • Documentation evidence only. Remaining atomic questions and enforcement under failure have not been established by a bounded workflow test.
  1. Happy: What does Happy cost?

    Finding: The core ADE has no software subscription charge; coding-model subscriptions, host resources and optional voice are separately scoped. No standardized task-scenario total was invented.