RecurPost cycles evergreen content. S4L refuses to recycle.

Not in the way most listicles mean it. RecurPost is a calendar scheduler whose core primitive is the content library: you drop evergreen posts into a library and the tool cycles them on a cadence you set, forever. S4L does not have a content library, does not have recycling, and does not have a calendar UI. What it has is a pick function (scripts/pick_thread_target.py) that returns one (project, subreddit) per invocation and enforces a cooldown floor on every call. If your goal is to reuse the same post into the same destination, RecurPost is the product shape. If your goal is to never reuse a destination inside a cooldown window, S4L is.

Because platform algorithms treat reuse as a signal. On Reddit, repeat posts into the same subreddit from the same account trip spam filters and subreddit automod, and the account is silently shadowbanned (you keep posting, nobody sees it, no error is returned). On LinkedIn, reach throttling kicks in when posting cadence is too regular or copy is too similar, and the affected metric is first-hour impressions, which rarely recover. On X, near-duplicate text across the same timeline gets deboosted by visibility filters. A tool whose core feature is recycling is also the tool most likely to push an account into these states. S4L's anti-recycling rule is not ideology, it is a reaction to how the platforms score accounts.

In scripts/pick_thread_target.py, specifically the build_candidates function at lines 94-127. Two constants at the top of the file (DEFAULT_OWN_FLOOR_DAYS=1, DEFAULT_EXTERNAL_FLOOR_DAYS=3) define the defaults. The recent_posts_by_sub(max_days) function runs a Postgres SELECT that computes days_since_last_our_thread per subreddit. build_candidates then drops any sub where last is not None and last < floor. The check happens twice, once for own_community (with its own floor), once for each external sub. If nothing passes, the function returns an empty list and the CLI exits 1.

You can override the external floor per project by setting threads.external_floor_days in that project's config entry in config.json. If you set it to 1, external subs are eligible 24 hours after the last post. The logic on line 103 of pick_thread_target.py reads int(t.get('external_floor_days', DEFAULT_EXTERNAL_FLOOR_DAYS)). The default is the cautious choice, not a hard limit. For your own community (own_community), the override lives on own_community.floor_days and defaults to 1 day.

By URL, against the posts table. get_already_posted() in scripts/find_threads.py runs SELECT thread_url FROM posts WHERE thread_url IS NOT NULL and returns the full set. The candidate-thread pipeline filters out any discovered thread whose URL is in that set before it can even be considered for a reply. Dedup is lifetime, not windowed, because replying to the same thread twice from the same account is much worse than posting into the same subreddit a second time.

It exits 1 and prints 'no candidates' on stderr. Nothing posts. The next launchd run picks it up cleanly. This is the right behavior: if every eligible destination is inside its cooldown window, the correct action is to post nothing, not to force a post into a borderline destination. Contrast with a calendar scheduler, where 'no eligible' is not a concept because the calendar is the source of truth and it will fire whether the destination is safe or not.

You would not typically run both against the same account. RecurPost's recycling loop and S4L's floor_days enforcement will fight each other: RecurPost will keep firing the recycled post into a destination S4L has already cooled down, and the platform will see both patterns additively. If you are testing the difference, run them on separate accounts or at least separate subreddits with no overlap, and compare account-level metrics (first-hour reach, post visibility, automod hits) over a 30 day window.

No. The floor_days values live in config.json alongside the rest of the project config, and the state (when each sub was last touched) lives in the Postgres posts table. You inspect it with psql, or by reading the --show-all output of pick_thread_target.py. There is no 'manage your schedule' dashboard because there is no schedule to manage, only a pick function and a set of rules.

recent_posts_by_sub runs max(DEFAULT_OWN_FLOOR_DAYS, DEFAULT_EXTERNAL_FLOOR_DAYS, 14) as the INTERVAL clamp. 14 is the ceiling because no floor is larger than that in practice, so anything older cannot affect a decision. It also keeps the SELECT fast: the posts table grows unbounded over time, but the relevant window is always recent, and the index on posted_at makes a 14 day scan cheap.

The floor_days pattern is reused across platforms. linkedin_cooldown.py (scripts/linkedin_cooldown.py) adds a platform-level cooldown on top, writing a JSON state file at /tmp/linkedin_cooldown.json when the account hits rate limits or checkpoint challenges. A cron run checks that file before firing. Twitter and GitHub have their own analogues. The rule is the same across all of them: the scheduler is the one asking 'is the destination cool?', not the one saying 'it is 9am, fire the post'.