How to auto-post Hugging Face model releases without writing a single “new model dropped” tweet.

Why a scheduled “new model dropped” tweet does almost nothing

Most of the tools and most of the playbooks for this topic have a tidy answer: connect the Hub to a webhook, write a tweet template, schedule it. Done. The problem is that this answer ignores how releases on Hugging Face actually find their audience.

A new model has a long tail of useful life. The DeepSeek-V3 release got a 2316-upvote thread on r/LocalLLaMA on day one, and the same model is still being mentioned in “what 7B should I run for code” threads months later. The templated launch tweet reaches frontpage scrollers once. The people who actually adopt your model find it three weeks in, while they are evaluating something else.

The launch tweet does not reach those people. A reply in their thread does. So the right job is not “announce on a schedule”, it is “detect new releases, expand each release into search topics, and reply to threads where someone is already evaluating models in that space.”

The Hub feed: what you actually get for free

The endpoint is https://huggingface.co/api/models. With sort=createdAt&direction=-1 it returns model records ordered newest first. No token. No rate limit at the cadence we use. Each record looks like this:

{
  "_id": "...",
  "id": "deepseek-ai/DeepSeek-V4-Pro",
  "author": "deepseek-ai",
  "createdAt": "2026-04-22T06:04:45.000Z",
  "tags": ["transformers", "safetensors", "long-context", "..."],
  "pipeline_tag": "text-generation",
  "library_name": "transformers",
  "likes": 3241,
  "downloads": 174402,
  "trendingScore": 3069,
  "private": false
}

The interesting fields for distribution are id, author, tags, and pipeline_tag. The id is the unique handle people will paste into a thread when they recommend you. The author lets you filter the firehose down to your org. The tags and pipeline_tag are the seed for the search topics that drive the engagement loop.

Two distribution moves, side by side

The same release, two completely different shapes of work. The left tab is what every other guide tells you to schedule. The right tab is what S4L runs.

# the move every scheduler tells you to make

new model just dropped 🚨🚀

introducing my-org/My-Model-7B

✅ open weights
✅ apache 2.0
✅ outperforms <bigger model> on <hand-picked benchmark>

try it now 👉 https://huggingface.co/my-org/My-Model-7B

#opensource #ai #llm #huggingface

How a release flows through the pipeline

The Hub feed is the input. The momentum filter is the gate. The bandit picks the voice. The reply lands in a live thread. Every step is logged so the next cycle re-ranks itself from real outcomes.

The momentum gate, in one formula

This is the one piece of math that decides whether your model release ever produces a reply. Read scripts/fetch_twitter_t1.py, the compute_delta function around line 43. The shell sleeps 300 seconds between the two snapshots:

# scripts/fetch_twitter_t1.py
def compute_delta(t0, t1):
    dl = (t1.get("likes", 0) or 0)     - (t0.get("likes", 0) or 0)
    dr = (t1.get("retweets", 0) or 0)  - (t0.get("retweets", 0) or 0)
    dp = (t1.get("replies", 0) or 0)   - (t0.get("replies", 0) or 0)
    dv = (t1.get("views", 0) or 0)     - (t0.get("views", 0) or 0)
    db = (t1.get("bookmarks", 0) or 0) - (t0.get("bookmarks", 0) or 0)
    return dl + 3 * dr + 2 * dp + dv / 1000.0 + db

Retweets are weighted 3x because they are the strongest virality signal. Replies are 2x because a reply means someone cared enough to type. Views are divided by 1000 so they do not dominate. The threshold is a literal delta_score >= 1. Anything below that is a tweet that has stopped moving. The pipeline does not spend a single LLM token drafting against it.

The config you actually touch on release day

One project block in config.json. The discovery cron writes the queries; you only edit it manually if you want to override what tags expand into search topics.

// config.json (the only block you touch when you ship a model)
{
  "projects": {
    "my-model-7b": {
      "landing_pages": {
        "repo": "https://huggingface.co/my-org/My-Model-7B",
        "readme": "https://huggingface.co/my-org/My-Model-7B/raw/main/README.md"
      },
      "threads": {
        "external_subreddits": [
          { "name": "LocalLLaMA",      "floor_days": 7  },
          { "name": "MachineLearning", "floor_days": 14 },
          { "name": "OpenSourceAI",    "floor_days": 7  }
        ],
        "twitter_queries": [
          // generated from the Hub feed: model id, tags, pipeline_tag
          "\"My-Model-7B\" since:YESTERDAY",
          "long context 7B since:YESTERDAY",
          "function calling open weights since:YESTERDAY"
        ]
      }
    }
  },
  "exclusions": {
    "github_repos": ["my-org/My-Model-7B"]
  }
}

Wiring it up end to end

Five steps. Most of the work is the first one (the discovery cron). The rest is wiring its output into the existing engagement loop.

What this approach is bad at, honestly

A reply loop is not the right move for every kind of release. If you are an AI lab with a billion-parameter model and a press team, the templated launch post will reach more people on day one than a momentum-filtered reply ever will. The launch beats the reply at the front of the curve.

Where the reply loop wins is the back of the curve: the long tail of evaluators, integrators, and people running their own benchmarks weeks or months later. If your model is open-weights, dev-tooling-adjacent, or competes on a specific axis (speed at small batch, function-calling reliability, low-VRAM ergonomics), the long tail is where most adoption actually happens. The reply loop is sized for that audience.

It is also genuinely worse at vanity metrics. A momentum-filtered reply does not produce a viral 10k-retweet announcement screenshot you can put on a fundraising deck. It produces a slow accumulation of conversations where you showed up next to a real question with a useful answer, and a corresponding slow accumulation of downloads and stars. If your KPI is the screenshot, this is the wrong tool.