Trigger.dev alternatives for agent background jobs

A parent task retries and triggers the refund task again. You add a Trigger.dev idempotency key so the child is created once. The child's run function still throws after the provider accepts the refund. Trigger.dev retries run from the top. The provider sees a second refund.

This post separates a background job from an agent-initiated call, and shows which retry key protects which one.

What the task retry covers

Tasks retry when run throws. The default maxAttempts is 3, including the first try. You can set backoff, a minimum delay, a maximum delay, and jitter. How it works says a retry starts from the beginning and can reuse cached results of completed subtasks.

Idempotency is explicit. An idempotency key on trigger stops a second run from being created. It does not make the code inside run idempotent. When run retries, every API call in it happens again unless that call is idempotent. Moving the refund into a child task with a trigger key does not close the gap. The child is triggered once, and its own run can still retry after the provider accepted the request. Only the provider can collapse that duplicate. Trigger.dev says to pass the provider key, and that ctx.run.id stays stable across attempts of the same run.

What the October 2026 bill includes

The pricing page lists Free at $0 with $5 of credits a month, 20 concurrent runs, and 1-day log retention. Hobby is $10 a month with $10 of credits, 50 concurrent runs, and 7-day logs. Pro is $50 a month with $50 of credits, 200 concurrent runs, and 30-day logs. Every production run that starts is $0.000025, plus compute. The default Small 1x machine is $0.0000338 a second. Dev runs are not charged the invocation fee. You pay while the task is executing.

That is a bill for workers and run starts. It is not a count of provider side effects.

Background jobs and calls the agent starts

Use Trigger.dev when the work should leave the request and run for a long time. Video, multi-day mail, a chain of AI steps. The queue, the machine, and the retry of the task are the product. Durable execution platforms compares that shape.

An agent-initiated call is different. The user is waiting, the model just chose a method, and you need a yes or no before the provider sees the body. A background retry from the top is the wrong place for that decision. Swytchcode checks the method you enabled and can block on arguments. POST and PATCH retries need an idempotency key set. On the October 2026 pricing page, allow and deny are on every plan, including Free at 100 live commands. Policy as code is the rule. Put the long job in Trigger.dev. Put the provider call, and its key, where a retry cannot change the amount.

Watch a refund task that also writes an audit row. The provider accepts the refund. The audit insert fails. run throws, and the next attempt starts at the top. Cached child tasks can be skipped if you keyed them. The refund call in the body of run is not a child task. It goes out again. Compute billing continues for each attempt, at the machine rate, even though the business outcome already happened. Lower maxAttempts on tasks that spend money. Use AbortTaskRunError when the error cannot succeed on a second try, such as a rejected card with a clear decline code. Keep retries for timeouts. And still send the provider key, because a timeout is the case where you do not know whether the first call landed. A cached child task saves compute. It does not save you from a second provider request that lived in the parent run. If a new trigger can start a new run for the same order, key the provider call on the order id, not only on the run id.

Use both keys on purpose

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry, copy the ID from the local list, and add it. Inside the task, send the provider idempotency key from ctx.run.id or from the order id.

swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. Validate the policy for any cap.

swy auth connect <provider>
swy policy validate

Keep Trigger.dev for the job that should survive the web request. Send the provider a key that does not change when run starts over. A trigger key stops a second run. It does not stop the body of run from calling the provider again after a crash. Use the order id for that provider key.

Related reading

• Durable execution platforms. Queues and resume logic, separate from one provider call.
• Policy as code. A cap on the call, including the retry.
• Log every API call an agent makes. Run logs and provider responses are different.
• Human approval. A background retry should not approve itself.

FAQ

Does a Trigger.dev idempotency key stop a double charge?

It stops a second trigger from creating a second run. It does not stop run from calling the provider again on a retry. Trigger.dev's docs say only the provider key closes that gap.

How many attempts is the default?

maxAttempts defaults to 3, and that count includes the first try. You can raise it, or throw AbortTaskRunError when another try cannot succeed.

What is a production run charged?

$0.000025 when it starts, plus compute for the seconds it executes. The default Small machine is $0.0000338 a second. Dev runs skip the invocation fee. Free includes $5 of credits and 1 day of logs.

Should the agent enqueue every provider call?

Enqueue work that can finish later. Do not enqueue the decision of whether this amount may be sent. Make that decision before the call, then let the job retry with a stable provider key.