Published: 2026-09-16
Deep dive

Build automations with GPT-6 Astra in Codex, host them on trigger.dev so they don't eat your limit

Chapters / key moments (click to jump — plays here on the page)

Codex scheduled tasks work, but each run is a chat turn billed to your weekly limit. Most automations are deterministic pipelines with one or two AI steps, so they don't need an agent loop at runtime. The pattern here uses the agent to build the automation and plain code to run it. That cuts cost, and it also stops the drift he saw when a Codex routine began messaging the wrong channels after a month.

Source video

"How to Build GPT-6 Astra Automations (that don’t eat your usage limit)" by Nate Herk — Watch on YouTube →

Step-by-Step Breakdown

Decide whether it needs an agent at all.
Draw the flow. The 6am brief is trigger → read calendar → decide on research (AI) → draft message (AI) → send to ClickUp. The order is fixed and only two steps are non-deterministic, so it should be code with two model calls, not a standing agent. He estimates 90% of business automations look like this.
Plan with Astra before building.
Describe the automation and let Codex ask questions: delivery target (a ClickUp DM), schedule (weekdays 6:00 America/Chicago), calendar scope, research boundaries, and a per-run cost cap (he set 25¢).
Keep API keys in a .env, not in harness plugins.
Codex plugin connections don't move to trigger.dev. Keys in one .env can be copied to any host. If you lack a key, ask Codex where to get it.
Build and verify locally first.
Ask Codex to test end to end before moving anything. It used test-driven development, sent a real test DM, and hard-coded the channel ID so the script can't send anywhere else. His test brief cost about 1.33¢.
Connect GitHub and trigger.dev from the CLI and deploy.
Have Codex authenticate both CLIs (a browser sign-in each), create a private repo, and push. .env, calendar snapshots and anything sensitive stay out of git. Codex copied the env vars into trigger.dev itself and used its browser to verify the GitHub integration. Trigger.dev split the job into a scheduled task that calls a runner task.
Test in production.
Use Test schedule → Run test in trigger.dev. Read the run's payload and status. When something is off, paste the run into Codex.
Webhook-triggered version.
With /goal, he had Codex build a local form (name, email, team size, need) whose submission triggers a second trigger.dev task. That task drafts an outreach suggestion and DMs it to him. Afterwards, have sub-agents try to break the form: spam submissions, malformed emails.
Third type: a Codex SDK automation.
For work that really is open-ended, the last part of the video calls the Codex SDK from hosted code. You still get a full agent loop, but it is triggered programmatically instead of living as a chat routine. Use this only where the steps genuinely vary from run to run.

Common Errors & Fixes Covered

Error: hosted run finishes with status: disabled, no message sent

Why it happens: an enable-flag environment variable for the brief was set to false in trigger.dev's environment variables. Codex had deliberately left delivery off until a hosted test passed.

Fix: Deployments → Environment variables → set the flag to true → re-run the test.

Error: run reports delivered but no new DM appears

Why it happens: duplicate prevention. That day's brief had already been sent, so the script skipped sending it again. This is working as designed.

Fix: none needed. Override it once only if you want proof of delivery.

Gotchas & Caveats

Trigger.dev's free plan scheduling window can delay a 6am job by up to an hour.
Codex may create the trigger.dev project in a different organisation than the one you're looking at. Check the org switcher before assuming nothing deployed.
Genuinely open-ended tasks, where the steps differ every run, still belong in an agent routine. This pattern is for fixed pipelines.
The video includes a sponsor segment (Hyper Agent).

Key Takeaways

Use the frontier model to build the automation, not to run it every morning.
Hard-coding destinations removes a whole class of agent drift.
A per-run cost cap and duplicate-send protection belong in the spec from the start.