DEV Community: Sanjay Singh

How We Built a Production Email Verification Pipeline That Saved Our Sender Reputation

Sanjay Singh — Thu, 20 Aug 2026 06:01:22 +0000

Every platform that sends emails — onboarding sequences, notifications, password resets, newsletters — lives or dies by one metric: deliverability. Send a few dozen emails to dead mailboxes and your domain ends up on a blacklist. Your carefully crafted messages land in spam. Your sender reputation — built over months — evaporates overnight.

We learned this the hard way. This article walks through the production email verification system we built to protect our email sending infrastructure, and the design decisions behind every layer.

The Problem: Why Naive Validation Kills You

Most tutorials tell you to slap a regex on the email field and call it a day:

const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

That regex catches obvious typos — user@, @domain.com, spaces — but it happily accepts:

ceo@totallylegit-disposable.com (throwaway address)
info@company.com (shared inbox — nobody reads platform emails there)
user@nonexistent-domain.xyz (domain has no mail servers)
john@catch-all-domain.com (server accepts everything, but the mailbox doesn't exist)

Every one of these will either bounce, trigger a spam complaint, or waste your send quota. At scale, this compounds into a deliverability crisis.

We needed a pipeline that handles all of these cases before the email ever leaves our server.

The Architecture: 8 Verification Steps

Our SmtpVerifierService runs every candidate email through an ordered sequence of increasingly expensive checks. The philosophy is simple: fail fast, fail cheap.

flowchart TD
    A["Input Email"] --> B["Normalize"]
    B --> C{"Cache Hit?"}
    C -- Yes --> D["Return Cached Result"]
    C -- No --> E["Regex Check"]
    E --> F["Role-Based Check"]
    F --> G["MX Record Lookup"]
    G --> H["Disposable Domain Check"]
    H --> I{"Major Provider?"}
    I -- Yes --> J["Skip SMTP, Mark VALID"]
    I -- No --> K["Catch-All Detection"]
    K --> L["SMTP RCPT TO Probe"]
    L --> M["Cache + Return"]

Each step can short-circuit with a verdict. We defined five possible outcomes:

Verdict	Meaning	Action
VALID	Mailbox confirmed to exist	✅ Safe to send
INVALID	Definitively bad address	❌ Block globally, never send
CATCH_ALL	Server accepts everything	⚠️ Send with caution
RISKY	Role-based or shared inbox	⚠️ Treat carefully based on context
UNKNOWN	Verification inconclusive	⏸️ Skip for now, retry later

export enum EmailVerdict {
  VALID = 'VALID',
  INVALID = 'INVALID',
  CATCH_ALL = 'CATCH_ALL',
  UNKNOWN = 'UNKNOWN',
  RISKY = 'RISKY',
}

The key insight: UNKNOWN is not INVALID. Greylisting, timeouts, and connection resets are temporary. Marking those as invalid would permanently discard good emails. Instead, we skip them and let the next verification cycle retry with a fresh connection.

Step 1: Normalization and Cache Check

Before anything else, we normalize the email and check an in-memory cache:

const normalised = email.trim().toLowerCase();

const cached = this.fromCache(normalised);
if (cached) return cached;

The cache is a simple Map<string, CacheEntry> with a 24-hour TTL. We chose in-memory over Redis for three reasons:

Latency — zero network hop for cache hits
Simplicity — no external dependency for a single-process worker
Volume — we verify hundreds per day, not millions. The map stays small.

A background timer purges expired entries every 6 hours to prevent unbounded memory growth:

const CACHE_TTL_MS = 24 * 60 * 60 * 1000;
const CACHE_CLEANUP_INTERVAL_MS = 6 * 60 * 60 * 1000;

this.cacheCleanupTimer = setInterval(
  () => this.purgeExpiredCache(),
  CACHE_CLEANUP_INTERVAL_MS,
);
// Allow process to exit even if the timer is still running
if (this.cacheCleanupTimer.unref) {
  this.cacheCleanupTimer.unref();
}

The .unref() call is critical — without it, the timer would keep the Node.js process alive indefinitely, preventing graceful shutdown.

Step 2: Regex Format Check (The Cheapest Gate)

const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

if (!EMAIL_REGEX.test(normalised)) {
  return this.cacheAndReturn(
    normalised,
    EmailVerdict.INVALID,
    'Invalid email format',
  );
}

This is intentionally loose. We're not trying to implement RFC 5322 — we're filtering obvious garbage before spending DNS and TCP resources. If it doesn't have a local part, an @, and a dotted domain, it's out.

Step 3: Role-Based Address Filtering

Emails to info@, support@, admin@, or hr@ are shared inboxes, not personal addresses. Sending transactional emails to these addresses often leads to higher bounce and complaint rates, especially when the recipient didn't explicitly sign up.

const ROLE_BASED_PREFIXES: ReadonlySet<string> = new Set([
  'info', 'admin', 'support', 'contact', 'sales',
  'help', 'billing', 'abuse', 'postmaster', 'webmaster',
  'hostmaster', 'security', 'noreply', 'no-reply',
  'mailer-daemon', 'office', 'team', 'hr', 'careers',
  'jobs', 'feedback', 'marketing', 'press', 'media',
]);

We mark these as RISKY instead of INVALID because they are deliverable — they're just not ideal targets for most email flows:

if (ROLE_BASED_PREFIXES.has(localPart)) {
  return this.cacheAndReturn(
    normalised,
    EmailVerdict.RISKY,
    `Role-based address (${localPart}@) — not a personal inbox`,
  );
}

The consuming service can then decide what to do based on context — skip entirely, flag for review, or send with caution.

Step 4: MX Record Validation

If a domain has no MX records, it cannot receive email. Period.

private async checkMx(domain: string): Promise<boolean> {
  try {
    const records = await dns.resolveMx(domain);
    return records.length > 0;
  } catch (err: unknown) {
    const code = (err as NodeJS.ErrnoException).code;
    if (code === 'ENOTFOUND' || code === 'ENODATA') {
      return false; // Domain definitively has no MX records
    }
    // DNS timeout or transient failure — don't penalise the email
    return true;
  }
}

Notice the error handling: ENOTFOUND and ENODATA are definitive — the domain doesn't exist or has no mail records. But a DNS timeout is transient. We give the benefit of the doubt and continue the pipeline rather than falsely rejecting a valid email.

Step 5: Disposable Domain Blocking

deep-email-validator has its own disposable domain list, but it misses some. We maintain a supplementary set of known throwaway domains:

const EXTRA_DISPOSABLE_DOMAINS: ReadonlySet<string> = new Set([
  'mailinator.com', 'guerrillamail.com', 'tempmail.com',
  'throwaway.email', 'yopmail.com', 'sharklasers.com',
  'maildrop.cc', 'discard.email',
  // ... 16 domains total
]);

Anyone using a disposable email to sign up is either testing or has no intention of engaging. We mark these as INVALID and block the address.

Step 6: Major Provider Short-Circuit

Here's a counterintuitive design decision: we skip SMTP verification entirely for Gmail, Outlook, Yahoo, iCloud, and ProtonMail.

const SMTP_PROBE_SKIP_DOMAINS: ReadonlySet<string> = new Set([
  'gmail.com', 'googlemail.com',
  'yahoo.com', 'outlook.com', 'hotmail.com',
  'icloud.com', 'protonmail.com', 'proton.me',
  // ... 22 domains total
]);

Why? These providers actively block SMTP RCPT TO probes from cloud IPs. If you try to verify john@gmail.com from an AWS or DigitalOcean server, Google will either:

Reject the connection outright (false INVALID)
Rate-limit you and return 450 codes (false UNKNOWN)
Silently accept the probe but flag your IP for suspicious activity

Since MX, regex, and disposable checks already passed, we mark these as VALID and move on. The risk of a false positive on gmail.com is far lower than the risk of false negatives from unreliable SMTP probing.

flowchart TD
    A{"Is domain a major provider?"}
    A -- "Gmail, Outlook, Yahoo..." --> B["Skip SMTP probe"]
    B --> C["Mark VALID"]
    A -- "Custom domain" --> D["Proceed to catch-all detection"]
    D --> E["Then SMTP RCPT TO probe"]

Step 7: Catch-All Domain Detection

Before probing the real address, we probe a randomly generated address at the same domain:

private async detectCatchAll(domain: string): Promise<boolean> {
  const probeAddress =
    `${randomUUID().replace(/-/g, '').slice(0, 16)}@${domain}`;

  const res = await this.runWithTimeout(
    validate({
      email: probeAddress,
      sender: 'hello@yourdomain.com',
      validateSMTP: true,
      validateMx: false, // already verified
    }),
  );

  // If a random gibberish address was accepted, it's catch-all
  return res.valid || res.validators.smtp?.valid === true;
}

If a3f8b2e91c4d7a06@domain.com is accepted, the domain is a catch-all — it accepts everything. This means verifying the real address is meaningless; the server would say "yes" regardless.

We mark catch-all domains with CATCH_ALL verdict. Consuming services can decide whether to proceed — the address might still be valid, but we can't confirm it.

Step 8: Full SMTP Verification with Greylisting Retry

For custom domains that aren't catch-all, we perform the actual SMTP RCPT TO probe using deep-email-validator:

sequenceDiagram
    participant V as Verifier
    participant S as Mail Server

    V->>S: HELO / EHLO
    S-->>V: 250 OK
    V->>S: MAIL FROM: hello@yourdomain.com
    S-->>V: 250 OK
    V->>S: RCPT TO: target@domain.com
    alt Mailbox exists
        S-->>V: 250 OK → VALID
    else Mailbox not found
        S-->>V: 550 User unknown → INVALID
    else Greylisting
        S-->>V: 450/451 Try again → UNKNOWN
        Note over V: Wait 30 seconds
        V->>S: RCPT TO: target@domain.com
        S-->>V: 250 OK → VALID
    end

The most interesting part is greylisting handling. Many mail servers temporarily reject the first delivery attempt from an unknown sender (response codes 450, 451, or messages containing "greylist" or "try again"). This is an anti-spam technique — legitimate senders retry, spammers don't.

Our verifier detects greylisting by inspecting the SMTP response:

const isGreylisting =
  smtpReason.includes('greylist') ||
  smtpReason.includes('try again') ||
  smtpReason.includes('temporarily') ||
  smtpReason.includes('4.7.1') ||
  smtpReason.includes('450') ||
  smtpReason.includes('451');

On the first attempt, we return UNKNOWN with the reason. The outer method then waits 30 seconds and retries exactly once:

const GREYLIST_RETRY_DELAY_MS = 30_000;

const firstAttempt = await attempt(false);

if (firstAttempt.verdict === EmailVerdict.UNKNOWN) {
  await new Promise((r) => setTimeout(r, GREYLIST_RETRY_DELAY_MS));
  return attempt(true);
}

If the retry also fails, we cache the result as UNKNOWN so we stop hammering the server. The next verification cycle will retry organically.

The Timeout Safety Net

Every external call — DNS, SMTP probe, catch-all detection — is wrapped in a configurable timeout:

private runWithTimeout<T>(promise: Promise<T>): Promise<T> {
  let timer: ReturnType<typeof setTimeout> | undefined;

  const timeout = new Promise<never>((_, reject) => {
    timer = setTimeout(
      () => reject(new Error('SMTP_VERIFY_TIMEOUT')),
      this.smtpTimeoutMs, // Default: 10 seconds
    );
  });

  return Promise.race([promise, timeout]).finally(() => {
    if (timer !== undefined) clearTimeout(timer);
  });
}

The timeout is configurable via environment variable (defaults to 10 seconds). This prevents a single unresponsive mail server from blocking the entire verification queue.

How Consuming Services Use Verdicts

The verification service is a pure function — it takes an email and returns a verdict. Any consuming service then maps each verdict to a domain-specific action:

flowchart TD
    A["Email Address"] --> B["Verify"]
    B --> C{"Verdict?"}
    C -- VALID --> D["Safe to Send"]
    C -- INVALID --> E["Block Globally"]
    E --> F["Never Send Again"]
    C -- UNKNOWN --> G["Skip, Retry Later"]
    C -- CATCH_ALL --> H["Send with Caution"]
    C -- RISKY --> I["Flag for Review"]

The critical detail: INVALID emails aren't just skipped — they're globally blocked. This prevents any part of the application (notifications, newsletters, transactional emails) from ever attempting delivery to that address again.

if (verification.verdict === EmailVerdict.INVALID) {
  await this.mailService.blockEmail(email);
  // Update user record to reflect invalid email status
}

Lessons Learned

1. Never trust SMTP results from major providers

Gmail, Outlook, and Yahoo will lie to your cloud IP. Accept it and skip the probe. Your regex + MX + disposable checks are sufficient for these domains.

2. `UNKNOWN` ≠ `INVALID`

This was our most expensive lesson. Early versions marked timeouts and connection errors as INVALID, permanently discarding thousands of valid emails. Treat inconclusive results as inconclusive — let the next cycle retry.

3. Catch-all detection must precede SMTP probing

Without catch-all detection, you'll mark catch-all domain addresses as VALID when they might not be. Probe a random address first. If the server says "yes" to garbage, it'll say "yes" to anything.

4. In-memory cache is fine at moderate scale

We process hundreds of verifications per day, not millions. A Map with TTL and periodic cleanup is simpler, faster, and more reliable than adding a Redis dependency for this workload.

5. Greylisting is more common than you think

About 15–20% of custom domains use greylisting. Without the 30-second retry, you'd mark all of these as UNKNOWN forever and never be able to send to them.

6. Role-based emails need their own verdict

info@company.com is technically deliverable, but sending to shared inboxes often leads to higher complaint rates. A separate RISKY verdict lets consuming services make the right decision without the verification layer overstepping.

The Numbers

After deploying this pipeline, our email metrics changed dramatically:

Metric	Before	After
Bounce rate	~12%	< 1%
Spam complaints per 1000	~8	< 1
Valid emails wrongly blocked	~15%	< 2%
Sender reputation score	Moderate	Excellent

Key Takeaways

Layer your defences — each check catches what the previous one missed.
Order by cost — regex is free, DNS is cheap, SMTP is expensive. Run them in that order.
Distinguish temporary from permanent failures — your verdict enum should have more than just valid and invalid.
Skip what you can't verify — major providers block SMTP probes from cloud IPs. Don't fight it.
Detect catch-all domains — they'll accept any address, making SMTP verification useless.
Retry greylisting — one retry after 30 seconds resolves most temporary rejections.
Block invalid emails globally — not just in the sending flow, but across your entire platform.

The full implementation is ~500 lines of TypeScript in a single NestJS injectable service. No external SaaS dependency, no monthly verification API bill — just DNS, SMTP, and careful engineering.

Building email verification from scratch isn't glamorous, but it's the difference between an email infrastructure that scales and one that gets your domain blacklisted. Invest in the plumbing.

ZyVOP is a developer publishing platform where every post you write natively cross-posts to Dev.to, Hashnode, Medium, and Bluesky — with the canonical URL pointing back to your ZyVOP post. Publish your first post here.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

The Real Cost of Running a Developer Platform

Sanjay Singh — Tue, 18 Aug 2026 04:19:04 +0000

The cross-posting engine was the reason ZyVOP existed. It was also the reason I had to leave Vercel.

Vercel charges for edge function execution time. Cross-posting to Dev.to, Hashnode, and Medium in a single job — authenticating with each API, handling retries, confirming canonical URLs — takes time. Unpredictable time. The kind that racks up charges silently and hits a hard timeout before the job finishes.

The risk wasn't just cost. It was a writer publishing a post, seeing a success message, and discovering hours later their article never appeared on Dev.to. That scenario was one slow API response away from happening.

That was enough. I moved to a VPS where background jobs run for as long as they need to, with no clock running.

What I Was Running On (And What It Was Costing)

ZyVOP is not a simple app. It runs a Next.js frontend, a NestJS backend, PostgreSQL, real-time notifications, an AI news feed, cross-posting to Dev.to, Hashnode, Medium, and Bluesky, 2FA, Groq AI integration, Brevo email, badges, a leaderboard, and a full API.

On Vercel, this was going to cost at minimum $20/month on the Pro plan. That's before the real costs kicked in.

Build minutes were the first problem. Every deployment consumes build time. Every pull request triggers a preview build. Since early 2026, Vercel defaults new Pro projects to Turbo machines, which cost significantly more per minute than Standard. A moderately active codebase doesn't need to do anything unusual to hit $40-60/month.

The edge function timeout was the fatal problem. Our cross-posting engine needs to authenticate with three or four external APIs per post, handle retries on failures, and confirm canonical URLs were accepted correctly. That takes time. Vercel's execution limits were cutting the job short before it finished — with no guarantee the user would see an error if the job failed mid-process.

I was building a platform whose core feature — cross-posting — was silently broken for any post that took longer than a few seconds to process. The writers I was trying to recruit were my most important early users. Losing their trust over a billing decision would have been unforgivable.

The New Stack

I moved everything to a VPS running Docker with Cloudflare Tunnel handling all inbound traffic. Here's what it costs now:

Service	Plan	Cost/month
VPS (4 vCPU, 8GB RAM, 160GB SSD)	Paid	$8
Cloudflare Tunnel	Free	$0
Brevo (transactional + marketing email)	Free	$0
Groq AI (content intelligence)	Free tier	$0
X Premium (India, for DM outreach)	₹427/mo	~$5
Domain (zyvop.com)	Annual	~$1
Total		~$14/month

The cross-posting engine that was at risk on Vercel has not failed once since the migration. The cross-posting job runs inside the NestJS backend with no execution time limit. When a writer publishes a post, it cross-posts reliably every time.

Why Each Line Item Is Worth Explaining

The VPS ($8/month)

Four vCPU, 8GB RAM, 160GB SSD. Everything runs here inside Docker: the Next.js frontend, the NestJS backend, and the Cloudflare Tunnel connector. Each container runs with restart: always, meaning everything comes back up automatically after any crash or server reboot.

The $8/month buys something Vercel cannot sell at any price: certainty. The cross-posting job runs inside the NestJS backend process for as long as it needs to. No execution time billing. No hard timeout ceiling. No clock running against you.

Cloudflare Tunnel (Free)

This is the most underrated piece of infrastructure in the stack and most developers who self-host don't use it.

Without Cloudflare Tunnel, self-hosting means opening ports, configuring Nginx, managing SSL certificates, and exposing your server's IP to the internet. It means your VPS is a target.

With Cloudflare Tunnel, none of that exists. A Docker container running cloudflared creates an outbound encrypted connection to Cloudflare's edge. All traffic enters through Cloudflare and travels through that tunnel to your server. No ports open. No SSL to manage. No IP exposed. Cloudflare's DDoS protection runs in front of everything automatically.

The entire setup is three things: a tunnel token from the Cloudflare dashboard, a Docker container that runs it, and a DNS record that Cloudflare creates for you automatically. The tunnel token goes in .env.production — not hardcoded in your Docker Compose file, which is a mistake that's easy to make and important to avoid.

One thing nobody warns you about: after you remove your site from Vercel and point DNS through Cloudflare, purge the Cloudflare cache immediately. Cloudflare will keep serving cached responses from the old Vercel origin for hours if you don't. The fix is one button in the dashboard or one API call.

Brevo (Free)

Brevo's free plan gives 300 emails per day and unlimited contacts. ZyVOP uses transactional emails for account events and marketing emails for the weekly digest and re-engagement flows. At 116 users in beta, the free tier has significant headroom.

When we outgrow it, the Starter plan is $9/month. The threshold for hitting it doesn't exist yet.

Groq (Free)

Groq powers ZyVOP's AI content intelligence — tag suggestions, related content recommendations, and the AI news feed curation. The free tier provides 30 requests per minute and 14,400 requests per day without requiring a credit card.

For our current usage that's more than enough. When it isn't, Groq's paid tier starts at $0.05 per million tokens for smaller models — one of the cheapest inference APIs available in 2026. Llama 3.3 70B, which is capable enough for almost everything we need, runs at $0.59 per million input tokens. The AI features will stay cheap for a long time.

X Premium India (₹427/month ≈ $5)

This is a distribution cost, not infrastructure. X Premium is required to send DMs to accounts you don't follow. Since cold outreach to developers is part of the growth strategy — and DMs outperform emails for reply rates — this is a necessary line item.

Honest assessment: the jury is still out on ROI. The DM deliverability is better. Whether that converts to writers is a separate question.

What This Costs at Scale

The $14/month number is a beta number. Here's how it changes as the platform grows:

Stage	Users	Brevo	Groq	VPS	X Premium	Total
Now	~100	$0	$0	$8	$5	~$14
Early growth	~1,000	$9	~$2	$8	$5	~$24
Real traction	~10,000	$25	~$15	$20	$5	~$65
Platform scale	~100,000	$65	~$80	$60	$5	~$210

These are estimates, not projections. The Groq number depends heavily on which models we use and how many AI requests we make per user. The VPS number depends on traffic patterns. The Brevo number is the most predictable.

The point is: a developer platform with real AI features, full email infrastructure, and auto cross-posting to four platforms costs about $210/month to run at 100,000 users. That's not a business problem. That's a solved problem.

The Number Nobody Talks About

Infrastructure cost is the wrong thing to optimise at this stage.

$14/month is $168/year. That's noise. The real cost of running ZyVOP is the hundreds of hours that went into building the cross-posting engine, the Markdown parser, the real-time notification system, the AI news feed, the leaderboard, the badge system, and the 2FA flow.

Time is the only resource that doesn't get cheaper at scale.

The infrastructure bill is something you can fix in an afternoon. The product decisions you get wrong in year one follow you for years. Spend your energy there.

ZyVOP is a developer publishing platform that auto cross-posts to Dev.to, Hashnode, Medium, and Bluesky in one click — with canonical URLs pointing back to your domain. Publish your first post here.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

I Built a System That Cross-Posts to 5 Platforms With One Click — Here's How

Sanjay Singh — Mon, 17 Aug 2026 13:19:26 +0000

Every time I publish a blog post on ZyVop, I want it to also appear on Dev.to, Hashnode, Medium, Bluesky, and WordPress. Manually? That's 20 minutes of copy-pasting, reformatting, and fixing broken code blocks. Five times. For every post.

So I built a cross-posting engine that does it in one click.

This post walks through the adapter pattern I used, the bizarre API inconsistencies across platforms, the content transformation pipeline, and the error handling strategy that makes the whole thing resilient.

The Problem

Content distribution is one of those problems that sounds simple until you actually do it. Each platform:

Has a different API (REST, GraphQL, AT Protocol)
Expects a different content format (Markdown, HTML, rich text)
Has different tag limits (Dev.to: 4 tags, Hashnode: 5, Medium: 5)
Handles authentication differently (API keys, OAuth tokens, app passwords)
Some support updating posts, some don't

I needed a design that could handle all of this without turning into spaghetti.

The Adapter Pattern

The core idea is simple: every platform implements the same interface. The orchestrator doesn't care about API details — it just calls publish() on each adapter.

Cross-Post Architecture

flowchart LR
    A[Post Published] --> B[CrossPostService]
    B --> C{Platform Enabled?}
    C -->|Dev.to| D[DevToAdapter]
    C -->|Hashnode| E[HashnodeAdapter]
    C -->|Medium| F[MediumAdapter]
    C -->|Bluesky| G[BlueskyAdapter]
    C -->|WordPress| H[WordpressAdapter]
    D --> I[Persist Results]
    E --> I
    F --> I
    G --> I
    H --> I

Each adapter is a standalone NestJS injectable service. The orchestrator checks which platforms the user enabled, verifies they've configured their API keys, and fires off each adapter:

export interface CrossPostResult {
  platform: string;
  success: boolean;
  url?: string;
  error?: string;
}

This return type is the contract. Every adapter returns the same shape — whether it succeeded, the published URL, or what went wrong.

The orchestrator just loops through:

if (post.crossPostToDevTo && userDevToApiKey) {
  results.push(await this.devTo.publish(post, author, userDevToApiKey));
}

if (post.crossPostToHashnode && userHashnodeApiKey) {
  results.push(await this.hashnode.publish(post, author, userHashnodeApiKey));
}

// ... same pattern for Medium, Bluesky, WordPress

No if-else hell. No platform-specific branching in the orchestrator. Each adapter owns its own complexity.

The Content Transformation Problem

Here's where things get interesting. My blog stores content as HTML (it uses a rich text editor). But Dev.to wants Markdown. Medium wants HTML. Bluesky wants plain text with "facets." WordPress wants HTML.

So I built a CrossPostParserService that handles the conversion.

HTML to Markdown Conversion

The backbone is Turndown — an HTML-to-Markdown library. But the default output is broken for blog posts. Code blocks lose their language annotations, and tables come out as garbage.

I had to add custom rules:

this.turndown = new TurndownService({
  headingStyle: 'atx',       // # H1 instead of H1\n===
  codeBlockStyle: 'fenced',  // ```js instead of indented
  bulletListMarker: '-',
});

// Custom rule: preserve language annotations on code blocks
this.turndown.addRule('fencedCodeBlock', {
  filter: ['pre'],
  replacement: (_content, node) => {
    const code = node.querySelector('code');
    let lang = '';
    if (code) {
      const cls = code.getAttribute('class') || '';
      const match = cls.match(/language-(\S+)/);
      if (match) lang = match[1];
    }
    const text = code ? code.textContent : node.textContent;
    return '\n\n```' + lang + '\n' + text + '\n```\n\n';
  },
});

Without this rule, a TypeScript code block would lose its syntax highlighting on Dev.to. That's the difference between a polished cross-post and one that looks like you didn't care.

The HTML Table Problem

HTML tables are even worse. Turndown produces broken Markdown for anything beyond a simple 2-column table. So I wrote a preprocessor that converts tables to Markdown before Turndown touches them:

htmlToMarkdown(html: string, zyvopUrl: string): string {
  // Step 1: Extract tables, convert them ourselves
  const tableMap: string[] = [];
  const preprocessed = html.replace(
    /<table[^>]*>([\s\S]*?)<\/table>/gi,
    (match) => {
      const md = this.convertHtmlTableToMarkdown(match);
      const idx = tableMap.length;
      tableMap.push(md);
      return `<p>ZYVOPTBL${idx}ENDTBL</p>`;  // placeholder
    }
  );

  // Step 2: Let Turndown handle the rest
  let markdown = this.turndown.turndown(preprocessed);

  // Step 3: Swap placeholders back with our Markdown tables
  markdown = markdown.replace(/ZYVOPTBL(\d+)ENDTBL/g, (_, idx) => {
    return tableMap[parseInt(idx, 10)].trim();
  });

  return markdown;
}

The trick: replace HTML tables with placeholder tokens, let Turndown convert everything else, then swap the placeholders with properly formatted Markdown tables. Ugly? Yes. Works perfectly? Also yes.

Platform-by-Platform Breakdown

Publish Flow

sequenceDiagram
    participant App as ZyVop
    participant P as Parser
    participant API as Platform API

    App->>P: Convert HTML content
    P-->>App: Markdown / HTML / Plain text
    App->>API: Check for existing article ID
    alt New post
        App->>API: POST create article
        API-->>App: article ID + URL
        App->>App: Store article ID for future updates
    else Update
        App->>API: PUT update article
        API-->>App: Updated URL
    end

Dev.to — The Straightforward One

Dev.to has the cleanest API. Simple REST, API key in the header, Markdown body. It even supports updating existing articles:

const isUpdate = !!post.devToArticleId;
const url = isUpdate
  ? `https://dev.to/api/articles/${post.devToArticleId}`
  : 'https://dev.to/api/articles';

const res = await fetch(url, {
  method: isUpdate ? 'PUT' : 'POST',
  headers: { 'Content-Type': 'application/json', 'api-key': apiKey },
  body: JSON.stringify({
    article: {
      title: post.title,
      body_markdown: bodyMarkdown,
      published: true,
      series: post.series?.title || undefined,
      canonical_url: canonicalUrl,
      tags,
    },
  }),
});

On first publish, I store devToArticleId so future edits update the same article instead of creating duplicates.

Gotcha: Dev.to limits tags to 4, and they must be lowercase alphanumeric with no spaces. My sanitizeTag() function handles this — stripping special characters and truncating to 30 characters.

Hashnode — The GraphQL One

Hashnode uses GraphQL exclusively. Publishing requires two API calls: one to discover the user's publication ID, then one to create the post.

// Step 1: Find the user's publication
const meQuery = `query Me {
  me {
    id
    publications(first: 1) {
      edges { node { id } }
    }
  }
}`;

// Step 2: Publish to that publication
const publishMutation = `mutation PublishPost($input: PublishPostInput!) {
  publishPost(input: $input) {
    post { id url }
  }
}`;

Unlike Dev.to, Hashnode uses separate mutations for create vs update: PublishPost and UpdatePost. The input shape is nearly identical, but the mutation name differs. I handle this with a simple isUpdate branch rather than trying to abstract the GraphQL layer.

Gotcha: Hashnode's API key goes in a plain Authorization header — no Bearer prefix. Get that wrong and you'll get a cryptic "Invalid API key" error that doesn't tell you what's actually wrong.

Medium — The Stubborn One

Important note: Medium has officially shut down their API for new users. You can no longer generate new integration tokens. However, if you already had an integration token before the shutdown, it still works — which is why this adapter exists. If you're building something similar from scratch today, you'd likely skip Medium or explore unofficial workarounds.

For those with legacy tokens, the API has its own quirks:

Uses OAuth-style Bearer tokens
Requires fetching the author ID before publishing
Does not support updating published posts — at all, via API

That last point is a design decision I had to respect:

if (post.mediumArticleId) {
  this.logger.warn(
    'Medium API does not support updating published posts. Skipping.'
  );
  return { platform: 'medium', success: true };
}

When a user edits a post and republishes, Dev.to and Hashnode get updated. Medium gets skipped. Not ideal, but that's Medium's API limitation, not mine.

Another quirk: Medium accepts HTML directly (no Markdown conversion needed), so it gets the raw content with an "Originally published on ZyVOP" footer appended.

Bluesky — The Protocol One

Bluesky doesn't have a "publish article" API — it's a social network. So cross-posting here means creating a post (like a tweet) with the article title, excerpt, and link.

But Bluesky uses the AT Protocol, which has its own way of handling links. You can't just paste a URL into the text. Links need to be detected as "facets" — structured annotations on the text:

import { BskyAgent, RichText } from '@atproto/api';

const agent = new BskyAgent({ service: 'https://bsky.social' });
await agent.login({ identifier, password: appPassword });

let text = `New post: ${post.title}\n\n`;
if (post.excerpt) text += `${post.excerpt}\n\n`;
text += `Read more: ${canonicalUrl}`;

const rt = new RichText({ text });
await rt.detectFacets(agent);  // Auto-detects links and mentions

await agent.post({
  $type: 'app.bsky.feed.post',
  text: rt.text,
  facets: rt.facets,
  createdAt: new Date().toISOString(),
});

The RichText helper from @atproto/api handles facet detection — it scans the text for URLs and mentions, then creates the structured byte-offset annotations that the AT Protocol requires.

Gotcha: Bluesky doesn't support editing posts via the API. Once posted, it's permanent. I handle this by checking if blueskyPostUrl already exists and skipping the duplicate.

Another gotcha: The API returns an AT URI like at://did:plc:xxx/app.bsky.feed.post/rkey. To construct the web URL, you need to extract the rkey and build it yourself:

const uriParts = postRecord.uri.split('/');
const rkey = uriParts[uriParts.length - 1];
const postUrl = `https://bsky.app/profile/${identifier}/post/${rkey}`;

WordPress — The Classic One

WordPress uses its REST API with Basic Auth (application passwords). It's the most battle-tested API of the bunch, but authentication requires Base64-encoding the credentials:

const credentials = Buffer.from(`${wpUsername}:${wpAppPassword}`)
  .toString('base64');

const res = await fetch(apiUrl, {
  method: isUpdate ? 'PUT' : 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Basic ${credentials}`,
  },
  body: JSON.stringify({
    title: post.title,
    content: htmlContent,
    status: 'publish',
  }),
});

WordPress accepts HTML natively, so no Markdown conversion is needed. Like Dev.to, it supports updates via the same endpoint with a PUT method.

Platform Comparison

Here's a summary of how each platform differs:

Feature	Dev.to	Hashnode	Medium	Bluesky	WordPress
API Type	REST	GraphQL	REST	AT Protocol	REST
Content Format	Markdown	Markdown	HTML	Plain text	HTML
Auth Method	API Key	API Key	Bearer Token (legacy)	App Password	Basic Auth
Supports Updates	Yes	Yes	No	No	Yes
API Available	Yes	Yes	Legacy tokens only	Yes	Yes
Tag Limit	4	5	5	N/A	Unlimited
Post Type	Article	Article	Article	Social Post	Article

Error Handling That Doesn't Lose Data

Cross-posting is inherently flaky. APIs go down, rate limits get hit, tokens expire. If Dev.to fails but Hashnode succeeds, I don't want to retry Hashnode. And I definitely don't want to lose track of what failed.

So I persist errors in a JSONB column on the post:

@Column({ type: 'jsonb', nullable: true, default: null })
crossPostErrors?: Record<string, string> | null;
// Example: { "devTo": "API 429: Rate limited", "medium": "Auth failed" }

After each cross-post attempt, the orchestrator merges new results with existing errors:

private async persistResults(postId: string, results: CrossPostResult[]) {
  const errors: Record<string, string> = {};
  const updates: Partial<Post> = {};

  for (const r of results) {
    if (r.success && r.url) {
      // Store the published URL
      if (r.platform === 'dev.to') updates.devToArticleUrl = r.url;
      if (r.platform === 'hashnode') updates.hashnodeArticleUrl = r.url;
      // ... etc
      errors[r.platform] = '';  // Clear previous error
    } else if (r.error) {
      errors[r.platform] = r.error.replace(/<[^>]*>/g, '').slice(0, 300);
    }
  }

  // Merge with existing errors, clear resolved ones
  const existing = existingRow?.crossPostErrors || {};
  const merged = { ...existing, ...errors };
  for (const k of Object.keys(merged)) {
    if (!merged[k]) delete merged[k];
  }

  updates.crossPostErrors = Object.keys(merged).length > 0 ? merged : null;
  await this.repo.update(postId, updates);
}

This gives me:

Per-platform error tracking — see exactly which platform failed and why
Auto-clearing — when a retry succeeds, the error gets removed
Sanitized messages — HTML tags stripped, truncated to 300 chars (no raw stack traces in the DB)

The Retry Mechanism

Sometimes Dev.to is down, or your Hashnode API key rotated. The admin dashboard shows per-platform error messages, and there's a retryCrossPost mutation that lets you retry specific platforms:

async retryCrossPost(
  postId: string,
  userId: string,
  platforms: string[]
): Promise<CrossPostResult[]> {
  const post = await this.repo.findOne({
    where: { id: postId },
    relations: ['author', 'tags'],
  });

  if (post.author.id !== userId && post.author.role !== 'ADMIN') {
    throw new Error('Not authorized');
  }

  if (post.status !== 'PUBLISHED') {
    throw new Error('Can only retry for published posts');
  }

  return this.crossPost(post, post.author, platforms);
}

The platforms parameter lets you retry just the ones that failed. No need to re-publish everywhere.

Canonical URLs — The SEO Angle

One thing most cross-posting guides skip: canonical URLs. When the same article exists on 5 platforms, Google needs to know which one is the original.

Every adapter sets canonical_url (Dev.to), originalArticleURL (Hashnode), or canonicalUrl (Medium) pointing back to the ZyVop URL:

const zyvopUrl = `${this.parser.getFrontendUrl()}/${post.slug}`;
const canonicalUrl = post.canonicalUrl || zyvopUrl;

If the author has set a custom canonical URL (maybe they originally published on their personal blog), that takes priority. Otherwise, ZyVop is the canonical source. This prevents duplicate content penalties in search rankings.

What I'd Do Differently

Queue-based publishing. Currently, cross-posting happens synchronously during the publish flow. If Medium's API takes 10 seconds, the user waits 10 seconds. I should push each platform to a BullMQ job and return immediately.
Webhook-based updates. Right now, editing a post triggers re-publishing to all platforms. A smarter approach would be diffing the content and only re-publishing if something meaningful changed.
Image hosting. Some platforms don't accept external image URLs. Hashnode and Dev.to handle this fine, but Medium can be finicky. A proper solution would upload images to each platform's CDN.

The Module Structure

Here's how the code is organized:

src/modules/cross-post/
├── cross-post.module.ts           # NestJS module definition
├── cross-post.service.ts          # Orchestrator
├── cross-post-parser.service.ts   # HTML→Markdown + table conversion
└── adapters/
    ├── devto.adapter.ts           # Dev.to REST API
    ├── hashnode.adapter.ts        # Hashnode GraphQL API
    ├── medium.adapter.ts          # Medium REST API
    ├── bluesky.adapter.ts         # Bluesky AT Protocol
    └── wordpress.adapter.ts       # WordPress REST API

7 files. ~450 lines total. Each adapter is 70-120 lines. The parser is ~100 lines. The orchestrator is ~140 lines.

Adding a new platform (say, LinkedIn or Ghost) means creating one new adapter file, registering it in the module, and adding the toggle flags to the Post entity. The orchestrator doesn't change.

Wrapping Up

Cross-posting isn't glamorous infrastructure, but it compounds. Every post automatically reaching 5 audiences means 5x the surface area for discovery — with zero extra effort after the initial setup.

The adapter pattern keeps each platform's quirks contained. The error persistence makes failures visible instead of silent. And the canonical URL strategy keeps SEO clean.

If you're building a blogging platform (or even just a personal blog), this is one of those features that pays for itself on day one.

This is part of my Building in Public series, where I share the actual architecture behind ZyVOP — the blogging platform I'm building for developers. Follow along for more deep dives into the engineering decisions behind the product.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Why I Moved ZyVOP From Vercel to a VPS With Docker and Cloudflare Tunnel

Sanjay Singh — Sun, 16 Aug 2026 14:46:22 +0000

When I launched ZyVOP — a developer publishing platform with auto cross-posting to Dev.to, Hashnode, and Medium — Vercel felt like the obvious choice. Fast deploys, zero infrastructure management, global edge network. Perfect for moving fast.

Then the bills came in.

And then the edge function timeouts started hitting.

This is the story of why I moved ZyVOP off Vercel, how I set up a VPS with Docker and Cloudflare Tunnel, and what I'd do differently if I started over.

The Vercel Problem

Vercel is genuinely excellent for static sites and simple apps. But ZyVOP isn't a simple app.

We run:

Real-time notifications
Cross-posting jobs to multiple external platforms
An AI news feed updated continuously
Background processing for markdown rendering and KaTeX

Two problems emerged fast.

Problem 1: Cost

Vercel's free tier is generous until it isn't. The moment you hit production traffic with background jobs and API routes firing constantly, you're looking at Pro tier ($20/month) minimum — and that climbs quickly with function invocations, bandwidth, and team seats.

For a bootstrapped platform in beta, that's real money that should be going toward writer payments and content, not infrastructure.

Problem 2: Edge Function Execution Limits

Vercel's edge functions have a hard execution time limit. For simple request/response cycles that's fine. For our cross-posting engine — which needs to authenticate with multiple external APIs, handle retries, and confirm canonical URLs — we were constantly bumping against the ceiling.

The cross-posting would silently fail on complex posts. Writers would publish, think it cross-posted, and then notice their Dev.to article never appeared. That's a trust-destroying bug.

The fix wasn't to optimize the code. The fix was to get off a platform with artificial execution limits.

Why VPS + Docker + Cloudflare Tunnel

I evaluated a few options:

Option	Cost	Control	Complexity
Vercel Pro	$20+/mo	Low	Low
Railway	$5-20/mo	Medium	Low
Render	$7+/mo	Medium	Low
VPS + Docker	$4-10/mo	Full	Medium
VPS + Docker + Cloudflare Tunnel	$4-10/mo	Full	Medium

The VPS route won on cost and control. Cloudflare Tunnel was the key addition that made it production-ready without the complexity of managing SSL certificates, exposing ports, or configuring Nginx from scratch.

The Architecture

Here's what the traffic flow looks like now:

User Request
     ↓
Cloudflare Edge (CDN, DDoS protection, SSL termination)
     ↓
Cloudflare Tunnel (encrypted, no exposed ports)
     ↓
cloudflared daemon (running in Docker)
     ↓
App Container (Node.js)
     ↓
Background Workers (cross-posting, notifications)

No SSL certificate management. No Nginx config to maintain. Cloudflare handles all of that at the edge. The only port you need open on your VPS firewall is SSH — Cloudflare Tunnel handles all inbound web traffic.

The Setup

1. VPS Configuration

I'm running a VPS with 4 vCPU, 8GB RAM, and 160GB SSD at $8/month. That's more than enough for ZyVOP's current load with significant headroom to scale.

First thing after provisioning: lock it down.

# Create non-root user
adduser deploy
usermod -aG sudo deploy

# Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart ssh

# Basic firewall — only allow SSH
ufw allow OpenSSH
ufw enable

No HTTP or HTTPS ports open. Cloudflare Tunnel handles inbound traffic entirely.

2. Docker Compose Setup

Everything runs in Docker. Here's the core structure:

# docker-compose.yml
services:
  frontend:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - NEXT_PUBLIC_API_URL=https://api.zyvop.com
        - BACKEND_URL=https://api.zyvop.com
    container_name: zyvop_frontend
    restart: always
    env_file:
      - .env.production
    networks:
      - external_backend_network

  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: zyvop_cloudflared
    restart: always
    command: tunnel run
    env_file:
      - .env.production
    networks:
      - external_backend_network

networks:
  external_backend_network:
    name: zyvop_zyvop-network
    external: true

And in .env.production:

TUNNEL_TOKEN=your_tunnel_token_here
NEXT_PUBLIC_API_URL=https://api.zyvop.com
BACKEND_URL=https://api.zyvop.com

Key decisions here:

External network — the frontend connects to the backend via a shared Docker network (external: true). The backend runs in a separate compose stack, keeping concerns cleanly separated.

restart: always — both containers restart automatically after a crash or VPS reboot. No manual intervention needed.

restart: always on cloudflared — the tunnel must never go down. This gets the most aggressive restart policy.

Never hardcode the tunnel token — keep it in .env.production and out of your compose file. If your repo is ever public or shared, a hardcoded token is an immediate security incident.

3. Cloudflare Tunnel Configuration

Setting up the tunnel takes about 10 minutes — and you don't need to install anything locally. Everything is done through the Cloudflare dashboard and Docker.

Step 1 — Create the tunnel in Cloudflare dashboard

Go to one.dash.cloudflare.com → Networking → Tunnels → Create a Tunnel

Note: The old dash.teams.cloudflare.com URL is retired as of 2026. Everything now lives at one.dash.cloudflare.com.

Choose Cloudflared as the connector type
Name your tunnel (e.g. zyvop-production)
Cloudflare will generate a tunnel token — copy it

Step 2 — Add your public hostname

Still in the dashboard, under your tunnel settings:

Hostname: zyvop.com
Service: http://app:3000

Cloudflare automatically creates the DNS record for you.

Step 3 — Pass the token to Docker

Add the token to your .env file:

CLOUDFLARE_TUNNEL_TOKEN=your_token_here

Your cloudflared Docker service picks it up automatically:

cloudflared:
  image: cloudflare/cloudflared:latest
  restart: always
  command: tunnel run
  env_file:
    - .env.production

With TUNNEL_TOKEN set in .env.production, cloudflared picks it up automatically. That's it — no local installation, no CLI setup, no credentials file to manage. The entire tunnel runs inside Docker and connects on every deploy.

4. Cloudflare Cache Rules

This is where you get Vercel-like performance without Vercel's price. In your Cloudflare dashboard, add cache rules for static assets:

If: File extension matches js, css, png, jpg, woff2, svg
Then: Cache Everything
Edge TTL: 1 month
Browser TTL: 1 day

Static assets now serve from Cloudflare's edge globally — your VPS only handles dynamic requests.

What Broke During Migration

I won't pretend it was seamless. A few things broke:

Cross-posting webhooks — These were firing on Vercel's edge and assumed a specific timeout behavior. Moving them to a persistent worker process actually fixed the timeout problem but required rewriting the job queue logic.

Environment variables — Vercel's environment variable management is seamless. On VPS you manage .env files yourself. Use docker secret or a proper secrets manager in production — don't commit .env to your repo.

Cold starts are gone, but so is auto-scaling — Vercel scales to zero and back up automatically. On VPS your container is always running, which is better for consistent performance but means you need to think about capacity planning.

Cloudflare cache after deleting from Vercel — This one caught me off guard. After removing the site from Vercel and pointing DNS through Cloudflare Tunnel, the site was slow to load for new visitors. The reason: Cloudflare was still serving cached responses from the old Vercel origin. The fix is straightforward but non-obvious if you haven't hit it before:

# Cloudflare Dashboard → Your Domain → Caching → Configuration
# Click "Purge Everything"

Or via API:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Do this immediately after switching origins. Don't wait for cache to expire naturally — it can take hours and your users will see stale or broken pages during that window.

The Results

Cost: Down from projected $40-60/month on Vercel Pro to $8/month on VPS — 4 vCPU, 8GB RAM, 160GB SSD.

Edge function timeouts: Zero since migration. Cross-posting now completes reliably on every post.

Performance: Comparable for most users. Users geographically close to the VPS see similar speeds. Users far away are served cached assets from Cloudflare's edge network — so static content is fast globally.

Uptime: 99.9%+ since migration. Cloudflare Tunnel is rock solid.

Would I Recommend This Setup?

For a simple marketing site or small app — no. Vercel is still the right choice. The developer experience is genuinely hard to beat.

For a platform with background jobs, long-running processes, or cost sensitivity at scale — yes. VPS + Docker + Cloudflare Tunnel gives you production-grade infrastructure at a fraction of the cost, with none of the artificial limits.

The migration took about 1–2 hours including testing. The cost savings paid for that time investment within the first month.

What's Next

The current setup handles ZyVOP's beta load comfortably. When we need to scale:

Add a second VPS and load balance via Cloudflare
Move the database to a managed service
Introduce Redis for the job queue

But that's a future problem. For now, $8/month and zero timeouts is exactly where we need to be.

ZyVOP is a developer publishing platform with auto cross-posting to Dev.to, Hashnode, and Medium. If you're a developer who writes, publish your first post here.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

AI Text Watermarking: The Statistics Hiding Inside Every Sentence

Sanjay Singh — Sat, 15 Aug 2026 05:34:44 +0000

Something changed on August 2, 2026. Every new Claude model started embedding an invisible mark into the text it generates. You can't see it, strip it with backspace, or find it with Ctrl+F. But it's there — baked into which words were chosen.

Google's been doing the same thing since 2024. OpenAI still hasn't shipped text watermarking, though the research has existed for years. This isn't a niche topic anymore. It now touches text you generate every day.

Here's how it actually works.

First: what a watermark is not

Not hidden characters. Not invisible Unicode. Not metadata appended to the file.

The watermark is the text — specifically, a statistical bias in which words the model picked. That single insight is what everything else follows from.

How an LLM picks the next word

A language model doesn't know "the next word." It calculates a probability score over its entire vocabulary — typically 50,000 to 100,000+ tokens — then samples from that distribution.

If the model is mid-sentence and large, big, substantial, and considerable would each fit, they each get a score. Sampling turns that weighted distribution into an actual pick.

The watermark lives here — in which token gets picked.

The KGW mechanism (the green list)

The dominant approach comes from a 2023 ICML paper by Kirchenbauer, Geiping, and Wen. It's called KGW.

Before each token is sampled:

Take the previously generated token as a seed.
Use a secret key + a hash function to split the vocabulary into two groups: a green list and a red list (roughly 50/50).
Add a small constant δ to the logit scores of every green-list token.
Sample normally from the nudged distribution.

The bias is tiny — on any single token, nothing looks off. But over 300 tokens, if 62% came from the green list when chance predicts 50%, that's a statistically significant event. It doesn't happen by accident.

Detection needs just two things: the text, and the same secret key. Re-derive the green/red split at each position using the same hash — it's deterministic, so it reproduces exactly.

Count the green tokens. Run a one-proportion z-test. If the z-score clears the threshold, the watermark is there.

The z-score grows with the square root of document length. Short texts rarely have enough tokens to reach significance.

Google's SynthID: tournament sampling

Google's SynthID-Text, published in Nature in 2024, takes a different path.

Instead of a green/red split, it samples multiple candidate tokens, assigns each a pseudorandom g-value keyed to a secret, then runs a tournament-style knockout to pick the winner. Less quality degradation than KGW's binary approach, and harder to spoof. The tradeoff is compute.

Google has used SynthID on Gemini app and web outputs since 2024. The API has been a documented exception.

Claude's watermark (August 2026)

Anthropic hasn't published the exact mechanism. What's confirmed:

Effective August 2, 2026, all newly launched Claude models embed an imperceptible watermark in generated text.
This applies globally — not just EU users — across Claude.ai, the API, Claude Code, and cloud partners.
Files (.svg, .png, .jpg) get C2PA-compliant provenance metadata instead of a token-level signal.
Older models will follow before the EU grace period ends December 2, 2026.

GPTZero's CTO Alex Cui published a technical thread on August 11 explaining how frontier labs typically implement text watermarking at production scale. He described the KGW approach — hash over previous tokens plus a secret key, green/red vocabulary split, detection by counting green draws — as the method fast enough for streaming models.

Worth noting: he was describing the general industry method, not Claude's confirmed implementation. Anthropic hasn't disclosed what they actually use. But what Cui described is consistent with everything public.

One confirmed detail: the model itself isn't aware it's being watermarked. The signal is injected at the sampling layer.

What erases it

Light paraphrase dilutes, doesn't erase. A one-pass rewrite weakens the signal but rarely kills it.

The WaterPark benchmark (J. Liang et al., EMNLP Findings 2025) tested ten watermarking methods against twelve attack types. A single ChatGPT paraphrase pass dropped every tested method below 30% TPR. For SynthID specifically, TPR fell from 0.998 on clean text to 0.498 under moderate paraphrasing — half the signal, one pass.

Re-composition kills it. The harder attack isn't "rewrite this paragraph" — it's "read this, then write a new version from scratch." When a model regenerates from a summary or outline, the original token choices are gone and so is the fingerprint. Published literature on summarization-based attacks consistently shows detection collapsing toward chance under full rewrite.

Translation. Translate to another language, then back. The vocabulary partition was defined for the source language. A different tokenizer sees different splits.

Fine-tuning. If the watermarked model gets fine-tuned on new data, the sampling distribution shifts and the signal fades.

What doesn't erase it: copy-paste, reformatting, changing fonts, or adding punctuation. None of that touches which tokens were picked.

The authorship trap

The biggest misconception about this technology is what it proves.

A watermark doesn't mean a human didn't write the text. It doesn't mean one did. It doesn't prove authorship at all.

It means Claude processed that text — even if you only asked it to proofread a paragraph or fix formatting. Anthropic says the mark only shows Claude "had a hand in something," not that Claude wrote the whole thing.

This matters for academic integrity enforcement. The pre-watermark AI detectors — pure statistical classifiers — already have documented false-positive problems.

A 2023 study (W. Liang et al., Patterns, vol. 4, issue 7) tested seven detectors on 91 TOEFL essays written by non-native English speakers. False-positive rate: 61.3%. The same detectors classified native-speaker essays with near-perfect accuracy.

UCLA opted out of Turnitin's AI detection at launch. UC San Diego Extended Studies deactivated it in April 2025.

Watermarks are more reliable than classifiers when the signal is intact. But "intact" is a big caveat. And a watermark's absence proves nothing.

Files: C2PA

Text gets a token-level signal. Files get something different.

C2PA (Coalition for Content Provenance and Authenticity) is an open standard for attaching cryptographically signed provenance metadata to media files. It records that a file was processed by Claude and flags whether it's been tampered with since. Any C2PA-compliant reader can verify the signature.

The catch: it lives in the file's metadata layer, not the content. Strip the metadata and the signal is gone — meaningfully different from a text watermark, which travels with the words.

Where this is heading

No detection API has shipped yet. Anthropic confirmed one is coming ("that you can use yourself"), but as of mid-August 2026, there's no public tool to check whether a given piece of text carries the Claude watermark. An Anthropic engineer put it plainly on August 12: "it's not perfect, you can edit it, but it's a first step."

The EU AI Act's Article 50 is what triggered deployment. OpenAI hasn't announced a text watermark. The research has existed since Aaronson and Kirchner's 2022 proposal — the deployment gap has just been long.

The mechanism is real. The gap between "signal is embedded" and "signal can be verified by anyone" is also real.

The one-sentence version

An LLM generates text by sampling from a probability distribution over its vocabulary; a watermark biases that sampling using a secret key, leaving a statistically detectable pattern in which tokens were chosen — a pattern that survives copying and light editing, but collapses under full re-composition.

Sources:

Kirchenbauer et al., A Watermark for Large Language Models (ICML 2023)
Kirchenbauer et al., On the Reliability of Watermarks for Large Language Models (ICLR 2024)
Dathathri et al., Scalable watermarking for identifying LLM outputs (SynthID-Text, Nature 2024)
W. Liang et al., GPT detectors are biased against non-native English writers (Patterns, vol. 4, issue 7, 2023)
J. Liang et al., Watermark under Fire: A Robustness Evaluation of LLM Watermarking (WaterPark, EMNLP Findings 2025)
TechCrunch, Anthropic says it will watermark text generated by its AI models (Aug 11, 2026)
Alex Cui / GPTZero, technical thread on text watermarking methods (Aug 11, 2026)

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Why I Built a Developer Platform Instead of Just Using Dev.to

Sanjay Singh — Wed, 12 Aug 2026 12:36:08 +0000

For years, whenever I finished a technical article, I had a routine: paste the Markdown into Dev.to, hit publish, and watch the views roll in. It was simple. Dev.to has a fantastic community, great distribution, and it's undeniably one of the best places for developers to share knowledge.

But over time, a lingering frustration started to set in.

I realized I was building someone else's domain authority. I was locked into their editor, their analytics, and their feature set. If I wanted to add a custom email capture, integrate AI tooling, or do deep data analysis on my audience, I couldn't. I was a guest in someone else's house.

That frustration led to an "aha!" moment: What if I treated third-party platforms purely as distribution channels, and built my own platform as the canonical home for my content?

That's how ZyVOP was born. It's a custom-built developer platform with a Next.js frontend, a NestJS backend, and a Groq AI integration for content intelligence. Here is the story of why I built it, the business case for doing so, and the technical deep dive into how it works.

The Business Case: True Ownership and Syndication

If you're manually cross-posting or giving away your canonical URLs to Dev.to, ZyVOP solves both problems.

When you publish exclusively on a third-party platform, your data is siloed. With ZyVOP, the primary focus is True Data Ownership.

Instead of choosing one platform, ZyVOP acts as the central hub. I write the article once using a custom Tiptap editor (with support for KaTeX math and Mermaid diagrams), and ZyVOP automatically syndicates it out. Because it originates on my domain, search engines recognize ZyVOP as the canonical source.

But it goes beyond just posting articles. Owning the platform allowed me to build an entire ecosystem around the user:

Custom Notifications: Integration with Brevo for fine-grained email digests, comment alerts, and automated re-engagement flows.
AI Integration: Native hooks to Groq for AI-assisted writing and content enrichment.
Internal Intelligence: Instead of relying on basic view counts, owning the platform allows me to integrate Groq AI for deep content intelligence, suggesting relevant tags and tracking cross-channel engagement to help authors build their audience organically.
Enterprise-grade Security: Implementing Two-Factor Authentication (2FA) with backup codes — a feature you rarely get out-of-the-box on simple blogging platforms.

The Technical Deep Dive

Building a platform that can parse rich text, syndicate to multiple APIs, and run data intelligence requires a robust stack. Let's look under the hood.

A Powerful Backend Entity (NestJS & PostgreSQL)

In ZyVOP, the user is more than just an email and password. Because the platform acts as a syndication engine, the User entity (built with TypeORM and GraphQL) holds the keys to the entire developer ecosystem.

Here's a look at how we structure integrations in our backend:

// backend/src/modules/users/entities/user.entity.ts
@Entity('users')
export class User {
  @PrimaryGeneratedColumn('uuid')
  id!: string;

  // Syndication API Keys
  @Column({ type: 'varchar', nullable: true })
  devToApiKey?: string | null;

  @Column({ type: 'varchar', nullable: true })
  hashnodeApiKey?: string | null;

  @Column({ type: 'varchar', nullable: true })
  mediumApiKey?: string | null;

  // AI Integrations
  @Column({ type: 'varchar', nullable: true })
  groqApiKey?: string | null;

  // Custom Notifications
  @Column({ type: 'boolean', default: true })
  emailUpdates!: boolean;

  @Column({ type: 'boolean', default: true })
  weeklyDigest!: boolean;

  // Security
  @Column({ type: 'boolean', default: false })
  twoFactorEnabled!: boolean;
}

This entity allows a single user to manage their entire digital presence across the web from one dashboard.

The Custom HTML-to-Markdown Parser

One of the hardest parts of syndication is dealing with different Markdown flavors. ZyVOP's frontend editor (Tiptap) outputs rich HTML, but platforms like Dev.to require very specific Markdown.

Instead of relying on generic libraries that often break code blocks or custom formatting, I built a custom parser (html-to-markdown.js) using regex to gracefully downgrade HTML into Dev.to-compatible Markdown, injecting the canonical URL at the end:

function htmlToDevToMarkdown(html, canonicalUrl) {
    if (!html) return '';
    let text = html;

    // Preserve code blocks gracefully
    text = text.replace(/<pre><code[^>]*>([\s\S]*?)<\/code><\/pre>/gi, (_, code) => `\n\`\`\`\n${decodeHtml(code)}\n\`\`\`\n`);
    text = text.replace(/<code>([\s\S]*?)<\/code>/gi, '`$1`');

    // Convert headers, bold, and links
    text = text.replace(/<h2[^>]*>([\s\S]*?)<\/h2>/gi, '## $1\n');
    text = text.replace(/<strong>([\s\S]*?)<\/strong>/gi, '**$1**');
    text = text.replace(/<a[^>]*href="([^"]*)"[^>]*>([\s\S]*?)<\/a>/gi, '[$2]($1)');

    // Clean up remaining tags
    text = text.replace(/<[^>]+>/g, '');
    text = decodeHtml(text);

    // Inject Canonical Source
    text += `\n\n---\n\n*Originally published on [ZyVOP](${canonicalUrl})*`;
    return text;
}

Together, these two layers — the backend entity and the parser — form the core of ZyVOP's syndication engine.

The Architecture of ZyVOP

To visualize how all these pieces fit together, here is the architecture of the ZyVOP ecosystem:

flowchart TD
    %% Core Entities
    Author([Author])
    Reader([Reader])

    %% Frontend Application
    subgraph Frontend [Next.js App]
        Editor[Tiptap Rich Editor]
        UI[Tailwind UI]
        Apollo[Apollo GraphQL]
    end

    %% Backend Application
    subgraph Backend [NestJS Backend]
        API[GraphQL API]
        Auth[Auth & 2FA Service]
        Syndication[Syndication Engine]
    end

    %% Data Persistence
    DB[(PostgreSQL)]

    %% External Ecosystem
    subgraph External [Syndication & Ecosystem]
        DevTo[Dev.to]
        Hashnode[Hashnode]
        Medium[Medium]
        Bluesky[Bluesky]
        Brevo[Brevo Mailing]
    end

    %% Intelligence Layer
    subgraph IntelligenceLayer [Intelligence Layer]
        Analytics[Internal Analytics]
        Groq[Groq AI]
    end

    %% Routing
    Author --> Editor
    Reader --> UI
    Editor --> Apollo
    UI --> Apollo

    Apollo <--> API
    API <--> Auth
    API <--> Syndication
    Auth <--> DB
    Syndication <--> DB

    %% Outbound Integrations
    Auth --> Brevo
    Syndication -.->|Cross-Post| DevTo
    Syndication -.->|Cross-Post| Hashnode
    Syndication -.->|Cross-Post| Medium
    Syndication -.->|Cross-Post| Bluesky

    %% Intelligence
    Syndication <--> Analytics
    API <--> Groq

Conclusion

Building a developer platform from scratch isn't for the faint of heart. It means maintaining your own infrastructure, dealing with SEO, managing Postgres migrations, and parsing messy HTML.

ZyVOP isn't just a blog — it's a syndication engine that cross-posts to Dev.to, Hashnode, Medium, and Bluesky in one click, with canonical URLs, 2FA, and AI tooling built in. I still love Dev.to. I just don't live there anymore.

ZyVOP is open to early writers — publish your first post here.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Token Budgeting: The Engineering Skill Nobody Talks About

Sanjay Singh — Sat, 20 Jun 2026 17:38:41 +0000

1. The Misconception That's Costing You Money

Ask a developer how to reduce their LLM bill and they'll say: "write shorter prompts." Remove adjectives. Trim examples. Cut the system prompt.

This isn't wrong — it's just the lowest-leverage version of the right idea. It optimizes the 4% of your context that is the actual user message while ignoring the 96% that is conversation history, system prompt, idle tool schemas, and over-retrieved documents.

Token optimization is a context engineering problem. The real questions are:

What is in your context that doesn't need to be there?
Is your context structured so the cache can work?
Is the model you're paying for the right one for this specific task?

Answer those and you'll reduce your bill by 60–80%. Shorten prompts and you'll reduce it by 5%.

2. Measure First: You Can't Optimize What You Can't See

Before touching anything, instrument what you have. Every provider returns token usage in the API response — read it.

// Wrap your API calls to log token usage from day one
async function loggedCompletion(params: Anthropic.MessageCreateParams) {
  const response = await client.messages.create(params);
  const { input_tokens, output_tokens,
          cache_read_input_tokens, cache_creation_input_tokens } = response.usage;

  console.log({
    inputTokens:    input_tokens,
    outputTokens:   output_tokens,
    cacheHits:      cache_read_input_tokens   ?? 0,   // paid 10% of normal
    cacheWrites:    cache_creation_input_tokens ?? 0,  // paid 125% (first call)
    estimatedCost: (
      (input_tokens  * 0.000003) +
      (output_tokens * 0.000015) +
      ((cache_read_input_tokens ?? 0) * 0.0000003)
    ).toFixed(6),
  });

  return response;
}

Count tokens before you send to understand what a request costs before paying for it:

const count = await client.messages.countTokens({
  model:    'claude-sonnet-4-6',
  system:   SYSTEM_PROMPT,
  tools:    TOOLS,
  messages: conversationHistory,
});
console.log(`This call: ${count.input_tokens} input tokens`);

Run this for 48 hours before optimizing anything. The distribution will tell you exactly which lever to pull first.

3. The 2026 Pricing Landscape

Before optimizing, know what you're paying. Two facts dominate the table:

Model	Input /1M	Output /1M	Cached Input	Context
Claude Opus 4.8	$5.00	$25.00	$0.50	1M
Claude Sonnet 4.6	$3.00	$15.00	$0.30	1M
Claude Haiku 4.5	$0.80	$4.00	$0.08	200K
GPT-5.5	$5.00	$30.00	$0.50	1M
GPT-4.1	$2.00	$8.00	$1.00	1M
GPT-4.1 Nano	$0.10	$0.40	$0.05	1M
DeepSeek V4 Flash	$0.14	$0.28	$0.003	1M

Fact 1: Output costs 4–8× more than input. A verbose response is far more expensive than a verbose prompt. Controlling output length matters more than controlling input length.

Fact 2: The model spread is 89×. GPT-4.1 Nano at $0.10/1M input vs Claude Opus 4.8 at $5.00/1M. Every routine task sent to a frontier model burns 10–50× its necessary cost.

xychart-beta
    title "Output Token Price per 1M (USD) — June 2026"
    x-axis ["DeepSeek V4 Flash", "GPT-4.1 Nano", "Haiku 4.5", "GPT-4.1", "Sonnet 4.6", "Opus 4.8", "GPT-5.5"]
    y-axis "$/1M output tokens" 0 --> 32
    bar [0.28, 0.40, 4.00, 8.00, 15.00, 25.00, 30.00]

Cache savings that stack with any of the above: Anthropic 90% off cached input, OpenAI 50% off automatically, Batch API 50% off async requests at both providers.

4. Where Your Tokens Actually Go

Most teams optimize the wrong things because they haven't diagnosed where their tokens land.

pie title "Typical Token Distribution — Multi-Turn Agent Session"
    "Conversation history (replayed each turn)" : 42
    "System prompt (replayed each turn)" : 18
    "Tool schemas (loaded but often unused)" : 15
    "RAG retrieved context" : 14
    "Actual user message" : 7
    "Model output" : 4

The user message — the thing most developers try to shorten — is 4% of the total. The big cost drivers are conversation history and system prompt, both of which replay in full on every single turn.

The quadratic growth problem: Every new message replays the entire prior conversation from scratch. A session with n equal-length turns doesn't cost n turns — it costs n(n+1)/2 turn-equivalents.

xychart-beta
    title "Cumulative Input Tokens — 200-Token Average Turn"
    x-axis ["Turn 5", "Turn 10", "Turn 20", "Turn 30", "Turn 50"]
    y-axis "Cumulative tokens (thousands)" 0 --> 260
    bar [3, 11, 42, 93, 255]

A 50-turn conversation pays for 255,000 input tokens from something that generated roughly 10,000 tokens of actual content. This compounds silently and is the dominant cost driver for any application with extended conversations.

5. Lever 1: Prompt Caching — 90% Off Static Content

Prompt caching is the highest single-impact optimization available if your app has a consistent system prompt, tool definitions, or reference documents. At Anthropic, cached tokens cost 10% of the normal rate. At OpenAI, 50% off automatically.

The mechanism: Claude computes a KV cache of your prompt prefix. On the next request, if the prefix is identical, it reuses the cached state instead of reprocessing it.

const response = await client.messages.create({
  model:      'claude-sonnet-4-6',
  max_tokens: 1024,
  system: [
    {
      type:          'text',
      text:          SYSTEM_PROMPT,          // 3,000+ tokens of static context
      cache_control: { type: 'ephemeral' },  // ← mark for caching
    },
  ],
  messages: conversationHistory,
});

// Inspect the result — is caching actually working?
console.log({
  cacheHits:   response.usage.cache_read_input_tokens,    // paid 10%
  cacheWrites: response.usage.cache_creation_input_tokens, // paid 125% (once)
});

The rules you must know before caching anything:

Minimum 1,024 tokens per block to qualify. Sub-1,024 blocks are silently ignored.
Default TTL is 5 minutes. Requests spaced further apart miss the cache — use the 1-hour extension for slower workflows.
Up to 4 cache breakpoints per request. Use them on your four largest static blocks.
Cache writes cost 25% more on the first call. Breakeven is typically 3–4 requests.

Cache structure: the ordering that makes or breaks hits

Caching is prefix-based. A single dynamic element placed before your static content breaks every cache hit. The correct order — every time:

// ✅ CORRECT — static content first, dynamic last
await client.messages.create({
  system: [
    { type: 'text', text: SYSTEM_PROMPT,   cache_control: { type: 'ephemeral' } },
    { type: 'text', text: TOOL_DOCS,       cache_control: { type: 'ephemeral' } },
    { type: 'text', text: REFERENCE_DOCS,  cache_control: { type: 'ephemeral' } },
  ],
  messages: [
    ...conversationHistory,                // dynamic — grows per turn
    { role: 'user', content: userMessage }, // always last
  ],
});

// ❌ WRONG — timestamp in the system block breaks every cache hit
system: [{
  type: 'text',
  text: `Current time: ${new Date().toISOString()}\n${SYSTEM_PROMPT}`,
  //     ↑ changes every second — cache never activates
}]

// ✅ Put dynamic values in the user message instead
messages: [{ role: 'user', content: `[${new Date().toISOString()}] ${userMessage}` }]

For OpenAI, caching is automatic — keep the prompt prefix identical across calls and the 50% discount applies with no code changes.

6. Lever 2: Context Pruning and Compaction

Caching addresses static content. Pruning addresses the quadratic growth of conversation history.

Summarize old turns into a cached block:

async function prepareContext(messages: Message[], keepRecentTurns = 6) {
  if (messages.length <= keepRecentTurns * 2) {
    return { summary: null, messages };
  }

  const older  = messages.slice(0, -(keepRecentTurns * 2));
  const recent = messages.slice(-(keepRecentTurns * 2));

  // Use a cheap model for summarization — this is simple work
  const res = await client.messages.create({
    model:      'claude-haiku-4-5',
    max_tokens: 300,
    messages: [{
      role:    'user',
      content: `Summarize this conversation in under 200 words.
Include: user's goal, decisions made, current status. Exclude: detailed reasoning.
${older.map(m => `${m.role}: ${m.content}`).join('\n')}`,
    }],
  });

  return { summary: res.content[0].text, messages: recent };
}

// Use the summary as a second cached block
const { summary, messages } = await prepareContext(history);

await client.messages.create({
  system: [
    { type: 'text', text: SYSTEM_PROMPT, cache_control: { type: 'ephemeral' } },
    ...(summary ? [{ type: 'text' as const, text: `## Prior context\n${summary}`,
                     cache_control: { type: 'ephemeral' as const } }] : []),
  ],
  messages,
  max_tokens: 1024,
});

The Haiku summarization call costs a fraction of a cent. The savings from not replaying 30 turns of history on every subsequent call are substantial.

Warning: Over-pruning context degrades answer quality and triggers retries that cost more than the context you saved. The goal is the smallest sufficient context, not the smallest possible one.

7. Lever 3: Model Routing — Pay for Reasoning Only When You Need It

This is the highest-leverage structural change most teams never make. The 89× price spread between cheap and frontier models means every routine task sent to Opus burns unnecessary budget.

// A cheap classifier routes tasks to the right model tier
async function classifyTask(message: string): Promise<'simple' | 'medium' | 'complex'> {
  const res = await client.messages.create({
    model:      'claude-haiku-4-5',  // $0.80/1M — the classifier itself is cheap
    max_tokens: 5,
    messages: [{
      role:    'user',
      content: `Reply with ONE word: simple, medium, or complex.
simple = extraction, classification, yes/no, short lookups
medium = summarization, structured analysis, multi-step predictable tasks
complex = deep reasoning, architecture decisions, research synthesis
Task: "${message}"`,
    }],
  });

  const result = res.content[0].text.trim().toLowerCase();
  return (['simple', 'medium', 'complex'].includes(result) ? result : 'medium') as any;
}

const MODEL_MAP = {
  simple:  'claude-haiku-4-5',   // $4.00/1M output
  medium:  'claude-sonnet-4-6',  // $15.00/1M output
  complex: 'claude-opus-4-8',    // $25.00/1M output
};

const MAX_TOKENS_MAP = { simple: 256, medium: 1024, complex: 4096 };

export async function routedCompletion(message: string, context: ConversationContext) {
  const complexity = await classifyTask(message);
  return client.messages.create({
    model:      MODEL_MAP[complexity],
    max_tokens: MAX_TOKENS_MAP[complexity],
    system:     context.system,
    messages:   [...context.history, { role: 'user', content: message }],
  });
}

Real-world distribution for a typical support application: ~60% simple, ~30% medium, ~10% complex. Routing to Haiku for 60% of requests instead of Sonnet reduces total cost by roughly 40% on that portion alone — with no quality degradation on routine tasks.

8. Lever 4: Batch API — 50% Off Everything Async

Not every LLM request needs to be real-time. Both Anthropic and OpenAI offer batch APIs at 50% off with identical quality. If your users aren't waiting for the response, use it.

Good candidates: content classification, bulk summarization, document extraction, data enrichment, A/B prompt testing, nightly report generation.

// Anthropic Message Batches — 50% off, processed within 24 hours
const batch = await client.beta.messages.batches.create({
  requests: items.map(item => ({
    custom_id: item.id,
    params: {
      model:      'claude-sonnet-4-6',
      max_tokens: 512,
      system: [{ type: 'text', text: SYSTEM_PROMPT,
                 cache_control: { type: 'ephemeral' } }],
      messages: [{ role: 'user', content: item.content }],
    },
  })),
});

// Poll or webhook for results
for await (const result of await client.beta.messages.batches.results(batch.id)) {
  if (result.result.type === 'succeeded') {
    await saveResult(result.custom_id, result.result.message.content[0]);
  }
}

Stack caching with batching: a cached batch request on Sonnet 4.6 drops from $3.00/1M to $0.30/1M (cache) × 0.50 (batch) = $0.15/1M — a 95% reduction on that input.

9. Lever 5: Surgical RAG — Stop Dumping Documents

RAG pipelines are the most common source of unnecessary context bloat. Teams retrieve 10,000+ tokens by default because the context window can hold it — not because it improves results.

The research is clear: context window size does not drive quality. Placement and precision do. More context, placed poorly, actively hurts performance via the "lost in the middle" effect — models perform worse when critical information is buried mid-context.

async function surgicalRag(query: string, tokenBudget = 2000) {
  // Retrieve more candidates than you'll use
  const candidates = await vectorDB.search(query, { limit: 20 });

  // Filter by relevance score — weak matches add noise
  const relevant = candidates.filter(c => c.score >= 0.75);

  // Fill up to budget, best matches first
  let used = 0;
  const selected = [];
  for (const chunk of relevant) {
    if (used + chunk.tokenCount > tokenBudget) break;
    selected.push(chunk);
    used += chunk.tokenCount;
  }

  return selected
    .map((c, i) => `[Source ${i + 1}: ${c.source}]\n${c.content}`)
    .join('\n\n---\n\n');
}
// Result: ~1,500–2,000 tokens vs 10,000+ from naïve retrieval
// Same or better quality. Significantly lower cost.

The savings from surgical RAG are substantial — limiting retrieval to 2–3 focused chunks instead of 8–10 full documents can cut input tokens by more than 50%. Cache stable reference content (product docs, FAQs, policies) using prompt caching instead of re-retrieving it on every turn.

10. Anti-Patterns

1. Optimizing prompt length before diagnosing cost drivers Spending hours trimming 200 tokens from a system prompt when 20,000 tokens of conversation history are growing quadratically. Instrument first, optimize second.

2. max_tokens: 4096 as a default everywhere Output tokens cost 4–8× more than input. Set max_tokens deliberately:

Task	Appropriate max_tokens
Classification, yes/no	10
Factual lookup	256
Summary or analysis	512–1024
Document generation	2048–4096

3. Dynamic content in static blocks A timestamp, session ID, or A/B flag placed inside the system prompt block resets the cache prefix on every call. Every cached token becomes uncached. Move dynamic values to the user message.

4. Routing everything to the frontier model "to be safe" Safe is not the same as correct. Haiku handles 60% of real-world support tasks correctly. Routing those to Opus or GPT-5.5 burns 6–30× the necessary budget with no quality gain on routine work.

11. Case Study: $2,400 to $680

A team running a customer support AI agent across 1,200 daily conversations hit a $2,847 monthly bill after three months of growth. After applying the fixes in this guide:

pie title "Source of 72% Cost Reduction"
    "Model routing (Haiku for simple tasks)" : 41
    "Prompt caching (fixing the cache miss)" : 33
    "Context pruning (conversation history)" : 18
    "Output token budgeting (max_tokens)" : 8

Month 3: $2,847 → Month 6: $849. A 70% reduction while handling 18% more conversations per day. The largest single saving was model routing — not prompt caching — because the team had been sending every request including simple intent classification to Sonnet 4.6.

The full story with month-by-month numbers is in How I Cut My AI API Bill by 70%.

12. FAQ

Q: Should I optimize input tokens or output tokens first? Output tokens. They cost 4–8× more. Set max_tokens deliberately per task type, use structured output (JSON schema) to prevent verbose prose when you need data, and ask the model for concise responses where appropriate. This is the fastest single change to make.

Q: How do I know if prompt caching is actually working? Check cache_read_input_tokens in the API response. If it's 0 on every call, caching is not activating. Common reasons: content below the 1,024-token minimum, cache_control markers missing or misplaced, or dynamic content in the static block breaking the prefix.

Q: Is model routing worth the engineering effort for a small app? Yes, if you're running more than ~1,000 requests per day. The classifier call costs a fraction of a cent using Haiku and pays for itself immediately. Breakeven is typically within the first day of deployment.

Q: How does the Batch API affect latency — and when is it acceptable? Batch requests complete within 24 hours, typically much faster for small batches. It rules out any real-time user-facing flow. It's ideal for anything that runs in the background: classification pipelines, nightly report generation, bulk data extraction, A/B prompt testing. If your users aren't waiting for the response, use the Batch API.

13. Further Reading

Official Docs

Deep Dives

Tools

🛠️ CostGoat — Real-time LLM pricing comparison
🛠️ OpenRouter — Multi-provider routing + spend dashboard
🛠️ LangSmith — Token usage tracing per node in agent graphs

Measure before you optimize. Run client.messages.countTokens() on your most frequent request type before changing anything. The distribution will tell you exactly which lever to pull first.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Check it out guys

Sanjay Singh — Sat, 20 Jun 2026 17:36:36 +0000

ZyVOP

Jun 20

Scraping Wikipedia & Open Government Data with Python (2026 Complete Guide)

#pythonwikipediascraping #scrapewikipediapythontutorial #wikipediaapipython #datagovinpythonapitutorial

16 min read

DEV Community: Sanjay Singh

How We Built a Production Email Verification Pipeline That Saved Our Sender Reputation

The Problem: Why Naive Validation Kills You

The Architecture: 8 Verification Steps

Step 1: Normalization and Cache Check

Step 2: Regex Format Check (The Cheapest Gate)

Step 3: Role-Based Address Filtering

Step 4: MX Record Validation

Step 5: Disposable Domain Blocking

Step 6: Major Provider Short-Circuit

Step 7: Catch-All Domain Detection

Step 8: Full SMTP Verification with Greylisting Retry

The Timeout Safety Net

How Consuming Services Use Verdicts

Lessons Learned

1. Never trust SMTP results from major providers

2. UNKNOWN ≠ INVALID

3. Catch-all detection must precede SMTP probing

4. In-memory cache is fine at moderate scale

5. Greylisting is more common than you think

6. Role-based emails need their own verdict

The Numbers

Key Takeaways

The Real Cost of Running a Developer Platform

What I Was Running On (And What It Was Costing)

The New Stack

Why Each Line Item Is Worth Explaining

The VPS ($8/month)

Cloudflare Tunnel (Free)

Brevo (Free)

Groq (Free)

X Premium India (₹427/month ≈ $5)

What This Costs at Scale

The Number Nobody Talks About

I Built a System That Cross-Posts to 5 Platforms With One Click — Here's How

The Problem

The Adapter Pattern

Cross-Post Architecture

The Content Transformation Problem

HTML to Markdown Conversion

The HTML Table Problem

Platform-by-Platform Breakdown

Publish Flow

Dev.to — The Straightforward One

Hashnode — The GraphQL One

Medium — The Stubborn One

Bluesky — The Protocol One

WordPress — The Classic One

Platform Comparison

Error Handling That Doesn't Lose Data

The Retry Mechanism

Canonical URLs — The SEO Angle

What I'd Do Differently

The Module Structure

Wrapping Up

Why I Moved ZyVOP From Vercel to a VPS With Docker and Cloudflare Tunnel

The Vercel Problem

Problem 1: Cost

Problem 2: Edge Function Execution Limits

Why VPS + Docker + Cloudflare Tunnel

The Architecture

The Setup

1. VPS Configuration

2. Docker Compose Setup

3. Cloudflare Tunnel Configuration

4. Cloudflare Cache Rules

What Broke During Migration

The Results

Would I Recommend This Setup?

What's Next

AI Text Watermarking: The Statistics Hiding Inside Every Sentence

First: what a watermark is not

How an LLM picks the next word

The KGW mechanism (the green list)

Google's SynthID: tournament sampling

Claude's watermark (August 2026)

What erases it

The authorship trap

Files: C2PA

Where this is heading

2. `UNKNOWN` ≠ `INVALID`