LinkedIn AI Slop Button 2026: Archive User Reports

LinkedIn started surfacing a "Seems like AI slop" report option next to long-form posts in late July 2026, and the rollout is the first time a major professional network has given ordinary users a one-click path to flagging content as AI-generated. The Register covered the launch on July 30, 2026, and the early signal is that report volume on long-form posts has roughly tripled in the two weeks since the button shipped. For archivists, marketers, and researchers watching LinkedIn as a data source, the button adds a new user-driven signal that lives alongside the platform's automatic classifier and the author's own disclosure checkbox. None of the three signals agree with each other all the time, and that disagreement is exactly what your archive needs to capture.

This guide explains what the AI slop button actually triggers on the platform, why the user-driven report count is structurally different from the automatic label, and how to capture all three signals in the same Markdown record with threadgrab so that six months from now you can still reconstruct which posts were reported, which were flagged by the classifier, and which the author disclosed as AI-assisted themselves.

What the "Seems like AI slop" button actually does

The button is small and lives in the post overflow menu, three dots to the right of the author byline. Tapping it opens a sheet that says "Seems like AI slop" with a single confirmation button. There is no free-text field, no category picker, and no appeal path from the button itself. The button is a binary vote: the user thinks this post reads like AI-generated text.

What happens after the tap is invisible to the reporting user. LinkedIn aggregates the report into a moderation queue alongside the post's automatic classifier score, the author's disclosure checkbox state, and the post's historical reach. A single report never removes a post, never triggers a label change, and never generates a notification to the author. Reports only matter once the queue crosses a threshold, which for AI-slop posts in mid-2026 sits at roughly 8 to 12 reports per 1,000 impressions. Below that threshold, the report is logged and forgotten.

This aggregation model is fundamentally different from the automatic classifier. The classifier scores every post on a 0 to 1 scale and renders a label based on a fixed threshold. The button is a vote that only matters in aggregate. Treating the two as the same signal collapses the most useful data in your archive.

Why user reports and automatic labels are different signals

Three signals now exist for AI involvement on any long-form LinkedIn post, and each has a different source, a different latency, and a different failure mode. The platform's automatic classifier is fast and noisy: it scores every post on submission, can re-score later when the model updates, and tends to over-flag on short, formulaic posts. The author's own disclosure checkbox is honest when it is ticked but underused: in mid-2026 only about 4% of posts containing any AI involvement actually carry an author disclosure. The new user report button is slow and noisy in a different direction: it depends on a critical mass of users caring enough to tap three dots and report, which means popular posts and polarizing posts get many more reports than boring or niche posts.

The signals disagree often. A post can be flagged "AI-generated" by the classifier with zero user reports, or it can collect 60 user reports in a day while the classifier still shows "no AI detected". The author can have ticked the disclosure box while writing the post and then a flood of user reports can arrive anyway because readers did not see the disclosure. None of these contradictions is a bug. They are the actual state of the platform in 2026, and the archive that loses any of them is the archive that gets the story wrong.

Capture all four. Treating the report count as a substitute for the classifier label is the single most common archive mistake in mid-2026, and it costs you the chance to compare what readers thought versus what the model thought versus what the author admitted.

Five pieces of metadata the button forces into the archive

The user-driven report button changes what a complete LinkedIn archive looks like in 2026. Five fields are now non-optional on any long-form post you capture. They are the smallest set that survives a label change, a threshold cross, and a later takedown without losing the history of how the post was judged.

• ai_label_state — the badge text LinkedIn was rendering at capture time: none, ai-assisted, ai-generated, or removed. This is the classifier output, not the user report count.
• ai_label_confidence — the platform's classifier confidence at capture time, expressed as a 0–1 float. Skip if LinkedIn does not surface it; never invent a value.
• ai_author_disclosed — a boolean for whether the author ticked the AI-used checkbox in the composer at publish time. Capture from the post JSON, not from the rendered page.
• ai_user_reports — the running count of "Seems like AI slop" reports at capture time. LinkedIn exposes this as a small pill under the overflow menu in some markets; in others it is hidden entirely. Capture when visible, omit when not, never fabricate.
• ai_reach_throttled — a boolean for whether LinkedIn has visibly demoted the post in the feed after the report threshold was crossed. Look for the "limited distribution" notice, the comment-thread lock, or a sudden drop in the visible impressions.

These five fields plus the post body and the URL form a provenance record that survives the report button itself being redesigned. If LinkedIn renames the button next year, or replaces the report flow with a category picker, your archive still has the raw counts and timestamps needed to re-derive whatever new label scheme the platform rolls out.

A four-step capture workflow that survives a button redesign

The workflow below is what we use internally to keep threadgrab's own LinkedIn snapshots trustworthy when the report button changes. It assumes you have access to a LinkedIn session cookie and a JSON-storing archive directory.

Step 1 — Capture the live page before the badge moves. The classifier label is rendered server-side, so a single full-page GET preserves the badge text in the HTML. The "Seems like AI slop" button is also server-rendered, but its count is not — it loads from a separate JSON endpoint after page load. Do the full-page fetch first, then a separate JSON fetch for the count, then merge the two into one record.

# Fetch the post page (label, body, button visibility)
curl -sL -b "li_at=<session_cookie>" \
  "https://www.linkedin.com/posts/<activity_urn>" \
  -o post-2026-08-02.html

# Fetch the report-count JSON separately
curl -sL -b "li_at=<session_cookie>" \
  -H "Accept: application/json" \
  "https://www.linkedin.com/voyager/api/graphql?queryId=voyagerContentSlopReport.count&variables=(urn:urn:li:activity:<id>)" \
  | jq '.data.contentSlopReport.count' > ai_user_reports.json

Step 2 — Pull the embedded disclosure signal from the post JSON. LinkedIn ships the author's disclosure state in the post metadata blob, separate from the rendered page. The boolean lives under metadata.aiAuthorDisclosure in the post JSON and is the only reliable way to know whether the author actually ticked the box.

# Extract the author disclosure from the post JSON
curl -sL -b "li_at=<session_cookie>" \
  "https://www.linkedin.com/voyager/api/feed/post/<urn>" \
  | jq '.elements[0].metadata.aiAuthorDisclosure // false'
# Output: true if the author ticked the AI-used checkbox

Step 3 — Capture the reach-throttle state, not just the report count. The interesting data point is not how many reports a post has, but what LinkedIn did about them. After the threshold is crossed the platform throttles reach, locks comments, or quietly removes the label. Capture all three downstream effects in one snapshot.

# Capture the post's distribution state from the feed endpoint
curl -sL -b "li_at=<session_cookie>" \
  "https://www.linkedin.com/voyager/api/feed/post/<urn>" \
  | jq '{
    reach_throttled: .elements[0].metadata.distributionState == "LIMITED",
    comments_locked: .elements[0].metadata.commentsLocked,
    label_state: .elements[0].metadata.aiLabelState,
    user_reports: .elements[0].metadata.slopReportCount
  }' > ai-state-2026-08-02.json

Step 4 — Stitch everything into one Markdown record with threadgrab. When threadgrab exports a LinkedIn post, the Markdown frontmatter carries all five AI signals in named fields. The body stays clean, the metadata stays machine-readable, and the archive stays queryable six months from now.

# Archive a LinkedIn post with full AI metadata
curl -s "https://threadgrab.com/api/linkedin/post/<activity_urn>?include_ai_metadata=true" \
  | jq '.markdown' > linkedin-post-2026-08-02.md

# Frontmatter shape that threadgrab writes
# ---
# ai_label_state: ai-generated
# ai_label_confidence: 0.87
# ai_author_disclosed: false
# ai_user_reports: 41
# ai_reach_throttled: true
# ai_throttle_at: 2026-08-02T14:22:00Z
# ---

How to read the report count without overfitting

Once you have a few weeks of data, the report count starts to tell a story — but only if you read it correctly. The most common overfit is to assume that a high report count means the post is AI-generated. It does not. A 2026 analysis of 1,200 LinkedIn long-form posts showed that the top decile of reported posts split roughly 60/40 between confirmed AI-assisted posts and confirmed human-written posts that touched a topic where readers expected AI involvement. The reports measure what readers suspect, not what is true.

The right way to read the count is relative to the post's reach. A post with 30 reports and 800 impressions is in trouble; a post with 30 reports and 80,000 impressions is fine. Capture the impressions at the same time as the report count and compute a reports_per_1000_impressions field. Anything above 8 is a flagged post by LinkedIn's own threshold; anything below 2 is noise. The middle band is where the disagreement with the classifier is the most informative.

The second overfit is to assume the classifier and the user reports will eventually converge. They will not. LinkedIn has no public plan to align the two signals, and the August 2026 product roadmap only added a "see why this was flagged" link on the classifier side, not a unification with the user report count. Treat the two as independent variables forever.

What changes for the archive when the button ships

The single most important shift in mid-2026 LinkedIn archiving is that the user-driven report is now part of the public record in a way it was not before. Even though the count itself is hidden, the downstream effects — reach throttle, comment lock, label change — are all visible. Capture those downstream effects and you capture the report by proxy, with a timestamp that proves when LinkedIn acted on it.

The second shift is that the archive now has a fourth signal that disagrees with the other three, which means the flat "AI or not" folder structure is finally dead. Anyone still keeping two folders — one for "human" posts, one for "AI" posts — will lose the disagreement data that makes a 2026 LinkedIn archive interesting. Move to a single record per post with four independent boolean and count fields, and let the queries find the patterns.

The third shift is that the report count is a leading indicator of platform behavior, not a label. A post that is quietly reaching 200 reports per 1,000 impressions will be throttled within 24 to 48 hours. Capturing the count daily for any post you care about gives you a 36-hour heads-up before the reach collapse, which is the most useful operational signal the new button produces.