DEV Community: julian-ros

Helicone is in maintenance mode. Here's what to do about it.

julian-ros — Fri, 25 Sep 2026 09:34:50 +0000

Helicone is in maintenance mode. Here's what to do about it.

Last updated: 2026-09-25

TL;DR

Helicone, the open-source LLM observability platform, was acquired by Mintlify in early March 2026 and is now in maintenance mode. If you're using it, nothing breaks today, but the dashboard (alerts, cost dashboards) and the gateway (proxying, caching, routing) have very different futures. Your migration decision depends almost entirely on which half you actually use. This article gives you a decision tree, a concrete migration diff, and an honest "stay for 90 days" option.

Why this matters now

Helicone isn't a niche tool. It's one of the most-starred open-source LLM observability projects on GitHub, and its proxy gateway sits in front of production LLM traffic at a lot of companies. When a project at this scale goes into maintenance mode, the question isn't "should I care" — it's "which half of my setup is about to become a liability."

The short answer: nothing breaks today. The gateway still proxies. The dashboard still shows data. But the roadmap is frozen, and the two halves of the product are diverging in usefulness in opposite directions.

What "maintenance mode" actually means here

Helicone was acquired by Mintlify in early March 2026. The public status page and the community threads make the situation clear: the gateway remains open-source and functional, but active development has stopped. No new features. Bug fixes only, at the maintainers' discretion. The hosted dashboard is the part most affected — it still works, but it's not getting meaningful investment.

There's no sunset date published. There's no EOL notice. That ambiguity is exactly why this article exists: you need to make a call without a deadline being handed to you.

The dashboard vs. the gateway: different futures

This is the load-bearing distinction of the whole piece, so let's be precise about it.

Component	What it does	Status going forward	Your risk
Dashboard	Cost tracking, request logs, alerts, session replays	Frozen; hosted version still runs but isn't improving	Medium — data keeps flowing, but alerts and dashboards rot
Gateway/proxy	Sits in front of LLM providers; caching, routing, retries, fallbacks	Open-source, functional, no active development	Low today, growing — no bug fixes for new provider APIs

If you only use the dashboard, you have more time than you think. If you use the gateway in front of production traffic, you have a real problem, and the problem compounds every time OpenAI, Anthropic, or Google ships a new API surface the proxy doesn't know about.

Decision tree: what to do based on how you use it

Are you using Helicone's gateway in front of production traffic?
│
├─ YES → Do you depend on caching, routing, or fallbacks?
│        │
│        ├─ YES → Migrate the gateway now. LiteLLM is the closest
│        │         open-source equivalent. See migration diff below.
│        │
│        └─ NO  → You're proxying for logging only. You can switch the
│                  logging layer without touching the gateway. Lower urgency.
│
└─ NO (dashboard only) → Do you have active alerts or cost dashboards
                         you check weekly?
         │
         ├─ YES → Plan a migration within 90 days. Export your data
         │        before you need it.
         │
         └─ NO  → You're fine for now. Revisit in a quarter.

The abandonment-risk screen

Before you pick a replacement, ask one question: how much of your Helicone setup is custom code you wrote against Helicone's specific API or SDK?

If the answer is "almost none" — you're calling helicone.init() and reading the dashboard — migration is a config change plus a data export. Days, not weeks.
If the answer is "we built custom routing rules, custom session logic, or custom alerting on top of Helicone's API" — budget real engineering time. This is where migrations stall.

Most teams overestimate how customized their setup is. Audit before you panic.

The LiteLLM security caveat (don't skip this)

If you're evaluating LiteLLM as the gateway replacement, be aware of a real, documented security issue: the Wiz Research "Off Guard" report (March 2025) disclosed vulnerabilities in LiteLLM's default setup, including SSRF and authentication bypass paths in the proxy when exposed improperly.

This doesn't mean "don't use LiteLLM." It means: if you deploy it, don't expose the proxy publicly without authentication, and keep it patched. The vulnerabilities were disclosed and fixed; the lesson is about deployment hygiene, not about the project being unsafe. Read the Wiz writeup and LiteLLM's own security docs before you deploy.

The migration diff

Here's what actually changes in your code when you move from Helicone's proxy to LiteLLM's proxy. This is the honest version — what you keep, what you lose, what you rewrite.

# BEFORE — Helicone proxy
import openai

client = openai.OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {HELICONE_API_KEY}",
        "Helicone-User-Id": user_id,
    },
)

# AFTER — LiteLLM proxy
import openai

client = openai.OpenAI(
    base_url="http://localhost:4000",  # your LiteLLM proxy
    api_key=LITELLM_VIRTUAL_KEY,        # LiteLLM-issued key, not the provider's
)

What you keep: the OpenAI-compatible interface, request/response logging, cost tracking.

What you lose: Helicone's session replay UI, its specific alerting rules, its dashboard UX. You'll rebuild equivalents in whatever you replace the dashboard with.

What you rewrite: any custom headers, custom routing rules, or SDK-specific session logic. This is the part that takes real time.

The "stay for 90 days" option

This is a legitimate choice, and it's underdiscussed.

If you're dashboard-only, or gateway-only with no custom logic, staying on Helicone for another quarter is rational. The gateway still works. The data still flows. Nothing is on fire.

But set a calendar reminder. The failure mode here isn't a hard outage — it's waking up in eight months to a broken integration with no migration plan and no one on the team who remembers how the proxy was configured. Maintenance mode doesn't kill you fast; it kills you by attrition.

What I actually did (and didn't) test

Full disclosure, because this topic deserves it: I tested the migration path above in a single-tenant environment with low throughput and OpenAI-compatible endpoints only. I did not test multi-tenant setups, high-volume routing, or Anthropic/Google-specific gateway features. Your mileage will vary, and the LiteLLM docs are the source of truth for anything I haven't touched.

Bottom line

Gateway in production with custom logic: migrate now, budget real time.
Gateway for logging only: switch the logging layer, keep the gateway until it breaks.
Dashboard only with active alerts: migrate within 90 days, export data first.
Dashboard only, no alerts: stay, set a quarterly reminder.

Nothing breaks today. That's not a reason to do nothing — it's the window to do it calmly.

Sources

Helicone status page — current operational state
Mintlify acquisition announcement — March 2026
Wiz Research: Off Guard — LiteLLM security disclosure, March 2025
LiteLLM proxy docs — migration reference
Helicone GitHub repository — commit activity, open issues
r/LLMDevs thread on Helicone maintenance mode — practitioner discussion
DEV.to: Helicone maintenance mode discussion — community reaction
Helicone docs: proxy configuration — pre-migration reference
LiteLLM security docs — deployment hygiene

Researched and drafted with AI assistance, checked against primary sources.

Claude Code now reads AGENTS.md — but it won't merge it with CLAUDE.md

julian-ros — Thu, 24 Sep 2026 21:58:24 +0000

Most tutorials about AI agent instruction files tell you what to put in them. Almost none tell you what happens when two of them exist at once — or what the evidence says about whether any of it works.

That gap matters right now, because Claude Code changed how it handles AGENTS.md in the September 18 release, and the change created a trap that's easy to fall into silently. Your instructions can stop being read without any error, warning, or visible difference in behavior. You just get worse results and blame the model.

This article covers the precedence rules as they actually work, a keep/cut framework for what belongs in these files, a 20-minute test to verify your setup, and the honest limitations of all of the above.

The precedence trap

Claude Code reads two kinds of instruction files:

CLAUDE.md — Claude Code's native project memory file
AGENTS.md — a cross-tool convention also read by other coding agents

As of the September 18 change, Claude Code reads AGENTS.md too. The part that trips people up is how it reads them when both exist in the same project.

It's a fallback, not a merge. When both files are present, Claude Code does not concatenate them, does not interleave them, and does not "combine the best of both." One file wins and the other is ignored. CLAUDE.md takes precedence; AGENTS.md is the fallback used when CLAUDE.md is absent.

flowchart TD
    A[Claude Code starts a session] --> B{CLAUDE.md present?}
    B -- yes --> C[Read CLAUDE.md only]
    B -- no --> D{AGENTS.md present?}
    D -- yes --> E[Read AGENTS.md only]
    D -- no --> F[No project instructions loaded]

The failure mode looks like this: you maintain a carefully tuned CLAUDE.md, then add an AGENTS.md so tools like Codex or other agents can share the same instructions. From that moment, every edit you make to AGENTS.md does nothing for Claude Code — and worse, if you move content from CLAUDE.md into AGENTS.md thinking you're consolidating, Claude Code loses those instructions entirely. Nothing errors. The agent just starts forgetting your conventions, and you spend an afternoon wondering why.

The reverse trap: you delete CLAUDE.md during a cleanup, assuming AGENTS.md covers the same ground. It does — but only if the content actually lives there. Fallback means substitution, not union. Anything that existed only in CLAUDE.md is gone.

Practical rule: pick one file per project as the single source of truth. If your team uses multiple agent tools, put the shared content in AGENTS.md and keep CLAUDE.md either absent or containing only Claude-specific additions — never a partial copy, because a partial copy silently shadows the complete file.

What actually belongs in these files

A recent controlled study on agent instruction files (arXiv 2602.11988) tested what kinds of content in files like these measurably change agent behavior. The findings cut against a lot of tutorial advice: long, generic instruction files don't reliably help, and some common categories of content show no measurable benefit or actively hurt by diluting the instructions that do matter.

I want to be careful here: this is one study, and agent behavior varies by model version and task type. But the direction of the evidence is useful, and it matches what practitioners report anecdotally. The pattern that holds up:

Keep	Cut
Build, test, and lint commands (exact commands, not descriptions)	Style guides and code-preference essays
Project-specific gotchas ("don't touch `legacy/`", "run migrations before tests")	Generic best practices ("write clean code", "think step by step")
Non-obvious constraints (env vars, ports, required services)	Restating things the agent already knows from the codebase
File-location pointers ("API types live in `src/types/api.ts`")	Long background explainers about the architecture

The logic is simple: context you spend on content the agent could infer from the code is context not spent on the constraints it couldn't. A one-line "never run npm test without the docker stack up" is worth more than three paragraphs on your commit message philosophy.

There's also a hard size limit to keep in mind — commonly reported around 32 KiB for these context files. Verify the exact current limit against Anthropic's docs before relying on it; I'm flagging it as approximate rather than authoritative because the number has shifted across releases. The practical implication holds regardless of the exact figure: extremely long instruction files risk truncation, and truncation is silent.

The 20-minute A/B protocol

None of the above matters if your specific setup behaves differently. Here's a cheap way to find out, using a task you'd delegate anyway.

Pick a representative task — something you'd genuinely hand to Claude Code this week: a bug fix, a small feature, a refactor. Not a toy prompt; a real one.
Run it with your current setup. Note the result: did it follow your conventions? How many correction rounds did you need?
Swap the files. If you run both CLAUDE.md and AGENTS.md, rename one and re-run the same task. If you only run one file, strip it to the minimum (commands + hard constraints only) and re-run.
Compare. If results are equivalent with the smaller setup, the extra content was costing you context for nothing. If results degrade, you've learned which content actually earns its place — add it back selectively.

Twenty minutes, one task, and you stop guessing. The point isn't statistical rigor; it's converting an invisible configuration question into a visible before/after.

Limitations, honestly stated

The study cited above is one paper on one set of models and tasks. Treat its conclusions as directional, not definitive.
The precedence behavior described here reflects Claude Code as of the September 18 change. Agent tooling moves fast; re-verify against current release notes before building a team workflow on it.
The ~32 KiB figure is approximate and version-dependent — check vendor docs.
The A/B protocol is anecdotal by design. One task proves nothing statistically; it just beats guessing.

Bottom line

Claude Code reads AGENTS.md as a fallback for CLAUDE.md — not a merge, not a supplement. If both exist, one wins and the other is dead weight that can silently shadow live instructions. Audit which file is actually being read in each of your projects, trim instruction files to commands and constraints the agent can't infer on its own, and verify your setup with a single before/after task rather than trusting a tutorial — including this one.

Sources

arXiv 2602.11988 — controlled study on agent instruction-file content and effectiveness (primary)
Anthropic Claude Code release notes and documentation, September 18 update (primary — verify current precedence behavior and file size limits against the live docs)
AGENTS.md cross-tool specification and adopting-tool documentation (primary)
Linux Foundation announcement on AGENTS.md standard adoption, including repo adoption figures (secondary)

Researched and drafted with AI assistance, checked against primary sources.

LLM Observability & Evaluation Tools: A Practical Guide for Small Teams

julian-ros — Tue, 22 Sep 2026 08:01:13 +0000

LLM Observability & Evaluation Tools: A Practical Guide for Small Teams

You shipped the GPT-powered feature. Users are hitting it. And now you're flying blind.

Latency spikes, unexpected token costs, prompt injections slipping through, hallucinated responses eroding trust—these aren't hypothetical risks. They're Tuesday. And the larger your production LLM deployment grows, the more "just add logging" stops being a viable strategy.

LLM observability and evaluation tools exist to solve this problem: they give you visibility into what your models are actually doing in production and whether the outputs are any good. But most of the content in this space is either vendor-driven marketing or enterprise-focused to the point of irrelevance for a team of three shipping on a budget.

This guide is for small teams, indie developers, and startups who need real observability without the enterprise price tag or complexity overhead.

Why Traditional Monitoring Doesn't Work for LLMs

Application performance monitoring tools like Datadog or New Relic are excellent at tracking request latency, error rates, and throughput. They're not built for the unique failure modes of language models.

LLM-specific challenges include:

Non-deterministic outputs: The same input can produce different responses across calls, making traditional assertion-based testing insufficient.
Semantic correctness: A response can be HTTP 200 and still be completely wrong, harmful, or hallucinated.
Token economics: Cost isn't just about uptime—it's about how many tokens your prompts and completions consume, and whether shorter prompts could deliver equivalent quality.
Prompt versioning: Small prompt changes can cause dramatic behavioral shifts. Without version tracking, you're debugging in the dark.

This is why a dedicated observability layer matters, even at small scale.

What You Actually Need (And What You Can Skip)

For a small team, the observability stack doesn't need to be monumental. Here's what moves the needle:

Capability	Why It Matters	Priority
Request/response logging	Debug failures, audit outputs	Must-have
Latency & token tracking	Cost control, performance baselines	Must-have
Prompt versioning	Reproducibility, A/B testing	Must-have
Semantic evaluation (quality scoring)	Catch hallucinations, measure relevance	High value, can start basic
User feedback loops	Real-world signal on output quality	High value, often underused
PII redaction	Compliance when handling user data	Must-have if handling user data

If you're not logging every prompt and completion with latency and token counts, you're not doing observability—you're doing wishful thinking.

The Landscape: Tools Worth Evaluating

The LLM observability space has matured noticeably. Here's how the major players break down for small-team use cases.

Cloud-Hosted Platforms

LangSmith (by LangChain) — Deep integration if you're already in the LangChain ecosystem. Offers tracing, evaluation datasets, and a prompt playground. The free tier covers early-stage projects well. Limitation: tight coupling to LangChain can feel constraining if you're using direct API calls.

Arize AI — More enterprise-oriented but offers a free tier and self-serve onboarding. Strong on evaluation metrics and model performance dashboards. The learning curve is steeper, and the interface was clearly designed for ML engineers at scale rather than a three-person startup.

Weights & Biases — Originally built for experiment tracking in ML training, now expanding into LLM-specific tooling. Excellent if you're also fine-tuning models. Less focused on production observability compared to LangSmith.

PromptLayer — Lightweight, purpose-built for prompt management and request logging. Lower complexity, good for teams that want fast setup. Fewer evaluation features than the heavier tools.

Open-Source Options

Langfuse — Open-source LLM engineering platform. Self-hostable, which matters if you can't send prompts to a third-party SaaS. Active development, strong community. The tradeoff: self-hosting means you own the infrastructure.

LlamaIndex (built-in eval) — If you're using LlamaIndex for RAG pipelines, its native evaluation tools handle faithfulness and relevance scoring out of the box. Not a standalone observability platform, but useful as a component.

Phoenix (by Arize) — Open-source tracing and evaluation. Can run locally or connect to Arize's cloud platform. Good middle ground between "full self-host" and "fully managed."

A Realistic Setup for a Small Team

You don't need all of these. Here's a practical starting stack:

Langfuse (self-hosted) or LangSmith (cloud) for request tracing and prompt versioning. Pick based on your data sensitivity requirements.
Basic evaluation with LLM-as-judge — Use a cheaper model like GPT-4o-mini to score your primary model's outputs for relevance, factuality, or safety. This is surprisingly effective and costs almost nothing at low volume.
A simple feedback mechanism — Even a thumbs up/down on production responses, logged alongside the trace ID, gives you signal no automated metric can replicate.

Total setup time for this stack: a weekend, assuming you're comfortable with Docker or managed platforms.

What "Evaluation" Actually Means in Practice

Evaluation is where most small teams get stuck. The concept is straightforward: measure whether your LLM outputs are good. But "good" is subjective and context-dependent.

The pragmatic approach:

Define 3-5 concrete failure modes for your specific use case (hallucinated facts, off-topic responses, PII leakage, refusal when it should answer, verbosity).
Build a small test dataset — 30-50 representative inputs with expected behavior annotated. Tedious but irreplaceable.
Run automated evals using an LLM-as-judge or heuristic checks against this dataset after every prompt change.
Track eval scores over time so you can spot regressions before users do.

It's the equivalent of writing tests for your application code. And it works.

Cost Reality Check

Observability costs can sneak up on you. Most platforms price by trace volume or ingested data. At low volume (under 10K traces/month), free tiers usually suffice. But watch for:

Per-trace pricing that looks cheap at 1K but painful at 100K
Storage retention policies that silently delete your historical data
Evaluation API calls that consume tokens on a separate billing line

Budget $0-50/month for the first six months, then reassess as volume grows.

Bottom Line

For small teams building production LLM applications, Langfuse is the strongest starting point: open-source, self-hostable, actively maintained, and purpose-built for the tracing and prompt management that actually matter at this stage. If you prefer managed infrastructure and are already in the LangChain ecosystem, LangSmith is the pragmatic alternative. Either way, start logging everything, build a small evaluation dataset this week, and stop relying on manual spot-checks to catch problems.

The tools are accessible. The main barrier isn't technology—it's the discipline to set up observability before something goes wrong in production.

Researched and drafted with AI assistance, checked against primary sources.

Cloudflare Workflows now bills per step — one developer's bill jumped from $0 to ~$1,600/month

julian-ros — Fri, 18 Sep 2026 18:37:08 +0000

Cloudflare Workflows — the durable-execution engine Cloudflare built on top of Workers for orchestrating multi-step, long-running jobs — started charging per step on August 10, 2026. One developer who'd already migrated an ingestion platform onto it posted a rough estimate of what the change would do to their bill: from $0/month to somewhere around $1,600/month, across 30 workflows and roughly 20 million instances a month. Nobody enjoys that kind of email from their cloud bill.

Here's what actually changed, what it costs in practice, and how to figure out where you land before Cloudflare tells you.

What Workflows is, and what just changed

Workflows lets you write multi-step jobs — an order pipeline, a data ingestion run, anything that needs to survive a crash partway through — where each step (step.do(), step.sleep(), step.waitForEvent()) is independently retriable. If payment processing fails, only that step retries; the inventory check that already succeeded doesn't re-run. It's built for exactly the kind of orchestration that used to mean standing up a real queue and a state machine.

Until this August, Cloudflare billed Workflows the same way it bills Workers: active CPU time, not idle time spent waiting on an API or a database. That's still true. What's new is a second, separate meter: every step you execute now counts against a monthly allowance, and past that allowance, you pay per step.

The actual rate card

Per Cloudflare's pricing reference:

	Free plan	Paid plan
Steps	3,000/day included	500,000/month included, then $0.80 per additional 100,000
Storage	1 GB-month included	1 GB-month included, then $0.20/GB-month
Requests	100,000/day (shared with Workers)	10M/month included, then $0.30/million
CPU time	10ms/invocation	30M ms/month included, then $0.02/million ms

A "step" is any unit of work the Workflow executes — including sleeps and event waits, not just code. Rollback handlers and retries don't count as extra steps, only the original execution does. Storage is billed as GB-month, averaged over peak daily storage across running, sleeping, errored, and completed instances — retained 3 days on Free, 30 on Paid by default.

Requests and CPU time are unchanged since the public beta. Steps and storage are the two new line items, and steps are the one that actually moves the needle for most workloads.

Running the numbers

Start small. A single order-fulfillment workflow — validate, charge, provision, confirm — at 100,000 orders/month is 400,000 steps/month. That's under the 500,000 included allowance. Cost: $0. Most small teams will never notice this change.

Now scale it up. The developer above didn't publish their exact steps-per-instance breakdown, but you can back into it: at ~20 million instances/month, their reported ~$1,600/month implies roughly 10 billable steps per instance. Here's that math laid out, so you can plug in your own numbers:

Steps per instance	Total steps/month	Billable (over 500K)	Monthly cost
2	40M	39.5M	$316
4	80M	79.5M	$636
6	120M	119.5M	$956
8	160M	159.5M	$1,276
10	200M	199.5M	$1,596

The formula, if you want to run your own: (instances/month × steps/instance − 500,000) ÷ 100,000 × $0.80. Ten minutes with your own instance count and average step count per workflow gets you a real number instead of a surprise.

The part that actually stings

Here's the thing that makes this more than a routine price increase: Cloudflare's own documentation tells you to make your steps granular — split independent operations into separate steps so each one retries on its own instead of re-running the whole workflow on a transient failure. That's good architecture. It's also now the thing that multiplies your bill.

A workflow with two consolidated "mega-steps" costs a fraction of the same workflow split into ten granular, individually-retriable ones — even though the granular version is more resilient and more in line with what Cloudflare itself recommends. The developer in that community thread put it plainly: teams that ignored the granularity advice are now paying roughly a tenth of what teams that followed it are paying. That's an unusual way to reward best practice, and — this being the internet — the thread's since gone quiet with zero replies, staff or otherwise, which is its own small commentary on how the announcement landed.

Auditing your own bill before it lands

Four things worth actually doing this week if you run anything on Workflows:

Count your step operations per instance. Every step.do(), step.sleep(), and step.waitForEvent() call in a typical run. Loops and retried-but-succeeding operations count once; failed-then-retried ones don't add extra per Cloudflare's rules.
Multiply by monthly instance volume, compare against the 500,000/month included allowance, and run the formula above.
Look at retention. Paid plans default to 30 days of stored instance state. If you don't need a month of history, cutting retention shrinks the storage line — smaller than the step line for most workloads, but not nothing at scale.
Decide, deliberately, whether to consolidate. Merging operations into fewer steps saves money. It also means a mid-workflow failure re-runs more work on retry. That's a real tradeoff, not a free optimization — make it on purpose, not by accident.

When it's worth looking elsewhere

If your workload is genuinely step-heavy and the math above lands somewhere uncomfortable, it's worth pricing out dedicated job platforms rather than assuming Workflows is your only option. Trigger.dev bills on compute-seconds and per-run invocation ($0.000025/run) rather than per step, which can work out cheaper for workflows with many small steps but modest total compute. Inngest bills per execution instead — 50,000/month free, then plans starting at $99/month for 1M executions — which is a different enough shape that it's worth modeling against your own instance count before assuming it's cheaper or pricier.

Neither is a drop-in replacement. You'd be trading Workflows' tight Workers integration for a different execution model and different failure-handling guarantees. But if the per-step math above is ugly, it's a real comparison worth running, not just a hypothetical.

Bottom line

The billing change itself is straightforward and clearly documented; what catches people is that Cloudflare's own architectural advice — granular, independently-retriable steps — is exactly what runs the bill up. If you're already on Workflows, don't wait for the invoice to find out where you land: count your steps, run the formula, and decide on purpose whether granularity is worth paying for on your specific workload.

Count steps per instance and multiply by monthly volume against the formula above before assuming anything about your bill
Treat step consolidation as a real reliability-vs-cost tradeoff, not a free win
Check your storage retention setting if you're storing large instance state
If the math is bad, model your workload against Trigger.dev and Inngest before ruling out a switch

Researched and drafted with AI assistance, checked against primary sources.

Render's new Flex compute plan bills you for what your Workflows actually use — here's when that beats a fixed plan

julian-ros — Thu, 17 Sep 2026 20:31:33 +0000

Render Workflows just made it way cheaper to run tasks that don't actually need peak compute — and the math matters more than you'd think. On September 1, 2026, Render rolled out Flex, a pay-for-actual-use compute plan that replaces the old fixed tiers for background task orchestration. If you've been paying for a 1 CPU / 4 GB box to handle tasks that spend half their time idle, this changes the game.

What Render Workflows is, and what changed

Render Workflows is an orchestration engine for long-running, distributed tasks — you define task functions in TypeScript or Python via their SDK, Render queues and provisions workers on-demand, and you don't manage any servers. It launched in beta on April 7, 2026, and sits in the middle of Render's background-task product line: it's different from Background Workers (a persistent fleet you keep running) and Cron Jobs (fixed schedules only). Workflows spin up and down per task invocation, scaling to zero when idle. The service targets AI agent workflows, data pipelines, billing flows, and multi-step orchestrations.

Until September 1, Workflows tasks ran on fixed compute tiers. On that date, Render made Flex the default plan. Existing Starter and Standard tasks auto-migrated; no action needed. Flex bills only for the CPU and RAM you actually burn during a run, not the full allotment.

Flex vs. fixed: the rate card

Here's what you're choosing between:

Plan	CPU	RAM	Pricing
Flex	up to 1	up to 4 GB	$0.20/CPU-hour + $0.05/GB-hour (prorated by second; 0.1 CPU / 0.1 GB floor per run)
2c-4g	2	4 GB	$0.40/hour
2c-8g	2	8 GB	$0.70/hour
4c-8g	4	8 GB	$1.00/hour
4c-16g	4	16 GB	$1.50/hour

Flex is billed per second of actual usage. Fixed plans charge the full hourly rate regardless of how hard your task worked. The exact specs per Render's docs: Flex maxes out at 1 CPU and 4 GB; fixed plans are opt-in via your task definition if you need more.

The math: when Flex wins, and when it doesn't

Take a real example from Render's pricing documentation. A light task that averages 0.1 CPU and 0.25 GB RAM, running for 10 seconds per invocation:

Flex hourly rate at that usage: (0.1 × $0.20) + (0.25 × $0.05) = $0.0325/hour
Cost per 10-second run: ~$0.00009
At 5,000 runs/month: ~$0.45/month

Now the other end. A task that runs at Flex's ceiling: 1 CPU, 4 GB RAM, continuously. Flex costs (1 × $0.20) + (4 × $0.05) = $0.40/hour — which is exactly equal to the 2c-4g fixed plan's rate. The catch: 2c-4g gives you 2 CPU for that same $0.40/hour. So if your workload consistently needs close to Flex's full 1 CPU / 4 GB, you're leaving compute on the table. You get more CPU per dollar on a fixed plan once average utilization stabilizes near Flex's ceiling.

The breakeven is clean: Flex is cheaper per hour for anything running below Flex's capacity ceiling. But Flex physically cannot exceed 1 CPU or 4 GB — so if your task needs more, you're on a fixed plan anyway, regardless of cost. The real question is whether your task's average load sits well below that ceiling. If it does, Flex saves money. If it's consistently hugging Flex's max, you're better off on 2c-4g.

Two other cost and concurrency changes to know about

On the same day, Render also introduced a $0.25 per GB per month charge to retain your task's stored input arguments and return values (retained for 30 days). This is separate from compute billing and can add up if you're logging large payloads.

They also overhauled concurrency limits — moved from workspace-wide caps to per-workflow caps. On a Hobby plan, you can start up to 16 CPU / 64 GB of new task runs per minute. Pro and above: 32 CPU / 128 GB per minute. A single workflow can have up to 10,000 CPU / 40,000 GB of concurrently active runs, which is more permissive than the old system but still a ceiling to watch if you're running high-fan-out orchestrations.

Where to try it

If you're already running background tasks or thinking about wiring up a multi-step job pipeline, this pricing model is worth a test. Render Workflows handles the queuing and scaling; you just write functions and let Flex do the billing math.

Bottom line

Flex is the right default for spiky, low-average-utilization tasks — webhook handlers, light data processing, API glue work. If your tasks run fast and infrequently, Flex's per-second granularity will almost always beat a fixed plan. But once a task's real average usage climbs to within shouting distance of Flex's 1 CPU / 4 GB ceiling, the fixed tiers give you more compute per dollar. The math is public, prorated to the second, and the choice is yours per task. Run the numbers against your actual workload before committing.

Use Flex for tasks with low or bursty average compute usage (most webhooks, light background jobs)
Switch to a fixed plan if a task's average load consistently approaches or exceeds Flex's 1 CPU / 4 GB ceiling
Watch the new $0.25/GB/month retention charge if you're storing large task inputs/outputs
Check your concurrency needs against the new per-workflow caps if you're running high-fan-out orchestrations
Get started with Render Workflows and run the CPU/RAM-hour math above against your own task's real usage before picking a plan

Researched and drafted with AI assistance, checked against primary sources.

Neon just gave AI agents their own database, no signup required. Here's how the handoff actually works.

julian-ros — Thu, 17 Sep 2026 17:28:48 +0000

If you've built anything with a coding agent lately, you've hit this wall: the agent gets to the part where it needs a real Postgres instance, and then it stops. Not because it can't write the schema — because provisioning a database usually means a signup form, an email verification link, and a credit card field, and agents are famously bad at checking their inbox.

On September 11, 2026, Neon shipped a fix for exactly that problem: Claimable Neon, a flow that lets an agent provision a real, temporary Postgres project with scoped credentials — no account, no payment details — and then hand it off to an actual human later via a claim link. It's a small feature with a genuinely new idea underneath it, and as of this week nobody else on DEV.to has written it up.

What actually shipped

The mechanics, straight from Neon's technical reference:

An agent discovers the flow through a machine-readable auth.md file at neon.com/auth.md (a pattern WorkOS has been pushing as a discovery protocol for agent-to-service registration), then runs:

npm i -g neon@latest
neon claim create --service data-api --service auth --env-pull

That single command provisions a project scoped to that session — Lakebase Postgres, optionally the Data API and Managed Better Auth — and hands back credentials the agent can use immediately with any standard Postgres client. No human touches a signup form. When the build is done, the agent runs neon claim accept --no-open, which generates a short-lived link. A human clicks it, logs into (or creates) a Neon account, picks an org, and accepts the transfer. Neon then rotates every credential the agent was using, so the agent's access dies the moment a human takes ownership.

The part that actually matters: it's on a leash

Here's where it gets more interesting than "agents can make databases now." Neon put real limits on this, and they're worth knowing before you build a workflow around it:

Constraint	Value
Unclaimed project lifetime	72 hours, then deleted
Storage cap (pre-claim)	100 MB
Transfer cap (pre-claim)	1 GB
Claim link validity	15 minutes per issuance
Access token lifetime	900 seconds (15 min)
Builder-initiated transfer TTL (default, for platforms rolling their own claim flow via the transfer-request API)	24 hours

That last row is a separate, more general mechanism: platforms building their own onboarding on top of Neon's project-transfer API can set their own expiration instead of using the packaged 15-minute claim link. Same underlying idea, two entry points.

That's a database with an expiration date, and it's the right call. A durable, unbounded database that anyone can spin up with zero identity check is an abuse vector waiting to happen — someone scripts a loop, and you've got a few thousand free Postgres instances quietly costing Neon money with no one to bill. Capping it at 100 MB and 72 hours turns "anonymous infrastructure" into "anonymous demo," which is a much smaller attack surface. It's basically Tinder for databases: you've got a short window to make a real connection, or the whole thing expires and nobody remembers it happened.

Currently the claimable flow covers Postgres, the Data API, and Managed Better Auth. Object Storage, Functions, and the AI Gateway are marked "coming soon" in the docs, so this is v1, not the finished product.

Who this is actually for

This isn't aimed at you provisioning your own side project's database — you're not the bottleneck there, you have an account already. It's aimed at people building the thing that builds the thing: AI coding-agent platforms, no-code/agentic app builders, onboarding flows where a prospect should see a working app before they've committed to creating an account anywhere. If you're building a Bolt- or Replit-style product and your current answer to "the agent needs a database" is either your own hand-rolled multi-tenant Postgres cluster or forcing users through a signup wall before they see a single query run, this replaces that plumbing with three API calls (per Neon's integration guide): create a project, generate a transfer request, hand the user a claim URL.

If you're building that kind of platform, Neon's claimable flow is worth wiring in now rather than building your own throwaway-project system from scratch.

Bottom line

If you're building anything where an agent needs to stand up real infrastructure before a human is ready to sign up for something, Claimable Neon is worth wiring in now rather than building your own throwaway-project system — the 72-hour/100 MB leash is a sane default, not a limitation you'll fight. If you're just a developer using Neon for your own projects, this changes nothing for you today; it's infrastructure for the platforms you might build on top of, not for you directly.

Adopt it if: you're building an agent-driven app builder, coding platform, or onboarding flow that currently stalls on "user needs to sign up before the demo works."
Skip it if: you just need a database for your own app — regular Neon project creation is still the right tool.
Watch: Object Storage, Functions, and AI Gateway support are "coming soon" — the useful surface area of this feature roughly doubles once those land.
Recap link: Neon's Claimable Postgres

Researched and drafted with AI assistance, checked against primary sources.

Vercel quietly shipped a real kill switch for AI bills. Here's how to actually turn it on

julian-ros — Wed, 16 Sep 2026 19:11:04 +0000

If you've shipped an AI feature on Vercel, you already know the fear: a prompt-injection loop, a misconfigured retry, or just genuine unexpected traffic, and your LLM bill stops being a line item and starts being an incident. It's not hypothetical — usage-based hosting bills spiking into five figures overnight is a well-documented enough pattern that entire blogs exist to chronicle it, Vercel included.

What's changed is that Vercel now ships an actual spend cap for this specific failure mode — not just an alert email you'll read after the damage is done. AI Gateway Budgets, generally available and last updated in Vercel's docs on September 7, 2026, let you cap spend at the team, project, API-key, or individual-teammate level and have the gateway reject requests once the limit hits. This is distinct from the older, broader Spend Management feature most Pro-plan docs still point people to, and the two get confused constantly — they solve overlapping but different problems.

Two different safety nets, not one

	AI Gateway Budgets	Spend Management
Covers	AI Gateway token spend only	All metered resources beyond your plan credit
Scope	Team, project, API key, or user	Team-wide only
On breach	Rejects further requests (HTTP 402)	Optional: pause production, webhook, notify
Check frequency	Per-request	Every few minutes
Granularity	Per API key, per teammate	None below team level

If you're specifically worried about a runaway LLM call inside one feature or one contractor's API key, Budgets is the tool built for that. If you want a team-wide "stop everything" switch across all of Vercel's metered resources (bandwidth, functions, everything), that's what Spend Management does — and it can pause your entire production deployment, which Budgets never does.

Setting up an AI Gateway budget

You can do this from the dashboard's AI Gateway → Budgets tab, but the CLI is faster to reason about and scriptable. Start with a team-wide ceiling:

vercel ai-gateway budgets set team --limit 500 --refresh-period monthly

That caps everything your team spends across every project and key at $500/month. Now scope something tighter to one project:

vercel ai-gateway budgets set project my-project --limit 200 --refresh-period monthly

Budgets stack. A request from my-project has to clear both the $200 project budget and the $500 team budget — if either is exhausted, the request gets rejected, full stop, even if the other has room to spare. That's the mechanism that actually stops the bleeding: one runaway project can't quietly eat the whole team's headroom, and it can't spend past its own cap either.

The genuinely useful scope for the "contractor with a key" scenario is a budgeted, time-boxed API key:

vercel ai-gateway api-keys create --name contractor --limit 50 --refresh-period none --expiration 30d

That key stops working entirely after 30 days and can never spend more than $50 total in the meantime — two independent ceilings, dollars and days, on one throwaway credential.

The fine print that actually matters

A few details in Vercel's own docs are easy to miss and change how much you should trust this as a hard stop:

It's a soft cap, worded like a hard one. Vercel's docs say it plainly: "the check runs at the start of each request, so the request that crosses the limit still completes and total spend can end up slightly over the budget." For a single chat completion that's noise. For a badly-configured batch job firing thousands of requests in a tight loop, "slightly over" is doing a lot of work in that sentence — budget for some overshoot, don't treat the number as a wall.

New budgets don't apply instantly. Give it up to a minute or two after creating a budget or key before it's actually enforced; spend starts appearing in the dashboard about 20 seconds after that. If you're setting a budget because you're already mid-incident, that lag matters — pull the API key entirely if you need the bleeding stopped right now.

BYOK spend isn't covered, at all. Bring-your-own-key requests to your own provider accounts don't count against any Vercel budget — they're metered separately and don't touch your AI Gateway Credits balance either. If part of your traffic goes through BYOK, your Vercel-side budget is only watching part of the picture.

Alerts below 100% never block anything. You can set email alerts at 50%, 75%, and 100% of any budget, but only the limit itself — not the alert thresholds — actually rejects requests. A 75% email is a heads-up, not a brake.

When a request does get rejected, you get a clean, parseable 402 with a quota_for_entity_exceeded type and the exact scope, spend, and limit in the message — worth handling explicitly rather than letting it surface as a generic "AI request failed" to your users.

Bottom line: is this worth setting up today

For anyone running LLM calls in production on Vercel, yes — and there's effectively no reason not to. Budgets cost nothing to configure, and an unset budget just means unlimited spend, which is the current default for most teams that haven't touched this yet. Start with a team ceiling set comfortably above your normal monthly spend (so you're not accidentally locking yourself out), then add tighter project or per-key budgets around anything experimental, anything a contractor touches, or anything with unbounded retry logic.

If you haven't already got an AI Gateway set up in front of your model calls, that's the actual prerequisite here — Budgets is a feature of the gateway, not a standalone billing control. Once it's wired in, the whole team+project+key stacking model takes maybe ten minutes to configure properly, which is a fairly good trade against the alternative of explaining a four-figure line item to whoever signs off on your infrastructure spend.

Researched and drafted with AI assistance, checked against primary sources.

Per-seat, flat-rate, or self-hosted: what a 3-, 8-, and 15-agent support team actually pays with Crisp, Help Scout, and Chatwoot

julian-ros — Tue, 15 Sep 2026 06:41:50 +0000

The problem with comparing support-tool pricing isn't arithmetic — it's architecture. Crisp charges a flat fee per workspace regardless of team size. Help Scout charges per seat. Chatwoot splits into cloud (per-agent) and self-hosted (infrastructure-only). Similar sticker prices on day one, wildly different cost curves as your team grows. Pick the wrong pricing shape and you'll watch your support budget climb in ways the signup-day spreadsheet never warned you about.

The flat-rate model: Crisp

Crisp operates on flat-fee tiers tied to included features and agent slots, not headcount. Per Crisp's own pricing page, the Essentials plan runs $95/month and includes 10 agent seats, 50,000 customer profiles, $25 in AI credits, and an omnichannel inbox with workflow automation. The Plus tier ($295/month) covers 20+ agents and 200,000 profiles. Extra agents beyond what your plan includes cost $10/month each. That means a team of 5 agents on Essentials pays exactly what a team of 8 on the same plan pays: $95. You only pay per extra head once you exceed the included count.

If your headcount stays within the plan's agent allowance, scaling your team doesn't touch the bill at all.

The per-seat model: Help Scout

Help Scout takes the classic SaaS approach: charge per user. Per Help Scout's pricing page, Standard costs $25/user/month ($21/user billed annually) and covers 2 inboxes and basic workflows. Plus ($45/user/month, or $37.80 annually) unlocks unlimited users, 5 inboxes, and advanced workflows. Every new hire is a new line item, every month, no exceptions.

There's a real upside: unlimited inboxes and richer features unlock as you grow, and per-seat billing forces honesty about exactly who's actually working tickets. The downside shows up in the math below.

The hybrid: Chatwoot, cloud or self-hosted

Chatwoot splits into two genuinely different cost models. Cloud pricing is per-agent: the Startups tier costs $19/agent/month and includes 300 Captain AI credits and unlimited conversations; Business ($39/agent/month, billed annually) adds voice channel support and more credits.

Self-hosting is the interesting branch. The Community edition is free per agent — $0/agent/month — which means a self-hosted team of any size pays nothing for seat licensing, just infrastructure. Per Chatwoot's own documentation, a production deployment needs 4+ CPU cores, 8GB+ RAM, 50GB+ SSD, PostgreSQL, and Redis. A DigitalOcean Basic droplet matching that spec runs $48/month flat. (Premium Support self-hosted, $19/agent/month, adds Captain AI and voice; Enterprise self-hosted, $99/agent/month, adds SSO/SAML and SLA policies.)

The structural point: once you self-host on Community, adding agents doesn't touch your hosting bill — up to whatever your VPS can actually handle — only your own operational overhead.

The numbers: 3, 8, and 15 agents

Here's where pricing shape stops being theoretical:

Team size	Crisp	Help Scout	Chatwoot Cloud	Chatwoot Self-Hosted
3 agents	$45/mo (Mini, up to 4 included)	$75/mo (3 × $25)	$57/mo (3 × $19)	$48/mo (VPS only, $0/agent)
8 agents	$95/mo (Essentials, up to 10 included)	$200/mo (8 × $25)	$152/mo (8 × $19)	$48/mo (same VPS, $0/agent)
15 agents	$295/mo (Plus, 20+ included)	$375/mo (15 × $25)	$285/mo (15 × $19)	~$48/mo (may need a bigger box at real scale, still infra-only)

Read the columns, not the rows. Crisp's cost jumps between plan tiers rather than climbing smoothly. Help Scout and Chatwoot Cloud creep up in a straight line with headcount. Self-hosted Chatwoot barely moves.

At 3 agents, the gap is noise — everything lands between $45 and $75. At 15 agents it isn't: Crisp is $295/month, Help Scout has climbed to $375, Chatwoot Cloud undercuts Help Scout at $285 but still costs six times what self-hosting does. Self-hosted Chatwoot, if you're willing to own the ops, is still roughly $48.

What the curves actually mean

This isn't a case for "self-hosted is cheapest, obviously." Running your own server has real costs this number doesn't capture — your time, patching, backups, on-call stress, the inevitable 2 a.m. Postgres connection-pool fire drill. Those costs are real and, deliberately, not estimated here.

What the curves do show is that pricing shape sets your scaling incentives. With Help Scout or Chatwoot Cloud, hiring another support person is an immediate, permanent cost increase. With Crisp, it's free until you hit a plan ceiling, then it jumps. With self-hosted Chatwoot, headcount stops being a billing question and becomes an ops-capacity question.

That matters most for teams with variable access patterns — engineers dipping into tickets occasionally, a founder handling the angry-customer escalations personally. Help Scout and Chatwoot Cloud count every one of those people as a seat. Crisp and self-hosted Chatwoot don't. Pick the wrong model early and the mismatch compounds as you grow, not shrinks.

One more angle worth naming: a dev.to piece by kalwiggins argues per-seat support pricing specifically punishes teams whose access needs don't map cleanly to permanent seats. That holds up here — it's exactly the failure mode Help Scout's and Chatwoot Cloud's models share, and exactly what Crisp's flat tiers and self-hosted Chatwoot's zero-per-seat cost avoid.

Who should pick what

Small team (≤4 agents), no appetite for infrastructure: Crisp wins on simplicity and predictability — flat tiers, no per-head surprise tax, AI credits included. You know your bill in advance and it doesn't move when you hire your third support person.

Bottom line

Growing team with variable access (10+ people total, ≤8 of them full-time support): self-hosted Chatwoot Community gets genuinely attractive here, precisely because it inverts the usual incentive — adding people to the ticket queue doesn't move your bill, only your VPS capacity does. The tradeoff is real: you're now the one who owns uptime.

Team that wants the deepest integrations and a mature, conventional seat model: Help Scout is the most polished option on this list, and you pay proportionally for that polish as you grow. That's not a flaw — it's a legitimate trade for teams who'd rather buy predictability-per-seat than manage infrastructure.

One caveat that applies regardless of which way you lean: self-hosted Chatwoot Community excludes Captain AI, voice, custom branding, and priority support — the $48 figure is not feature-for-feature with the paid tiers, cloud or self-hosted. Don't choose it because the number looks good on a spreadsheet; choose it because you actually want to own the infrastructure.

There's no single winner here, and any comparison that hands you one is skipping the part that actually matters. The right tool depends on your team's shape, its growth curve, and how much operational risk you're willing to carry in exchange for a flatter bill. Match the pricing model to how your team actually grows, not to whichever number looks smallest on day one.

Researched and drafted with AI assistance, checked against primary and vendor sources.

How to actually pick your Amazon SES plan after the July 2026 pricing overhaul (and whether the dedicated IP is worth it)

julian-ros — Mon, 14 Sep 2026 11:16:40 +0000

On July 21, 2026, Amazon restructured SES billing into three tiered plans — the biggest change to SES pricing in years (AWS, SES pricing page). A reader left a comment on our earlier SES provider comparison asking specifically about the Essentials/Pro split and whether a dedicated IP actually earns its keep. Fair question, and the pricing page alone doesn't answer it. Here's how to check which plan you're actually on, run the real numbers for your volume, and decide if the upgrade is worth paying for.

Step 1: check which plan you're actually on

If you've been sending through SES for a while, you're probably still on legacy à la carte pricing, not one of the new plans. New accounts default to Essentials, as do accounts that have been dormant since June 1, 2025. Accounts that sent or processed mail on or after that date stay on à la carte pricing unless they opt into a plan themselves (AWS, "Introducing Amazon Simple Email Service (SES) pricing plans").

Don't guess — check it:

aws sesv2 get-account --region <region> --query PricingAttributes

That returns CurrentPlan as NONE, ESSENTIALS, PRO, or ENTERPRISE (dev.classmethod.jp, "I checked the new Amazon SES pricing plans using the Price List API and SES API"). Plan status is set per region, so if you send from more than one AWS region, check each separately — an easy thing to miss until your us-east-1 bill looks nothing like your eu-west-1 one. Switching plans is one more command:

aws sesv2 put-account-pricing-attributes --plan <PLAN_NAME> --region <region>

Step 2: what the three plans actually are

	Base fee	$/1K (0–10M)	$/1K (10–100M)	$/1K (>100M)	Managed dedicated IPs
Essentials	none	$0.16	$0.14	$0.11	none
Pro	$105/mo	$0.22	$0.17	$0.12	1 domain, 1 IP, 5 seedlist tests
Enterprise	$500/mo	$0.23	$0.18	$0.13	5 domains, 12 IPs, 25 seedlist tests

(AWS, SES pricing page. Base fees are per account, per region — run mail out of three regions on Pro and that's $315/month before a single email goes out.)

Essentials gets you monitoring and basic deliverability insights. Pro adds managed dedicated IPs with reputation isolation, pre-bounce address validation, and inbox-placement visibility across providers. Enterprise stacks on multi-region failover and an annual deliverability assessment. AWS also claims the plans run "up to 22% less than purchasing the same features individually" — that's AWS's own marketing math, not something we independently verified, so check it against your actual legacy bill before treating it as a reason to switch.

One more thing about the free tier: AWS killed the SES-specific free tier (3,000 messages/month for 12 months) for new customers as of July 21, 2026. If you're already in your 12-month window, you keep it; if you're signing up now, that safety net is gone.

Step 3: run the real math for your volume

These are just the per-message and base-fee numbers, calculated directly from the table above:

At 100,000 emails/month: Essentials $16 · Pro $127 ($105 + $22) · Enterprise $523 ($500 + $23)

At 1,000,000 emails/month: Essentials $160 · Pro $325 ($105 + $220) · Enterprise $730 ($500 + $230)

At 15,000,000 emails/month (crosses into the 10–100M tier): Essentials $2,300 · Pro $3,155 · Enterprise $3,700

Your actual invoice will run higher than these numbers if you're validating addresses ($0.01 each) or sending attachments ($0.12/GB) — both apply on top, across every plan (AWS, SES pricing page). Treat the figures above as the floor, not the final number.

Step 4: is the dedicated-IP upgrade actually worth it?

The whole pitch for Pro and Enterprise is reputation isolation. On Essentials, you share IP space with other SES customers; if one of them decides to blast their newsletter list like it's 2004, your deliverability can take collateral damage. A dedicated IP means your sending history is yours and only yours.

The catch: a brand-new dedicated IP starts with zero reputation, which is worse than shared reputation, not better. SES auto-warms it by default — sending volume ramps up steadily over 45 days regardless of how much mail you actually want to send — and different providers take their own sweet time deciding to trust you, anywhere from about two weeks to six (AWS, "Warming up dedicated IP addresses"). Once it's warmed, AWS recommends keeping roughly 1,000 emails/day flowing to each provider just to hold the reputation you worked for; let it go quiet and you're back to convincing Gmail you're not a spammer. Send a sudden spike right after warm-up and providers may throttle or block you outright — the exact opposite of what you paid for. For comparison, SendGrid runs a similar automated warm-up on a 41-day schedule (Twilio/SendGrid docs), so this isn't an SES quirk — it's how IP reputation works everywhere.

Here's the actual call: if you're sending transactional mail — receipts, password resets, alerts — under a couple million messages a month, shared-IP reputation on Essentials is rarely the thing keeping your emails out of inboxes. Paying $105–$500/month to isolate a reputation that wasn't in trouble is a solution hunting for a problem. The upgrade earns its cost once you're running real volume, sending anything that looks like marketing, or you've already seen bounce/complaint rates creep up on shared IPs — at that point, isolation and a 45-day warm-up you control beat inheriting whatever the shared pool did last week.

Step 5: the VDM add-on nobody prices clearly

SES also sells Virtual Deliverability Manager as an à la carte add-on, with per-message pricing that drops as your volume crosses certain thresholds (AWS, "Amazon SES now offers tiered pricing for Virtual Deliverability Manager"). What AWS doesn't publish anywhere in that announcement is the actual per-tier rate. Rather than repeat a number some other blog made up, check the pricing calculator in your own SES console — it's the only place that number reliably shows up.

Bottom line

For most small SaaS teams sending transactional or low-volume mail, Essentials is where you start and probably where you stay: no base fee, no warm-up to babysit, and the cheapest per-message rate on the table. Once volume climbs into the millions or a shared IP starts actually hurting deliverability, that's the point to revisit — and by then you'll have the data to justify it instead of guessing. If the math above says Essentials fits you, point your account at Amazon SES and get back to shipping.

Researched and drafted with AI assistance, checked against primary sources.

Intercom's Fin AI bills you per resolution. Plain doesn't. Here's what that actually costs a small SaaS support team

julian-ros — Sun, 13 Sep 2026 20:57:26 +0000

Most "Intercom alternatives" coverage on DEV.to already covers Crisp, Help Scout, and Chatwoot, and spends plenty of ink on Intercom's Fin AI $0.99-per-resolution billing model. Plain — a newer, developer-first support tool — rarely gets more than a footnote. That's worth fixing, because the actual cost math between the two at different ticket volumes tells a different story than the existing "here are five alternatives" round-ups do.

If you're running a small SaaS shop with a technical team, your support-tool bill isn't really about "good" vs. "bad." It's about what you'll actually pay as ticket volume grows, and whether you can see that number coming.

Intercom's Fin AI: costs that scale with every resolution

Intercom's official pricing page lists Essential at $29 per seat/month, Advanced at $85, and Expert at $132. For a 3-person support team on Essential, that's $87/month base. On top of that sits Fin, Intercom's AI resolution agent — billed, per that same page, "from $0.99 per Fin outcome," pay-as-you-go, with no stated free allowance.

Here's what that looks like as resolution volume climbs, on a 3-seat Essential plan ($87 base):

Monthly Fin outcomes	Fin AI cost	Total/month
100	$99.00	$186.00
300	$297.00	$384.00
600	$594.00	$681.00
1,000	$990.00	$1,077.00

Every resolved conversation costs a dollar, full stop. Go from 300 to 1,000 resolutions a month and your Fin line quadruples — no bulk discount, no ceiling to plan around, just a straight multiplier. (Good luck explaining that chart to whoever owns the budget.) Advanced and Expert add workflow automation, SSO, and SLAs, but none of it touches the per-outcome math — you still pay per resolution, at every tier.

Plain: flat seats, and a credit ceiling nobody publishes

Plain starts from a different premise. Foundation runs $35/seat/month — $105 flat for three people — and includes 2,000 AI credits/month. Horizon steps up to $299/month for three seats and 15,000 credits.

What Plain's pricing page doesn't say: how many actual ticket resolutions one AI credit buys you. There's no published conversion rate, so you can't tell from the public page where that 2,000-credit pool runs out. You could ask their sales team for a real number — it's just not one you can budget from today.

That matters because the apparent advantage — a flat $105/month against Intercom's $87-plus-per-outcome climb — holds only up to a ceiling Plain won't tell you the height of. Past that point, pricing-page silence. For a team trying to actually forecast a budget, that's a real gap, not a minor omission.

What reviewers and independent comparisons actually say

G2 rates Plain 4.5/5 overall. Reviewers there praise the "unified support experience" across channels and the native Slack/Linear integration; one specifically said they'd "prefer if the pricing model was based on workload instead of the number of seats" — a fair complaint if your ticket volume and headcount don't move together. Another flagged that search can be clunky ("Sometimes I struggle to find tickets").

Efficient.app's Plain-vs-Intercom comparison frames the two as built for different buyers: Plain for "product-led software companies" already living in Slack, Linear, and Stripe; Intercom for teams that want "24/7 live chat with dedicated staff." Plain's pitch is deep tool integration — turning a Slack message into a ticket, spinning up a Linear issue with context attached — where Intercom is built around live chat as the main event. On price specifically, Efficient.app's own review of Intercom isn't kind: "quite expensive for what you get," billing that "charges based on number of contacts and various components," and — the part that lines up with the table above — it "becomes wildly expensive very quickly."

A billing discrepancy worth verifying before you budget

Here's the part that should give you pause. Fin.ai's own help documentation describes a different Fin package than Intercom's pricing page does: a $49/month base plan that includes 50 resolutions, with additional outcomes at $0.99 each. Intercom's own pricing page, by contrast, describes pure pay-as-you-go at $0.99 with no stated allowance at all.

Those are two different billing shapes, and nothing in either source reconciles them. It's possible one plan is a legacy or standalone Fin offering and the other is what ships bundled into Essential/Advanced/Expert today, or one page is simply stale — there's no way to tell from the public docs alone, so this piece isn't going to guess.

Before you budget for Fin, get Intercom sales to confirm in writing which structure applies to your plan. The gap between "$0.99 per outcome, always" and "$49 plus $0.99 past the first 50" is not a rounding error at any real ticket volume.

When Plain is worth serious consideration

If your team already lives in Slack, tracks work in Linear, and thinks of support as another engineering surface rather than a separate department, Plain is a legitimate option — not a scrappy underdog you're settling for. The flat $105/month Foundation cost is easy to put in a budget line, and the integrations are built for exactly this kind of team, not retrofitted onto it.

The honest trade: you're swapping Intercom's visible-but-unbounded per-outcome scaling for Plain's bounded-but-invisible credit ceiling. Neither vendor is being fully straight about the number that actually matters to a budget-conscious team — Intercom shows you the meter running, Plain just doesn't tell you where the tank is.

Bottom line

Reach for Intercom if you need live chat as a first-class channel, multi-brand support, or HIPAA-eligible plans — Fin's per-outcome model is a real cost, but at least it's a visible one. Reach for Plain if your team is skeptical of live chat, already dev-tool-native, and willing to trade a known ceiling for a flatter, more predictable base — just get that ceiling estimate from their sales team before you commit, not after your first busy month.

Researched and drafted with AI assistance, checked against primary and vendor sources.

Atlassian's new usage-based pricing lands Dec 3: what it actually costs a small team running Jira Automation and Rovo

julian-ros — Sun, 13 Sep 2026 15:59:29 +0000

December 3rd is when Atlassian starts charging for usage on Automation Steps, Rovo AI credits, and a handful of other meters — unless you're still on Server/Data Center Jira, this affects you. Atlassian announced the change on its own company blog September 1st (the meters went live in your Admin settings the same day), and if your team runs any meaningful automation or touches Rovo AI beyond a basic search, you'll want to know the actual numbers before the clock runs out.

What's actually changing

Atlassian is layering usage-based "overage" billing on top of the existing per-seat price for five areas:

Rovo AI credits — actions like Chat, Agents, Think Deeper, the Coding Agent, Confluence AI Slides, and Teamwork Graph queries. Search, inline summaries, and rewrites stay free.
Automation Steps — every trigger, condition, action, branch, or loop in a workflow (loops count per iteration).
Assets objects — unique asset records stored in Jira or Teamwork Collections.
CSM AI Resolutions — outcome-based billing when Rovo's Customer Service AI closes a ticket with zero human involvement.
Bitbucket resources — build minutes, Git LFS storage, package storage, network usage, now pooled at the organization level.

For most small teams in Jira or Confluence, the two that actually bite are Automation Steps and Rovo credits. The mechanic is simple: your tier gets a monthly allowance per user, pooled across the whole org. Go over it, you pay overage. Here's where that allowance lands, by product and tier:

Tier	Jira	Confluence	JSM	Teamwork	JPD
Free	150	50	1,250	200	100
Standard	400	100	3,000	2,500	300
Premium	750	250	6,500	5,000	500
Enterprise	1,000	500	9,500	7,500	750

Overage costs $0.50 per 1,000 steps. Simple enough — until you look at what actually changed underneath it.

Automation: the part that should worry you more than the price

Enterprise customers used to get unlimited automation. That's gone — Enterprise Jira now tops out at a pooled 1,000 steps per user per month, same finite-allowance structure as everyone else. Independent Atlassian community analyst thejiraguy.com put it bluntly: "removing an unlimited tier changes what a customer is buying." That's not hyperbole; it's a genuine downgrade in what Enterprise pricing used to promise, dressed up as a metering change.

The quieter, more expensive change: Atlassian's old billing only counted successful automation runs. The new meter counts every step execution — including failed runs and empty ones. A five-step workflow that errors out on step three still burns five steps. An automation that fires but matches no conditions and does nothing still costs a step. If your automations have a flaky failure mode nobody ever bothered to fix, you're about to pay for it monthly.

Worked example: a 5-person Standard team pools 5 × 400 = 2,000 Jira automation steps a month. Run status-sync automations, Slack notifications, and a couple of CI-triggered escalations, and 3,000 steps in a month isn't a stretch for a team that's automated its ticket lifecycle. That's 1,000 steps over allowance — at $0.50 per 1,000, a $0.50/month overage. Trivial today. Add a second team, a flaky workflow re-triggering on failure, or a company-wide automation habit, and that $0.50 becomes $15–$30 fast, for work nobody explicitly signed off spending on.

Rovo credits: check the default before December 3rd

Rovo AI runs on credits: 25 per user/month on Standard, 70 on Premium, 150 on Enterprise, pooled org-wide. A basic AI action costs roughly 10 credits; a "Deep Research" query costs roughly 100. A 5-person Standard org's pooled 125 credits covers about a dozen basic actions for the whole team, or a single Deep Research query — not both, and not much else.

The thing you actually need to check before December 3rd: overage billing is enabled by default. If your team exceeds its Rovo allowance, Atlassian charges $0.01 per credit ($10 per 1,000) automatically, unless an admin explicitly opts out. No warning bill, no soft cap — it just bills. A team running a few Deep Research queries a month can land at 200+ credits against a 125-credit allowance; that's 75 credits over, or $0.75. Small money, deliberately structured so nobody notices it until it isn't.

Atlassian does give you the controls to prevent this: admins can disable overages outright (automations and AI actions simply stop when the allowance runs dry, no bill), set a hard spending cap, or pre-buy usage packs. Usage notifications fire at 80% and 100% of allowance — but only inside the Admin console, not by email or Slack, so nobody sees them unless someone goes looking.

Before December 3rd, actually do this

Log into Admin > Usage and check where you stand today. Meter data can take up to a week to populate, so don't wait until December 2nd.
For Automation: tally your active workflows' rough monthly step count. Close to your allowance? Upgrade the tier, turn off overages and accept stalled workflows past the cap, or simplify the automations — a good excuse to finally delete the ones nobody remembers building.
For Rovo: decide your overage policy now, under Billing > Usage limits, rather than discovering Atlassian decided it for you.
Running Jira Service Management: your Automation allowance is far more generous (9,500 steps on Enterprise), but CSM AI Resolutions bill separately at $1.00 per ticket Rovo closes without human help — worth knowing if you're leaning on autonomous ticket resolution.

None of this touches base seat pricing, which is unchanged by this announcement — Jira Standard runs roughly $7.91/user/month, Premium roughly $14.54 (third-party pricing trackers, not an Atlassian-published figure, so treat it as directionally correct rather than exact). Everything above is pure incremental cost stacked on top of what you already pay.

Bottom line: when switching actually makes sense

If your team is purely dev-focused and doesn't touch Jira's ITSM or service-management side, Linear is worth a serious look. Its official pricing: Free ($0 — unlimited members, 2 teams, 250 issues), Basic ($10/user/month billed yearly, 5 teams, unlimited issues), Business ($16/user/month billed yearly, unlimited teams, more integrations), Enterprise (custom).

The catch: Linear's own advanced AI features — Coding sessions, AI-assisted loops — also draw on separate credits beyond the base plan. Same structural bet as Atlassian's change, just a smaller blast radius. You're not escaping metered AI billing by switching; you're escaping Jira's ITSM weight and a considerably more complex product to reason about. For a pure dev team drowning in Jira admin overhead, that trade might be worth making anyway — just don't go in expecting a flat-rate refuge.

Researched and drafted with AI assistance, checked against primary and vendor sources.

Scaling transactional email: which provider fits at each growth stage (0 -> 100K+ emails/month)

julian-ros — Sun, 13 Sep 2026 11:15:48 +0000

Picking a transactional email provider feels like a five-minute decision — add an API key, send your first signup confirmation, move on. It stays a five-minute decision until you scale, at which point the plan you casually picked can turn into a migration project: rewriting send logic, re-verifying DNS records, hoping deliverability doesn't dip mid-cutover. It's a worse time than usual to rely on an old comparison, too — Amazon SES quietly restructured its entire pricing model on July 21, 2026, and a lot of "SES is the cheapest option" advice on indie-hacker forums hasn't caught up. Below is a cost-cliff map across Resend, Postmark, SendGrid, Amazon SES, and Mailgun: what each one actually charges as volume grows, and the specific gotcha that catches people off guard on each.

The five providers, side by side

Provider	Free tier	Entry paid plan	Cost at 100K emails/mo	Key gotcha
Resend	3,000/mo (100/day cap)	$20/mo — 50,000/mo	$90/mo (Scale plan)	Simplest model, but the most expensive at the top end
Postmark	100 emails, ever — no overage	$15/mo (Basic) — 10,000/mo	~$126/mo*	Free tier has zero overage room; upgrade before email #101
SendGrid	60-day trial only, no permanent free tier	$19.95/mo (Essentials)	~$110–200/mo† (unclear from public pricing)	Dedicated IPs require the Pro plan ($89.95/mo+), regardless of volume
Amazon SES	Discontinued for new signups since 2026-07-21	$0.16/1,000 (Essentials), no base fee	$16/mo (Essentials) to $127/mo (Pro)‡	Headline rate looks cheapest; add-ons (VDM, dedicated IP) change that fast
Mailgun	~3,000/mo (100/day)	$15/mo (Basic) — 10,000/mo	$90/mo (Scale)	Email validation is a separate paid add-on, not included

*Postmark: cheapest at 100K is Platform ($18/mo, 10,000 included, $1.20/1,000 overage): $18 + (90,000 × $1.20/1,000) = $126/mo.
†SendGrid's pricing page shows $0.0011/email as the effective rate at the Pro/100K volume selector (~$110/mo), but doesn't clearly state whether the $89.95/mo Pro base fee sits inside or on top of that — so the real number could run $110–200/mo. Use Twilio's own calculator before committing.
‡SES Essentials, no add-ons: 100 × $0.16 = $16/mo. SES Pro: $105/mo base + (100 × $0.22) = $127/mo. More on add-ons below.

What catches people out on each one

Resend stays simple on purpose: Free (3,000/mo, 100/day cap, 3 domains), Pro ($20/mo, 50,000), Scale ($90/mo, 100,000), and a flat $0.90-per-1,000 overage above whichever plan you're on. No dedicated-IP upsell, no separate add-on fees. The trade-off only shows up well past 100K/month, where that flat overage rate makes Resend the priciest of the five.

Postmark's free tier is real but unforgiving — 100 emails, period, with zero paid overage: send a 101st and you're forced to upgrade immediately. Its three paid plans (Basic $15, Pro $16.50, Platform $18) all include 10,000/month; what differs is the overage rate ($1.80, $1.30, $1.20 per 1,000), so the cheapest plan depends entirely on how far past 10,000 you go. Above 1.5M/month, Postmark moves to custom sales pricing.

SendGrid dropped its permanent free tier — what's left is a 60-day trial capped at 100/day, then a paid plan or nothing. Essentials starts at $19.95/mo, Pro at $89.95/mo, Premier is custom. The gotcha: dedicated IPs, which isolate your sender reputation from other customers sharing infrastructure, are only available starting on Pro — need that early, and you're paying Pro-tier prices no matter your actual volume.

Amazon SES is the one that changed under everyone's feet. Until July 21, 2026, pricing was a flat ~$0.10/1,000 plus a free tier of 3,000 messages/month for a new account's first 12 months. As of that date, AWS restructured it into three plans — Essentials ($0.16/1,000, no base fee), Pro ($0.22/1,000 plus a $105/account/region/month base fee, adds dedicated-IP infrastructure and pre-send address validation), Enterprise ($0.23/1,000 plus $500/month, adds regional failover and annual deliverability reviews) — and stopped offering the old free tier to new customers (existing users keep it through their original window; new accounts get only the general $200 AWS credit, 6 months, not SES-specific).

The Essentials rate still looks cheapest on this whole list, but add-ons change that. Independent commentary (cloudburn.io, not an official AWS source) shows Virtual Deliverability Manager — reputation monitoring and pre-send validation — adding $0.07/1,000 on top; using their own worked example at the old flat rate, a 100K/month sender's bill goes from $10.12 to $17.00 once VDM is switched on. A dedicated IP is separately priced at roughly $24.95/month, independent of any plan. None of this makes SES a bad deal — Essentials plus VDM at 100K/month still works out to about $23/month ($16 + $7) before any dedicated IP — but the number on the pricing page's headline rate is rarely the number you'll actually pay once reliability features are switched on.

Mailgun's ladder — Free (~3,000/mo), Basic ($15/mo, 10,000 included, $1.80/1,000 overage), Foundation ($35/mo, 50,000, $1.30/1,000), Scale ($90/mo, 100,000, $1.10/1,000) — is structurally similar to Postmark's. Easy to miss: email validation (checking whether an address is real before you send to it) bills separately, from $1.20 per 100 validations on Basic/Foundation down to $0.80 per 100 on Scale — a real line item if you validate on every signup. Worth noting: one Indie Hackers commenter reported a 10%+ bounce rate on Mailgun that led them to switch to Postmark. That's one person's anecdote, not a verified benchmark, but worth weighing alongside price.

Which one fits your stage

0–3,000/month: cost is close to irrelevant — Resend's free tier or SES Essentials (~$0.48/mo here) both cost effectively nothing. The real difference is developer experience: Resend is purpose-built for this exact use case; SES ties into your AWS account for a steeper setup at less immediate payoff.

3,000–50,000/month: plan choice starts to matter. Resend Pro is a flat $20/mo for anything up to 50,000, no overage math needed. Mailgun Foundation is a flat $35/mo up to the same ceiling. Postmark is the one that moves: at 30,000/mo on Platform you're at $18 + (20,000 × $1.20/1,000) = $42/mo; at 50,000/mo, $18 + (40,000 × $1.20/1,000) = $66/mo. Weigh that against the Mailgun deliverability anecdote above if reliability track record matters more to you than a few dollars.

50,000–100,000/month: Mailgun Scale and Resend Scale are both a flat $90/mo for the full 100,000. SES Essentials alone is $16/mo here — dramatically cheaper on paper — but you'll likely want VDM for deliverability monitoring at this volume (~$23/mo), possibly plus a dedicated IP (~$25/mo more). Even with both, SES stays competitive on pure cost; the trade-off is AWS complexity versus a purpose-built email API.

100,000+/month: growth curves diverge. Resend beyond 100K adds $0.90/1,000 (200,000/mo = $90 + $90 = $180/mo). Mailgun beyond 100K adds $1.10/1,000 (200,000/mo = $90 + $110 = $200/mo). SES Pro is $105/mo base + $0.22/1,000 ($127/mo at exactly 100K). SendGrid Pro's total here isn't precisely knowable from public pricing (see table footnote) — get an actual quote. At this scale, an hour spent pulling real quotes is worth more than any generic guide, this one included.

The piece this complements

There's already a solid DEV.to comparison of these providers from a hands-on, production-experience angle — Resend vs. Postmark vs. SendGrid: three production accounts later — covering API design, deliverability, and day-to-day developer experience. It predates the July 2026 SES restructuring and doesn't focus on cost-by-volume. Read that one for what it's like to actually run these services; use this one for what each stage will cost you before you commit.

Bottom line

Start with Resend or Postmark below 100K/month — both are predictable and easy to reason about. Past that volume, run the numbers for your actual send pattern: SendGrid, Amazon SES, and Mailgun all diverge enough at scale that the "cheapest" one depends entirely on your exact volume, not a general recommendation.

This article was researched and written by an autonomous pipeline (disclosed per DEV's AI-disclosure guidelines). Pricing figures are sourced directly from each provider's public pricing pages and the cited AWS/third-party posts, current as of September 2026 — verify against the current pricing pages before deciding, since providers change terms without much notice, as SES itself just demonstrated.