DEV Community: Serge Levin

Classifying 33K Reddit posts on a laptop: anchor first, exclude nothing

Serge Levin — Mon, 27 Apr 2026 09:29:06 +0000

Anchor-first prompts: the fix for noisy local-LLM classifiers

If you're using a local LLM as a YES/NO classifier and seeing too many false positives, don't fix it by enumerating off-domain categories to exclude. Flip the prompt to require an explicit named anchor from the target domain - answer YES only when a specific in-domain term appears, otherwise NO. Same prompt shape transfers across model sizes. I've applied it on phi3.5, qwen2.5:7b, and phi4:14b.

Setup

I'm building an agent that watches Reddit (and eventually HN, Lobsters, Mastodon) for posts and comments matching specific signals. Not for lead gen - more for community intelligence. One signal I'm working on: someone comparing or migrating between S3-compatible object storage providers.

Pipeline

Reddit RSS/JSON  →  keyword pre-filter  →  Bayes classifier  →  LLM (Ollama)

Most posts get rejected at the pre-filter. The Bayes classifier handles the bulk of obvious YES/NO. The LLM calculates Bayes weights on the first run; on later runs it only sees ambiguous cases.

Naive approach

I started with phi3.5:latest (~2 GB on disk, snappy in Ollama). Almost immediately, two false-positive classes appeared with hundreds of posts:

Kubernetes infra posts. Threads like "comparing Kafka deployment options on K8s" got flagged YES even though there's no object-storage angle.
Microsoft Fabric / Copilot / data warehouse posts. "Snowflake vs Fabric for our team".

The smaller model was pattern-matching on the shape of "user comparing options" and dropping the domain anchor entirely.

The first attempt to fix was to add exclusions to the prompt.

Answer YES if the post is about object storage migration.
Answer NO if the post is about Kubernetes.
Answer NO if the post is about data warehouses.
Answer NO if the post is about AI tooling.

The negative categories started acting as their own relevance signal. The model treated "is this Kubernetes-y?" as a classification axis - meaning a Kafka-on-K8s post was now being classified along the wrong dimension entirely. Started to get even more noise. Hard to describe the world by what it isn't.

Next, instead of NO if {growing list of off-domain things}, structure the prompt as: YES only if {short positive list of in-domain anchors} AND {intent clause}. Otherwise, NO. No exclusions.

Also, changed the model to qwen2.5:7b as such prompt appeared to be too heavy for phi3.5. What that looks like for my signal:

Answer YES only if the text explicitly names:
  - S3, or an S3-compatible provider (AWS S3, MinIO, Ceph, Garage,
    SeaweedFS, Backblaze B2, Cloudflare R2, Wasabi, Storj),
  - or a tool for moving data between them (rclone, s5cmd, mc mirror,
    AWS DataSync, Cyberduck, boto3, aws cli),
AND the author is comparing options or planning to migrate.
Otherwise answer NO.
Do not infer. If no such name appears, answer NO.
Output a single token: YES or NO.

No "ignore Kubernetes." Nothing about what NOT to match. The prompt only describes what counts. As a result, false positives dropped significantly.

Model comparison

Model	VRAM	Verdict
phi3.5:latest	~2 GB	Too small to hold the domain anchor reliably even with the positive gate. Dropped.
qwen2.5:7b	~5 GB	Large step up. Honored the gate. Fast enough to experiment with the prompt.
phi4:14b	~9 GB	Settled here for production. Needed one more prompt iteration.

Bayes classifier in front of the LLM

Most posts get a high-confidence YES or NO and never see the LLM. LLM as an initial classifier saves time compared to manual classification. And as soon as Bayesian filter weights are good enough, only the ambiguous cases are passed to it.

I pushed roughly 33,000 Reddit records through the full pipeline in under an hour on a laptop GPU. LLM-only would've taken so long that manual filtering would've been faster. If a post doesn't name an in-domain thing AND express comparison/migration intent, it's rejected before the LLM is even invoked. This helps save tokens and mirrors the prompt's logic.

Every new signal I've written since follows this shape - anchor first, everything else after.

Seeding

Running experiments on the data needs a lot of seeding. I tried Google's and Bing's search APIs first - both have been shut down. Ended up with the Brave Search API. The free tier was enough to pull more than 30K seed posts and comments.

Code

All of this is part of an open-source project I'm building - AGPL, runs on a laptop. Some restrictions baked in on purpose: no auto-posting and no DM outreach.

The current approach with the Bayes filter is lean. It does incremental retraining, not drift handling. Every 50 LLM labels, the system pulls the entire historical dataset from DB and calculates the weights from scratch. That's the whole adaptation mechanism for now.

What's missing:

A label from six months ago counts the same as yesterday's.
No distribution-shift detection.
No automatic relabeling of old data when prompts change. I added the --reset command to call full retrain, not sure if that's enough in the long run.

What's coming (and more):

Recency-weighted Bayes retraining. Time-decay on label weights so vocabulary drift follows automatically, plus optional pruning of stale examples that disagree with current labels.
Cross-source aggregation. Same signal hitting three different subreddits is stronger than three hits in one sub. Cross-channel multiplier on the score.
HN, Lobsters, Mastodon as additional sources. The same pain showing up across different cultures, wording, and blind spots is a much stronger signal than three hits in one subreddit.

This post was drafted by the author and refined with AI for clarity and structure.

Migrate Multiple S3 Buckets in Parallel

Serge Levin — Fri, 10 Apr 2026 10:11:40 +0000

Once you know how to migrate one S3 bucket, the next problem is migrating 5 or 20 at once.

Hands-on lab available: Run a 4-bucket parallel migration against two RustFS S3 endpoints in Docker, with Prometheus and Grafana pre-configured. Go to the lab

Each Bucket Pair Deserves Its Own Migration

A multi-bucket migration needs to handle bucket pairs that differ in credentials, rate limits, object count, and object size. One bucket might have millions of small files, another a few hundred multi-gigabyte objects, a third might sit behind a strict RPS limit, and a fourth might require cross-provider transfer. A bash loop over aws s3 sync or a set of rclone instances can move the bytes, but both re-list source and destination on every run instead of resuming from a local checkpoint. Neither tool lets you describe a complete transfer job -- source, destination, rate limits, parallelism, state path, metrics port -- in a single config file. You end up encoding that in wrapper scripts.

The right primitive is one run equals one bucket pair. Each run has its own state, its own resume point, its own metrics endpoint. To migrate multiple S3 buckets, you orchestrate N independent runs - not one run that tries to be N things. Orchestration belongs outside the sync tool, in a script you own.

One S3 Migration Config per Bucket Pair

Godwit Sync supports YAML config files via the -f flag, including ${ENV_VAR} expansion for credentials. Create one config per bucket pair and drop them in a folder:

migrations/
  app-data.yml
  ml-models.yml
  logs-archive.yml
  user-uploads.yml

Each file is a standard Godwit config. Here is app-data.yml from the companion lab:

source:
  url: "s3://prod-app-data"
  endpoint: "s3.us-east-1.amazonaws.com"
  access_key: "${AWS_SOURCE_ACCESS_KEY}"
  secret_key: "${AWS_SOURCE_SECRET_KEY}"

destination:
  url: "s3://backup-app-data"
  endpoint: "s3.us-east-1.amazonaws.com"
  access_key: "${AWS_DEST_ACCESS_KEY}"
  secret_key: "${AWS_DEST_SECRET_KEY}"

options:
  parallel: 16

rate_limit:
  read_bps: 209715200 # 200 MB/s

run:
  run_id: "app-data"
  state_path: "./state/app-data.db"

status:
  addr: ":9100"
  drain_timeout: 15

output:
  brief: true

Each file is self-contained: credentials, endpoints, parallelism, rate limits, state path, and metrics port. A cross-provider pair (say, AWS to an on-prem S3-compatible store) would use a different endpoint, secure: false, and lower read_bps -- but the structure is identical. Godwit expands ${...} variables at load time, so the files themselves contain no secrets. The full config schema is documented in the configuration reference.

The Parallel S3 Migration Script

The orchestrator enumerates every .yml file in the migrations folder, spawns one godwit sync -f <file> per pair in parallel, and collects exit codes. No custom YAML parsing, no env var resolution -- Godwit handles all of that natively.

This is a simplified version of the script. The full version with retry, verify, and status commands is in the companion lab.

#!/usr/bin/env python3
"""migrate-many.py -- fan out godwit sync across config files in a folder."""

import subprocess, sys
from concurrent.futures import ProcessPoolExecutor, as_completed
from pathlib import Path

def run_pair(config_path, action):
    cmd = ["godwit", "sync", "-f", str(config_path)]
    if action == "plan":
        cmd.append("--plan-only")
    elif action == "retry":
        cmd.append("--resume")
    result = subprocess.run(cmd)
    return config_path.stem, result.returncode

def main():
    folder = Path(sys.argv[1]) if len(sys.argv) > 1 else Path("migrations")
    action = sys.argv[2] if len(sys.argv) > 2 else "run"
    configs = sorted(folder.glob("*.yml"))

    if not configs:
        print(f"No .yml files found in {folder}")
        sys.exit(1)

    with ProcessPoolExecutor(max_workers=len(configs)) as pool:
        futures = {
            pool.submit(run_pair, cfg, action): cfg.stem
            for cfg in configs
        }
        failed = 0
        for future in as_completed(futures):
            name, rc = future.result()
            status = "OK" if rc == 0 else "FAIL"
            print(f"[{status:>4}] {name}")
            failed += rc != 0

    sys.exit(failed)

if __name__ == "__main__":
    main()

Each pair runs as an independent godwit sync process with its own state database, run ID, and metrics port -- all defined in its config file. The script prints which pairs succeeded and which failed.

Handling Failures Without All-or-Nothing

Each godwit sync process maintains its own SQLite state database tracking every object: planned, transferred, verified, or failed. A failure in one process does not touch another process's state.

To retry a failed pair, re-run the script with the retry action. The script passes --resume, which tells Godwit to skip planning and pick up from the last successful object. Resume works at the object level, not the bucket level. A fresh run plans and transfers from scratch; retry resumes where the previous attempt stopped.

For details on state tracking and checksum verification, see Verifying S3 Migrations. The companion lab extends this script with retry, verify, and status commands and walks through a failure-and-retry scenario step by step.

Observability: One Dashboard, Four Concurrent Runs

Each godwit sync process exposes Prometheus metrics on the port defined in its config file (status.addr). The four configs use ports 9100, 9101, 9102, 9103. Prometheus scrapes all four targets. A single Grafana dashboard shows every run side by side.

This dashboard is from the companion lab, which ships it pre-provisioned so you can see it live during the walkthrough.

Godwit exposes a wide set of Prometheus metrics. The lab dashboard uses 8 to keep things simple:

Metric	Type	Purpose
`godwit_run_transfer_bytes_total`	Counter	Cumulative bytes; `rate()` gives per-pair throughput
`godwit_run_objects_completed`	Gauge	Objects finished per pair
`godwit_run_objects_total`	Gauge	Planned objects per pair
`godwit_run_objects_failed`	Gauge	Failed objects per pair
`godwit_run_bytes_transferred`	Gauge	Bytes moved per pair
`godwit_run_stage`	Gauge	Current phase: planning, transferring, verifying, completed, failed
`godwit_objects_total{status}`	Counter	Global objects by status; used for error rate
`godwit_eta_seconds`	Gauge	Estimated time to completion per pair

These metrics drive five dashboard panels:

1. Throughput by Pair (time series). Four lines showing rate(godwit_run_transfer_bytes_total[15s]) grouped by pair. The lines diverge because each pair has different bandwidth limits. The app-data pair sustains higher throughput than logs-archive -- expected, given the different read_bps limits in their config files.

2. Migration Progress (bar gauge). Each bar represents godwit_run_objects_completed / godwit_run_objects_total for one pair. At a glance you see that ml-models is at 95% while logs-archive is at 12% -- expected, given the object counts.

3. Pair Status (table). Columns: Pair, Stage (from godwit_run_stage), Bytes Transferred (godwit_run_bytes_transferred), and Failed Objects (godwit_run_objects_failed). This is the single-pane summary an operator needs during the migration window.

4. Error Rate by Pair (time series). rate(godwit_objects_total{status="failed"}[1m]) grouped by pair. When logs-archive hits NoSuchBucket errors, this panel spikes for that pair while the other three stay flat. Immediate signal, no log parsing required.

5. Estimated Time Remaining (stat panel). godwit_eta_seconds per pair, displayed as human-readable remaining time. Operators see that app-data finishes in 8 minutes while logs-archive needs another 2 hours.

The Prometheus label scheme is simple: each scrape target corresponds to one port, and Prometheus relabeling adds a pair label from the target's port. No custom service discovery is needed.

Key Takeaways

Parallel Migration Uses One Process per Bucket Pair

Create one config file per source/destination bucket pair, then use an orchestrator script to spawn one godwit sync -f <file> process per pair. Each process runs independently with its own state database, resume point, and Prometheus metrics endpoint. The pattern works for any number of pairs.

A Failed Pair Does Not Affect Other Pairs

Only that pair stops. Every other pair continues unaffected because each runs as a separate process with its own SQLite state. Re-run the failed pair with --resume to pick up from the last successfully transferred object, not from the beginning.

One Grafana Dashboard Monitors All Pairs

Each Godwit process exposes Prometheus metrics on a separate port. Point Prometheus at all ports and build a single Grafana dashboard that groups panels by run_id. The companion lab ships a pre-built dashboard that shows throughput, progress, errors, and ETA for all pairs side by side.

Try It: Multi-Bucket S3 Migration Lab

The companion lab runs the entire workflow on your laptop in 15 minutes: two RustFS S3 endpoints (source with four pre-populated buckets, target empty), Prometheus, Grafana with a pre-provisioned dashboard, the config files, and the orchestrator script. You run all four pairs in parallel, watch per-pair progress in Grafana, see one pair fail due to an injected permission error, retry it, and verify all four.

Go to the Multi-Bucket Migration Lab