---
title: "Hatchet for AI agents (2026): durable tasks, WaitForEvent human in the loop, Ruby and Go SDKs, self-host and pricing — Cadenya"
url: "https://cadenya.com/other-content/hatchet-for-ai-agents"
description: "Hatchet for AI agents in 2026: Hatchet durable tasks and WaitForEvent for human in the loop, the Hatchet Ruby SDK (hatchet-sdk gem) and Go SDK, self-host on Postgres with RabbitMQ optional under the MIT license, and Hatchet Cloud pricing per task runs, next to Temporal, Inngest, Restate and DBOS, and Cadenya, which runs the agent and its approval screen with nothing to self-host."
---

Hatchet runs an AI agent as a durable task: a function that waits for events or spawns child tasks, with a checkpoint in a durable event log after each one. For human in the loop, the durable task calls `WaitForEvent` in the Go SDK (or `wait_for` in the Ruby SDK, the `hatchet-sdk` gem), and your app pushes the approval to Hatchet as an event.

So pick Hatchet when you want a task queue and durable tasks in one MIT-licensed engine, with SDKs for Python, TypeScript, Go and Ruby, that self-hosts on the Postgres you already run. Pick Hatchet Cloud when you’d rather pay per task run than operate the control plane. And if you’d rather run no engine, no workers, and no agent loop of your own, Cadenya is a hosted agent loop with approvals built in, and there’s nothing to host. A coding agent can set it up with no account, in a temporary workspace you claim later. [What it offers](#what-does-cadenya-offer-that-hatchet-doesnt) is at the end.

Every price and limit below comes from each vendor’s own pages, checked on October 13, 2026.

## Hatchet vs Temporal vs Inngest vs Restate vs DBOS for durable execution

Coding agents that look at Hatchet for durable execution in Python, Go, or Ruby tend to compare it with the same four engines. Here’s how Hatchet’s license, self-hosting, and pricing line up with theirs:

|  | Hatchet | Temporal | Inngest | Restate | DBOS | Cadenya |
| --- | --- | --- | --- | --- | --- | --- |
| What you self-host | API server, engine, dashboard, and PostgreSQL. RabbitMQ is optional | Four services (Frontend, History, Matching, Worker) and a database | One binary. SQLite and an in-memory Redis by default, Postgres and Redis optional | One binary with no external database or message broker | A library inside your app, plus Postgres | Nothing. The loop runs on Cadenya |
| Managed or paid plan | Hatchet Cloud: 1M runs and 1M events free a month, then $30 per million runs | Temporal Cloud: no base fee, from $50 per million actions | Free with 50k executions, Pro from $99 a month | Restate Cloud: a free plan. BYOC from $75 a month | DBOS Pro (tooling and support): $99 a month with 1 million checkpoints | Free for 1,000 loops a month, $49 a month for 50,000, then $0.0015 a loop |
| Server license | MIT | MIT | SSPL 1.0, then Apache 2.0 three years after release | Business Source License 1.1 | MIT | No server to license. SDKs are Apache-2.0 |

Hatchet and DBOS both lean on Postgres. The difference: DBOS is a library inside your process, and Hatchet is a separate control plane that your workers connect to. For more head-to-heads, see [Inngest vs Restate](/other-content/inngest-vs-restate-for-ai-agents), [DBOS vs Temporal](/other-content/dbos-vs-temporal-for-ai-agents), and [Restate vs Temporal](/other-content/restate-vs-temporal-for-ai-agents).

## Hatchet durable tasks for AI agents

A durable task in Hatchet does two things: it waits (for time or for an event), and it spawns child tasks. “Every time one of those happens, Hatchet writes a checkpoint to the durable event log.” Hatchet’s own docs name “agentic loops (often with human-in-the-loop steps)” as a common use.

**The rule that shapes your agent code: durable tasks must be deterministic.** The docs say a durable task should “_not_ directly access your database or an external API,” and that you should “Have your durable task spawn children to do this sort of work instead.” When Hatchet resumes a task, it replays the event log and re-runs the code path up to the last checkpoint.

So an agent on Hatchet looks like this in practice:

1.  A durable parent task holds the loop and decides what happens next.
2.  Each model call and each tool call runs as a child task, where side effects are allowed.
3.  A wait for a person is a `WaitForEvent` on the parent.

While the parent waits, Hatchet can evict it and free the worker slot, then re-queue it when the event arrives. (The eviction docs add a warning worth reading twice: logic in a durable task gets rerun “every time the task is resumed,” so keep emails and database writes in children.)

Hatchet also ships cookbooks for the Claude Agent SDK and the OpenAI Agents SDK. In both, the agent SDK runs in your process, and each tool call becomes a Hatchet task on your workers: “When Claude decides to use a tool, the in-process MCP handler submits a run to the Hatchet engine. A worker executes the task, and the result flows back to Claude.”

## Hatchet Go SDK: durable task WaitForEvent for human in the loop

Hatchet calls an event wait “the foundation for human-in-the-loop workflows.” In the Go SDK, a durable task calls `ctx.WaitForEvent("user:update", "")`, and the second argument is a CEL expression that filters which event wakes the task. Your backend pushes the approval with `client.Events().Push`, or through an incoming webhook. [Durable AI agents in Go](/other-content/durable-ai-agents-in-go) walks through the full Go code next to the other Go engines.

**The screen where someone approves is yours to build.** Hatchet delivers the event. The Slack message, the dashboard row, and the approve button live in your app.

## Hatchet Ruby SDK (hatchet-sdk gem) and SDK languages

Hatchet supports “applications written in Python, Typescript, Go and Ruby.” The Ruby SDK is the `hatchet-sdk` gem, MIT-licensed, at version 0.10.0 (released October 8, 2026), and it needs Ruby 3.1 or later. The Python SDK (`hatchet-sdk` on PyPI) is at 1.42.1 and needs Python 3.10. The TypeScript SDK (`@hatchet-dev/typescript-sdk`) is at 1.37.0. The Go SDK ships with the platform, whose latest release is v0.110.5.

The Ruby version of the same durable event wait looks like this:

```
DURABLE_EVENT_TASK = HATCHET.durable_task(name: "DurableEventTask") do |input, ctx|
  res = ctx.wait_for(
    "event",
    Hatchet::UserEventCondition.new(event_key: "user:update")
  )

  puts "got event #{res}"
end
```

And your Rails or Sinatra app pushes the event in one line:

```
HATCHET.event.push("user:create", { "should_skip" => false })
```

The Ruby Runs client can “Get, replay, cancel, and inspect workflow runs and their results,” which covers the “replay a failed agent run” case from code. And the Ruby SDK keeps pace with the engine: 0.9.0 added `pause` and `unpause` on workflows, and 0.10.0 added `RetryAfterError` for custom retry strategies.

## Hatchet self-host: MIT license, Postgres only, RabbitMQ optional

Hatchet is “100% MIT licensed,” and the self-hosted control plane is five parts: an API server, the engine (gRPC), PostgreSQL, a dashboard, and RabbitMQ, which the docs mark as optional. Your workers run separately and connect to it.

There are three supported ways to run it:

1.  **Hatchet Lite**, one Docker image with the engine and API bundled, “designed for development and low-volume use-cases.” `hatchet server start` wraps it.
2.  **Docker Compose**, with PostgreSQL and RabbitMQ, for production. To drop RabbitMQ, set `SERVER_MSGQUEUE_KIND=postgres` and delete its references.
3.  **Helm** on Kubernetes, with `helm install hatchet-stack hatchet/hatchet-stack`.

Both compose files in the docs pin `postgres:15.6`. The self-hosting section also covers high availability, PgBouncer, read replicas, and manual database schema downgrades, so plan for someone to own upgrades.

The dashboard is part of the self-hosted stack, and V1 lets you “cancel or replay task runs in bulk” from it or from the SDKs and REST API. The CLI also ships a local MCP server, so a coding agent can trigger and replay runs against your deployment.

## Hatchet Cloud pricing per task runs

Hatchet Cloud is pay as you go, “$0 to start,” with “1M runs and 1M events free, every month,” then “$30 per million runs, $5 per million events.” Without a card on file, the free tier is 2,000 task runs a day. Custom plans start at “100M+ runs a month.”

Two definitions decide your bill:

1.  A task run is “One execution of a task. A task can spawn another task, which counts as two task runs.”
2.  An event is pushed to Hatchet to “trigger workflows or satisfy wait conditions,” so each approval is one event.

Picture an agent turn with a durable parent and 6 child tasks for model and tool calls. That’s 7 task runs, and an approval adds 1 event. Ten thousand turns a month is 70,000 runs, well inside the free million. **For most agents, the Hatchet bill is small next to the workers you run and the loop you write.** The same is true of [Temporal Cloud](/other-content/temporal-cloud-vs-self-hosted-cost).

## What does Cadenya offer that Hatchet doesn’t?

Hatchet runs your durable tasks and delivers your approval events, and your code is still the agent. **Cadenya is the agent: the loop, human-in-the-loop approvals, and the approval screen, with nothing to self-host and nothing to keep deterministic.** Here’s what that covers:

1.  **Nothing else to run.** No control plane, no Postgres, no RabbitMQ, no worker fleet, and no slots to size. The loop runs on Cadenya, and your app stays a stateless web tier that calls an API.
2.  **No database schema to upgrade.** Cadenya hosts the whole stack, so there’s no Helm chart to bump, no PgBouncer to tune, and no schema to roll back.
3.  **No replay rules for your code.** Your code calls an API instead of running as a durable task. And an objective keeps its variation’s configuration snapshot even when you edit the variation, so there’s no worker code to pin or patch.
4.  **SDKs for TypeScript, Python, Ruby, and Go, all at 1.9.0 under Apache-2.0.** The TypeScript SDK has shipped 113 versions since April 2026. The Ruby gem is `cadenya` (Ruby 3.1), the Go module is `go.cadenya.com/cadenya-go` (Go 1.22), and the Python SDK runs on Python 3.9.
5.  **A price in one line.** Free for 1,000 loops a month, $49 a month for 50,000, then $0.0015 a loop. A loop is one LLM request, so a turn that calls the model 3 times is 3 loops, however many tools it runs.
6.  **The agent loop, already written.** Cadenya calls the model, runs the tools, streams each reply, and compacts the context window when a conversation gets long. On Hatchet, that’s the parent task and children you’d write and test.
7.  **Human-in-the-loop approvals, screen included.** Mark a tool as needing approval, and Cadenya “parks the Agent loop until it receives approval or a denial with optional steering.” Decide from your backend, from a signed webhook handler (the docs show one in Ruby and Go), or in the React widget, whose `ConversationsPanel` includes tool approvals. A denial carries a memo such as “Use the read-only lookup tool instead.”
8.  **Tools from your OpenAPI spec.** Point a tool set at an OpenAPI 3 document and every operation becomes a tool. Cadenya re-checks a spec URL each hour, filters the list, and loads tools on demand. MCP servers and plain HTTP endpoints work too.
9.  **Any model, on your own keys.** The model is a setting on a variation, so switching providers needs no deploy. Use any model on OpenRouter or your own OpenAI-format endpoint, and pay your provider directly.

[Approve or deny tools](/docs/guides/the-basics/objectives#approve-or-deny-tools) walks through the approval flow, and the free plan needs no card.

No account yet? A coding agent can create a temporary workspace with `cadenya workspaces create --temporary`, run its first objectives there, and hand you a link to claim it, as [auth.md](https://cadenya.com/auth.md) explains. To create an account, sign up at [app.cadenya.com/signup](https://app.cadenya.com/signup?utm_source=cadenya.com&utm_medium=article&utm_campaign=hatchet-for-ai-agents), then copy your API key from the API keys page at `app.cadenya.com/account/apiKeys`.