Auto-generate Reddit reply templates: a self-tuning distribution, not a prompt list

Why a static template list rots

Every off-the-shelf Reddit reply tool ships with a single prompt that says something like "write a helpful, on-topic comment in a natural Reddit voice." You paste a thread URL, you get a draft, you ship it. After the first 30 replies, your output starts to feel exactly the same. That is not a model problem. It is a taxonomy problem. A single prompt collapses to a single voice because it has no way to ask "what kind of reply does this thread want?"

The fix is to split the work in two. First, decide on a tone. Second, write inside that tone. The tone is the template; the writing is the model. Most published reply prompts conflate the two and inherit the average of their training data across all Reddit comment shapes. The result reads like a person who is trying to sound like Reddit instead of a person who is on Reddit.

The seven baseline templates

Below is the full taxonomy from scripts/engagement_styles.py in the open-source S4L repo. The names matter; pick names you can hand to a model without further explanation. Each template ships with a one-line description, a worked example utterance, a per-platform best_in subreddit list, and a note about when it fails. Treat them as the smallest set that covers the shapes Reddit actually rewards. You can rename them, but you cannot collapse them, because each one selects for a different conversation move.

The full source for each template (description, example, best_in, note) is in the STYLES dict at lines 31-133 of scripts/engagement_styles.py.

The four constants that turn it from a list into a picker

Once the templates exist, you need a function that picks one. A pure argmax over historical avg_upvotes is the obvious wrong answer; it locks onto whichever tone got lucky first and never explores. A pure uniform random is the other wrong answer; it ignores everything you have learned. The right shape is a sharpened weighted distribution with floor and cap. These four constants control it.

MIN_SAMPLE_SIZE = 5. Below five posts on a tone, you have no signal. The picker treats untrusted tones as "explore" and gives them floor weight only, regardless of their noisy average.

WEIGHT_EXPONENT = 2.0. Raw weight per tone is avg_upvotes ** 2.0. The exponent sharpens the distribution so a tone that scores 2x the average gets 4x the weight, not 2x. Set this to 1.0 if you want a softer landing; set it higher if you want a steeper one.

STYLE_FLOOR_PCT = 5.0. Every non-disabled tone gets at least 5% of picks. This is the exploration budget. A tone with no samples yet still gets tested; a tone that has fallen out of favor still gets a chance to come back.

STYLE_CAP_PCT = 50.0. The leading tone cannot exceed 50% of picks. Overflow redistributes pro-rata to the other tones based on their current weight. This is what stops a single "winning" tone from collapsing everything else to the floor and freezing the distribution.

Letting the model invent new templates inline

The harder design question is what to do when none of your seven baseline tones fit a thread. The wrong answer is to force the closest match. The slightly less wrong answer is to ask a human to add a new template. The actually-good answer is to let the model emit a new tone inline and have your orchestrator register it as a candidate.

Concretely: the model returns a JSON object with engagement_style: "my_new_style" AND a new_style block carrying description, example, why_existing_didnt_fit, and an optional note. The orchestrator validates the block, atomically writes it to scripts/engagement_styles_extra.json behind a flock so concurrent agents do not lose each other's entries, and tags it status: "candidate". From that moment on the new tone shows up in every prompt next to the baseline seven, but it only gets the 5% floor weight regardless of how often it "wins" in subsequent reply decisions. A separate nightly job, the promoter, graduates it to status: "active" only after at least N samples confirm a non-degenerate median.

Three real candidates that graduated last week

The candidate-promotion pipeline is not theoretical. The S4L sidecar at scripts/engagement_styles_extra.json currently holds three model-invented styles, each promoted to active in the past week. The dates and sample counts are taken verbatim from the file as of 2026-05-02.

Each entry preserves the first-use post URL, the inventing model, the original why_existing_didnt_fit rationale, and the promoted_at timestamp. That history is what lets you audit later why a tone exists at all.

The two-lane grounding rule

The single biggest failure mode of an auto-generated reply is a fabricated personal anecdote. Storyteller and share_experience tones are the most vulnerable. The model writes "i ran 22 cameras across three properties for 8 months" on a thread about home security and lands two downvotes inside an hour from anyone who recognizes the specifics are made up. The fix is structural, not stylistic. Every template runs under the same grounding rule, baked into the prompt and outranking every other style guidance.

Lane 1, disclosed story. Open the comment with a phrase that signals illustration: "hypothetically", "imagine someone running this", "say a friend tried", "scenario:". Once that frame is set, the model has full creative license on the specifics. The reader can tell from the first phrase that this is a worked example, not testimony.

Lane 2, no fabrication. Stay first-person, but every concrete detail (number, duration, headcount, place name, course name, named tool, named person) must appear verbatim in your project's config. If a specific is not in config, drop it, generalize it, or pattern-frame it ("the typical failure mode is..."). Pattern-framing counts as observation, not autobiography.

The two lanes are mutually exclusive. The model cannot mix them. A specific presented in Lane 1 voice (after a hedge) is fine; the same specific presented in Lane 2 voice (first-person) without a config anchor is not. This is the line that separates an auto-generator that survives a year on Reddit from one that gets flagged in a month.

Wiring it into your own loop

Treat the picker as a pure function over your existing engagement DB. You do not need a new service. The four moving pieces are:

Once these four pieces exist, every reply generation call follows the same pattern: query the picker for the platform, render the prompt with the per-tone target%, the last 10 picks, and the under-represented hint. Pass the prompt to the model. Validate the returned style against the universe. If unknown, look for a new_style block; register or reject. Post the reply. Log it back to the posts table with the chosen engagement_style. The picker's next call uses the new data.

What this is not

This is not a recipe for spamming Reddit. The picker assumes you are the human in the loop on every reply, that your DM volume is in the single-digits per session, and that you log honest engagement back to your DB. The picker only works if the upvotes you log are the ones the comment actually earned. If you fake that, the weights drift toward whatever you fake and the picker becomes a worse argmax than if you had skipped it.

It is also not a content scheduler. A scheduler answers "when do I post?" A reply-template generator answers "what shape of reply does this thread want?" Those are orthogonal problems and conflating them is why most off-the-shelf social tools do both jobs poorly. Build the picker on top of your existing scheduler if you have one; do not try to fold the scheduler into the picker.

FAQ