Running Two Automated Content Pipelines From One Claude Code Session

Published 2026-09-30

I run two separate content pipelines right now, one for this site and one for a client's, both fully automated: a nightly planning cycle, a timed publish, and for one of them a connection-growth loop firing every 30 minutes overnight. None of it runs through Windows Task Scheduler anymore, all of it runs from crons scheduled inside a live Claude Code session. That setup replaced something that kept quietly failing, worth explaining what broke, what the fix actually is, and the two tradeoffs that come with it.

The Problem With Task Scheduler And An API Key

Task Scheduler needed a way to actually run Claude Code unattended, and the only way to do that headlessly was an API key. The API key kept running out. Twice in under a week.

The worse part was not the credit running out. It was that `claude.exe -p` returns exit code 0 even when it fails a credit check before doing any real work.

Task Scheduler saw a successful run every single time. The pipeline went quiet for two days before I noticed, because nothing in the logs said it had failed.

I needed something that could not silently pretend to succeed.

The Fix: Scheduling Inside A Live Session

A recurring cron running inside a live, resident Claude Code session replaced Task Scheduler entirely. No API key involved anywhere, billed as normal subscription usage, same as any other work I do in that session.

I've written before about the exact API-billing failure mode this replaced, so I won't repeat the full story here.

If a job fails now, I see it fail, in the same conversation, in real time. There is no separate process quietly returning a fake success code somewhere else.

The Precise-Trigger Pattern

Polling every 15 minutes to check "is it time yet" was the first version of this, copied from an older Task Scheduler habit. I dropped it.

The pattern now: a nightly recurring job decides the exact date and time the next piece should publish, then schedules a separate one-shot job for that exact moment. Nothing checks in between.

The one-shot job fires once, does its work, and is gone. No wasted runs, no 15-minute slop on the actual publish time.

What This Makes Possible

Two independent pipelines run side by side from the same session right now. One handles a nightly content cycle end to end, research, drafting, and a timed publish. The other runs a completely separate 30-minute recurring loop overnight for connection growth, unrelated to the content pipeline entirely.

Neither one touches the other's schedule or state. They just happen to share the same underlying scheduling mechanism, inside the same session.

A Concrete Example: Pacing A Connection Loop Without Tripping Detection

The 30-minute recurring loop I mentioned sends one LinkedIn connection request per firing, nothing more, even if a firing gets missed and there is a gap to catch up on. LinkedIn actively restricts accounts for automated connection behavior, so pacing is the entire point of the design.

I learned early not to trust the button's own visual state as proof anything happened. A Connect click sometimes shows no change at all, no modal, no "Pending" label, and still genuinely did nothing.

Other times the exact same click works fine on the next attempt with zero code changes in between.

The fix was checking the actual sent-invitations list after every attempt instead of trusting the button. That signal turned out to be unreliable in both directions, both false negatives and false positives showed up over enough attempts.

The Two Real Constraints

The session has to stay open. Close the window and every scheduled job disappears silently, no warning, no log entry saying it happened. There is no equivalent of Task Scheduler's "start when available" here.

Recurring jobs also auto-expire after seven days on their own. I found this out the hard way. A nightly cron expired without me noticing, and the pipeline it ran went quiet for two full days before I asked why.

The fix is checking on it, or setting a reminder near the expiry window, since nothing renews it automatically.

Both constraints are worth knowing before building around this the way I did. It works well for what it's actually doing, but it is not a replacement for infrastructure that needs to survive a closed laptop lid.

I've run into this same "the tool can quietly stop working" risk before with Claude Code, just for a different reason that time.