Compare

Hedy vs Junior

Both sell the same idea — an AI employee, not a chatbot. The fork in the road is where it runs and who holds the keys. Junior is a cloud service; Hedy deploys inside your walls.

Hedy is a private-deployment AI employee: it runs on your own Docker/K8s or air-gapped infrastructure, uses your own model keys (including local vLLM/Ollama), and prices per seat. Cloud AI employees like Junior run on someone else's servers, meter you by usage credits, and hold your data in their tenant. Hedy keeps source-of-truth, retrieval ACLs, and append-only audit inside your perimeter, and is Feishu/Lark-native alongside Slack. One Hedy replaces a team's output, not a chat seat.

At a glance

HedyJunior
Where your data livesYour VPC — or fully air-gappedVendor cloud (AWS)
On-prem deploymentYes — Compose or HelmNot offered today
Source auditableYes, by your security teamNo
Chat platformsFeishu & Lark first-class, plus SlackSlack & Microsoft Teams
Model keysYours — incl. local modelsVendor-managed
Pricing modelFlat per-seat licenceUsage credits, from $100/mo
Conduct red-line testingShipped in the eval gateUndisclosed
Integration breadthCore enterprise stack, growing3,000+ via connectors

Based on public information as of July 2026. Corrections welcome: hello@hedy.one

Where Junior shines

  • Live in minutes — no infra, no ops burden
  • Broadest integration catalog (3,000+ tools)
  • Consumer-grade polish and onboarding
  • A fit when your team lives in Slack/Teams and cloud SaaS is fine

Where Hedy wins

  • Data residency: knowledge, memory, audit and metering stay in your Postgres
  • Deploys air-gapped with local models — regulated industries welcome
  • Feishu / Lark native for CN-market teams
  • Flat seat pricing: an employee working harder costs nothing extra
  • Governance you can read: allowlists, approval tiers and audit are code, not policy pages

Which should you choose?

Choose Junior if you want an AI employee today with zero infrastructure and your compliance bar allows vendor cloud. Choose Hedy if your knowledge base, chat history and credentials must not leave your network — or your team works in Feishu/Lark. Same species, different custody model.

In depth

The core split is where the work runs. A cloud AI employee lives in someone else's tenant: your prompts, retrieved documents, and outputs cross their boundary, and you accept their sub-processors. Hedy deploys into your own infrastructure via Docker or Kubernetes, and runs air-gapped when you need it. There are no sub-processors. You bring your own model key and point it at a hosted API or a local vLLM/Ollama endpoint, so inference can stay inside the same network as your data. A typical compose deploy takes about 30 minutes.

Pricing follows the model. Cloud AI employees meter you on usage credits, so cost scales with every token and every retry, and forecasting is guesswork. Hedy is priced per seat, and every LLM call routes through one gateway that owns metering and quota, so spend is one number you control, not a variable bill from a vendor. Licensing is offline: an Ed25519-signed license validates without phoning home, which is what an air-gapped or regulated deployment actually requires.

Governance is the product, not a setting. Retrieval is ACL-scoped to the asker, so an AI employee never surfaces documents a person could not open themselves. Write actions are deny-by-default against an allowlist, with tiered approvals (L0/L1/L2) for anything that leaves a mark. The audit log is append-only with no update or delete path. An evidence gate requires answers to quote their sources verbatim, so claims are traceable rather than plausible. Red-line behavior tests run against the agent instead of trusting instructions in a prompt.

On integration, Hedy treats Feishu/Lark as a first-class channel alongside Slack, so the AI employee works where your team already coordinates rather than forcing a US-centric stack. The framing is different too: a cloud AI employee is one more seat in a chat workspace; one Hedy is meant to produce the output of a team. Private, not cloud. An employee, not an assistant. Doing the job, not recording the meeting.

Questions

Is Hedy cloud-hosted like other AI employees?
No. Hedy is deployed on your own infrastructure via Docker or Kubernetes, and supports fully air-gapped installs. There are no sub-processors and no vendor tenant holding your data. Cloud AI employees run on the vendor's servers; Hedy runs inside your perimeter, so prompts, retrieved documents, and outputs never leave your network.
How does Hedy's pricing differ from usage-credit AI employees?
Hedy is priced per seat, not per token. Every LLM call routes through a single gateway that owns metering and quota, so cost is a fixed, predictable number you control. Usage-credit models charge for every token and retry, which makes forecasting hard and ties your bill to the vendor's meter rather than yours.
Can Hedy use our own model instead of a fixed provider?
Yes. You bring your own model key and point Hedy at a hosted API or a local vLLM/Ollama endpoint. That means inference can run inside the same network as your data, which cloud AI employees generally cannot offer since they route through their own provider account.
What stops an AI employee from leaking data or acting without approval?
Governance is enforced in code, not prompts. Retrieval is ACL-scoped to the person asking, write actions are deny-by-default against an allowlist with L0/L1/L2 approval tiers, the audit log is append-only, and an evidence gate forces answers to quote sources verbatim. Red-line behavior tests validate these limits directly.

Related

hedy.one

See Hedy on your own infrastructure.

Book a demo