DEV Community: Nico Acosta

How to Screenshot a List of URLs (Bulk Capture for Research and Audits)

Nico Acosta — Tue, 07 Jul 2026 11:40:47 +0000

You have a spreadsheet, a sitemap, or a list of competitor pages, and you need a screenshot of each one. Doing it by hand means opening twenty tabs and pressing the capture key twenty times. This guide covers every method that actually works, from a free browser extension for a one-off batch to a scripted loop you can run on a schedule.

The short answer

To screenshot a list of URLs, loop over the list and capture each URL once. There is no magic "capture them all in one shot" primitive. Every tool, extension, or API does the same thing under the hood: it visits each page in turn and renders it. The real choice is how you drive that loop:

One-off, a handful of URLs: a browser extension that reads a pasted list.
Repeatable, or part of a pipeline: a short script that calls a screenshot API once per URL.
You already write capture code: keep your headless browser, just point the loop at a managed renderer if local Chromium is flaky in CI.

Method 1: a browser extension (for a quick one-off)

If you just need to grab a dozen pages once and never again, a Chrome extension like Multiple Screenshots is the fastest path. You paste your list, it opens each page, captures it, and saves the files locally. No code.

The limits show up the moment the job repeats. Extensions run in your browser, on your machine, with your session. You cannot put that in CI, schedule it overnight, or hand it to a teammate as a reproducible step. For a true one-time audit, fine. For anything you will do again, it is a dead end.

Method 2: an open-source script (DIY headless)

The classic developer answer is a script that drives a headless browser over the list. Tools like webscreenshot or a few lines of Puppeteer read a file of URLs and capture each one:

import puppeteer from 'puppeteer';
import { readFileSync } from 'node:fs';

const urls = readFileSync('urls.txt', 'utf8').trim().split('\n');
const browser = await puppeteer.launch();
const page = await browser.newPage();

for (const url of urls) {
  await page.goto(url, { waitUntil: 'networkidle2' });
  await page.screenshot({ path: `out/${encodeURIComponent(url)}.png`, fullPage: true });
}

await browser.close();

This works, and it is free. What it does not solve is everything around the capture: keeping Chromium installed and patched, handling pages that block headless browsers, dealing with cookie banners, and surviving in a CI runner or serverless function where a real browser binary is awkward to ship. Those problems scale with the size of your list. See screenshot a website from a URL for a fuller comparison of the DIY path versus an API.

Method 3: a screenshot API in a loop (repeatable)

When the job has to run more than once, a screenshot API turns each capture into a single HTTP request, so the loop is the whole program. You send a URL, you get back a hosted image. No browser to install, nothing to keep patched.

Here is the full pattern in Node. Read the list, capture each URL, and collect the hosted image URLs:

const urls = ['https://example.com', 'https://stripe.com', 'https://vercel.com'];
const results = [];

for (const url of urls) {
  const res = await fetch('https://api.grabbit.live/v1/grabs', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer sk_live_...',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ url, width: 1280, full_page: true, format: 'webp' }),
  });
  const data = await res.json();
  results.push({ url, image_url: data.image_url });
}

console.table(results);

Each response includes a hosted image_url, so you can drop the results straight into a CSV, a database, or a dashboard. Because every request is independent, you can keep the loop sequential for simplicity, or add limited concurrency if you want the batch to finish faster. This is exactly the kind of repeatable, scriptable job Grabbit's automated screenshots are built for, and you can wire it up with a free test key before adding a card.

A note on honesty: Grabbit does not expose a single "send me an array of URLs" endpoint. One request captures one URL. The loop above is the bulk pattern, and it keeps each capture independent so one bad URL never sinks the whole batch.

Choosing per-URL options

Each call in the loop is configured on its own, so a mixed list is no problem. The parameters that matter for a bulk job:

full_page: true captures the entire scrollable page, not just the viewport. Essential for audits where you want the whole page on record.
width sets the viewport (320 to 1920). Use a consistent width across the list so the screenshots line up for comparison.
format can be png, jpeg, or webp. WebP keeps a large batch small on disk.
delay_ms waits up to 10 seconds before the capture, which helps on pages that fade content in after load.

For a large list where you do not want to hold the connection open per request, the same endpoint accepts Prefer: respond-async (or ?async=true) and returns immediately with a job you poll later. That keeps a thousand-URL run from blocking your script.

Bulk screenshots for audits and monitoring

The reason most people want to screenshot a list of URLs is not the screenshots themselves, it is the comparison. Capture your competitors' landing pages today, capture them again next month, and the diff tells a story. Save each image_url next to its source URL and a timestamp, and you have the raw material for website change monitoring without building a crawler from scratch.

The same loop powers a few common jobs:

SEO audits: snapshot every page in a sitemap to spot rendering or layout regressions.
Competitor tracking: re-run the same list on a schedule and compare.
QA evidence: capture key pages on every deploy and attach them to the release.

Wrapping up

Screenshotting a list of URLs always comes down to a loop. A browser extension covers a one-time batch; a DIY script works until local Chromium becomes the maintenance burden; a screenshot API turns the whole job into a few lines that run anywhere, including CI and serverless. Point the loop at your list, collect the hosted image URLs, and you have a repeatable bulk-capture pipeline. To automate it end to end, see Grabbit's automated screenshots.

Originally published on the Grabbit blog.

Claude Code Pricing 2026: Pro vs Max vs Team (Updated June)

Nico Acosta — Tue, 07 Jul 2026 11:12:38 +0000

AI coding assistants like Claude Code, ChatGPT, Cursor, and Windsurf are changing how founders ship software. These tools accelerate development for experienced engineers and enable non-technical SaaS founders to build working prototypes without hiring a dev team.

But how much does it all cost? How much will a team spend on tools like Claude Code, and how can they prevent bill shock at the end of the month from overages? Read on to understand how to use Claude Code efficiently and avoid burning tokens.

How Much Does Claude Code Cost? Quick Overview

Visiting Claude.ai lets you chat with Claude's latest models.

But free Claude access does NOT include Claude Code. Access to Claude Code requires a monthly subscription.

Plan	Cost	Claude Code Access	Best For
Pro	$20/mo	✓ Full access	Daily coding, solo founders
Max 5x	$100/mo	✓ Extended limits	Heavy users, complex projects
Max 20x	$200/mo	✓ Maximum capacity	Power users, all-day coding
Team (standard seat)	$25/user/mo ($20 annually)	✗ Not included	Collaboration, research, admin
Team (premium seat)	$125/user/mo ($100 annually)	✓ Plus Cowork	Organizations, dev teams
API-only	Pay-per-token	Via terminal	Custom integrations

The Team plan trap: standard Team seats do NOT include Claude Code. If your team signed up to build, the developers need premium seats. Full decision guide in our Claude Pro vs Team vs Max breakdown.

Note that Anthropic offers yearly discounts on annual subscriptions - Claude Code Pro is $17/mo (15% savings) when purchased annually.

Each Claude Code subscription includes session limits—a maximum number of prompts you can send within a rolling 5-hour window. Claude Code Pro subscribers can expect a maximum 45 messages per 5-hour window. However, coding prompts consume more tokens than simple chat queries, so you'll realistically get 10-40 prompts per window.

Here's the worst feeling: You're in flow state, shipping a critical feature, and Claude Code says "You've reached your usage limit. Try again in 3 hours." Your momentum is gone. Your code progress halts for hours.

Why this matters: If you're racing to a demo, investor meeting, or launch deadline, losing 2-3 hours could mean missing your target.

You can turn on extra usage in your settings to keep Claude Code going. Set a monthly maximum you're comfortable with. Anthropic's documentation reports the average cost is $6/day, with 90% of developers under $12/day.

Any extra usage is paid at the API token pricing:

API Token Pricing

Model	Input (per 1M tokens)	Output (per 1M tokens)
Haiku 4.5	$1	$5
Sonnet 4.6	$3	$15
Opus 4.8	$5	$25
Fable 5	$10	$50

Claude Pro vs Max: Which Plan Should You Choose?

The Max plans cost more but include significantly more token capacity. Claude Max 5x costs $100/month and includes 5x the tokens of Pro. Claude Max 20x gives you 20x the tokens for $200/month.

For regular daily coding, troubleshooting, and planning, Claude Pro is sufficient. You may find a few days of heavy coding leads to extra usage charges.

When to upgrade to Max 5x: If you're hitting Pro's limits daily and spending $4+ on extra usage, Max 5x becomes cost-effective. Here's the math:

$4/day × 22 working days = $88 in overages
Add your $20 Pro subscription = $108/month total
Max 5x costs $100/month flat with 5x the capacity

If your overages consistently exceed $80/month, Max 5x saves money and removes the usage anxiety.

Claude Code Teams and Enterprise: When Do You Need Them?

Claude Code on the Team plan requires a premium seat at $125/month per developer ($100/month billed annually). The plan has a 5-seat minimum across seat types, with standard seats at $25/month ($20 annually) for teammates who collaborate but do not code. Five premium seats run $625/month; a mixed team of two developers on premium seats plus three standard seats is about $325/month.

Premium seats carry roughly 6.25x Pro's usage per session (5x a standard seat), slightly above Max 5x. But the real benefit is governance: your data is excluded from model training, Model Context Protocol (MCP) servers are configured at the team level, so when a developer leaves, you automatically revoke their access to internal databases and tooling, and Team provides centralized billing and usage auditing.

The decision framework:

Two founders building a product? Use two individual accounts; the 5-seat minimum makes Team expensive for you.
Growing past 5 developers? Security, permissioning, and data controls become critical. Team makes sense, with premium seats for the builders only.
Need SOC2 compliance or audit trails? Team is the path forward, and Enterprise ($20/seat plus API-rate usage) adds HIPAA options and SCIM.

For the full plan-choice walkthrough, including when individual Max plans beat Team seats, see Claude Pro vs Team vs Max.

How to Reduce Claude Code Costs: Practical Efficiency Strategies

Now that you know the pricing tiers, let's talk about the real cost lever: how efficiently you use tokens.

Every question, code review, and bug fix burns tokens. But you can cut how many tokens each query consumes. These strategies can reduce your bill by 50-80%.

Use `/clear` between tasks

The /clear command tells Claude Code to forget the current conversation context. Say you're squashing bugs: after fixing a frontend CSS issue, you jump to a backend database query. There's no need for Claude to keep the CSS conversation in memory. Clear it out for better results and fewer tokens.

When to /clear: Switching between unrelated files, moving from frontend to backend, or jumping from feature work to bug fixes. If Claude's suggestions start referencing the wrong context, you waited too long.

Use `/compact` to summarize the conversation

When building a feature over several iterations, every code snippet gets shared every time. The context window grows larger, meaning more tokens per question.

The /compact command tells Claude Code to summarize the current chat and start fresh with the "Cliff's Notes" version. The conversation continues with all pertinent details but uses a fraction of the tokens.

Rule of thumb: Use /compact after 10-15 messages or when /cost shows over 5M tokens in your session. You'll know you waited too long when Claude starts repeating itself or missing context from earlier.

Check your usage with `/cost`

The /cost slash command shows token usage for your current session. Use this to understand your usage patterns and identify which tasks burn the most tokens.

Configure `.claudeignore`

Just like .gitignore tells Git which files to skip, .claudeignore tells Claude what files to ignore when analyzing your codebase. Are you accidentally sending your entire node_modules folder to Claude with every prompt? That's 50-90% wasted tokens.

Action: Create .claudeignore in your project root with these lines:

.gitignore
node_modules/
.next/
build/
dist/
*.log
.env*
.git/

Run /cost before and after to verify the reduction.

Model Selection Strategy

Different Claude models have different costs. Match the model to the task:

Task Type	Model	Why
Autocomplete, simple edits	Haiku 4.5	Fastest, cheapest
Feature implementation	Sonnet 4.6	Best balance
Complex debugging	Sonnet 4.6	Usually sufficient
Architecture decisions	Opus 4.8	Worth the premium
Critical production code	Opus 4.8	When it matters most

The rule: Sonnet handles 80% of your work. Reserve Opus for complex reasoning tasks where Sonnet gets stuck. This alone can reduce token costs by 30-40%.

When to break the rule: If Haiku gives buggy code twice, jump straight to Sonnet. Don't burn three cheap iterations when one good Sonnet response costs less.

The Biggest Token Saver: Spec-Driven Development

All the tactics above (clearing, compacting, model switching) save 10-40% on tokens. But they miss the real problem: rebuilding the same feature over and over because the requirements weren't clear. Spec-driven development solves this.

The expensive way:

Prompt: "Build user authentication"
Claude builds it (5,000 tokens)
You: "Actually, I need email verification"
Claude rebuilds (6,000 tokens)
You: "And password reset"
Claude rebuilds again (7,000 tokens)

Result: 18,000 tokens, 3 rebuilds, one frustrated afternoon.

Spec-first workflow:

Write a clear requirement before coding
Break it into specific tasks
Implement each task with Claude understanding the full context

With the right prompt built from a clear specification, you can build the feature correctly the first time. That's 60-80% token savings.

BrainGrid formalizes this workflow, turning vague ideas into structured specs that Claude can implement in one pass. Give BrainGrid a prompt of what you'd like to build, and BrainGrid asks implementation questions and feature questions, just like a product manager fleshing out the details of what should be built. A requirements document is created, which you can use to generate a list of tasks.

Connecting BrainGrid to Claude Code allows Claude Code to read the requirements and tasks, then implement them directly from the command line. For the full setup, see our Claude Code MCP servers guide.

Spec-driven development ensures the prompts provided to Claude Code are complete and will build the expected feature the first time. Eliminate the iteration rabbit hole to save a huge percentage of token usage.

Is Claude Code Worth It? The Solo Founder's Decision Framework

If you value your time at $50/hour, Claude Code needs to save you 24 minutes per month to break even. That's one debugging session.

For a solo founder shipping products, a $20 Claude Code Pro account is worth it if it saves one hour of debugging. Any additional time savings from feature coding, prototyping, or writing tests is bonus ROI.

If Claude Code helps you shave 10-30% from each dev cycle (or increase output per cycle by 10-30%), that's $20 very well spent.

Maximize your $20/month: Pair Claude Code with BrainGrid to turn ideas into shippable specs in minutes, or integrate with other agentic tools like Cursor to further accelerate how quickly you and your team ship.

Frequently Asked Questions

How much does Claude Code cost?

Claude Code Pro is $20/month ($17/month when paid yearly). Claude Code Max ranges from $100-200/month for power users. On the Team plan, Claude Code requires a premium seat at $125/month per developer ($100/month billed annually).

Is Claude Code free?

No. A free Claude account allows chat on the web, but no access to Claude Code. You need a paid subscription.

What's the difference between Claude Pro and Max?

Claude Pro is $20/month. Claude Max starts at $100/month and includes 5x the token capacity. Upgrade trigger: If you're spending $80+/month on overages, Max 5x is more cost-effective.

Why is Claude Code using so many tokens?

When iterating on a problem, Claude Code processes the full conversation context with each response. Long conversations with lots of code snippets burn tokens fast. Use /clear between tasks and /compact during long sessions to reduce usage.

How do I reduce Claude Code costs?

The biggest lever is reducing iterations. Great prompts from tools like BrainGrid's spec-driven development ensure you build features correctly the first time. Fewer iterations = fewer tokens = lower costs.

Is Claude Code worth it?

If it saves you one hour of debugging per month, you've broken even (assuming your time is worth $20+/hour). Most founders report saving 5-10 hours monthly. Try Pro for 30 days and track time saved vs. rate limit waits.

Claude Code vs Cursor: which is cheaper?

Both have a $20/month basic plan. Cursor includes an IDE and routes queries to different LLMs automatically. Claude Code gives you direct access to Claude's full model lineup. For most founders, pick based on workflow preference, not price. See our detailed Cursor pricing breakdown for more.

What are Claude Code rate limits?

Claude Code has a 5-hour rolling window for token usage. Hit the limit and you'll see "Try again in X hours." Avoid surprises: Enable extra usage with a monthly cap (Settings > Billing). If you're regularly hitting limits, consider Max 5x.

Originally published on the BrainGrid blog.

Engineering project management without the overhead

Nico Acosta — Mon, 06 Jul 2026 13:15:04 +0000

Engineering project management is the practice of planning, tracking, and delivering software work: turning a pile of "we should do this" into scoped issues, moving them through a workflow, and knowing at any moment what is in flight, what is blocked, and what shipped. That is the whole job. Everything else a tool piles on top of it, the roadmaps, the portfolio views, the burndown charts, the AI copilots, is optional, and most of it is overhead.

This post is about the lean version. Not project management theory, and not the enterprise suite. The specific question a software team actually has: what is the smallest tool that lets us plan and ship the work without the process becoming the work?

What engineering project management actually requires

Strip it down and a software team needs four things from a tracker:

A place to write down the work. Issues with a title, an owner, a priority, and enough description to act on. That is the atom.
A workflow to move it through. Backlog to in progress to done, with a triage step for the stuff that arrives unsorted.
A way to batch it. A sprint or cycle so "this two weeks" is a real, bounded thing and not an open-ended list.
A shared view of state. So anyone, a teammate or an agent, can answer "what is the status of X" without a standup.

That is engineering project management for a software team. Notice what is not on the list: Gantt charts, resource-leveling, earned-value tracking, a roadmap timeline, velocity dashboards. Those belong to a different discipline, the capital-P Project Management that runs bridges and multi-year hardware programs. Bolting that machinery onto a software team is how a tracker turns into the thing everyone quietly avoids.

Radial ships exactly the four things above and stops there on purpose. Issues, a triage queue, board and list layouts, Cycles (time-boxed sprints), estimates, and projects to group related work. It does not ship burndown charts, velocity graphs, a roadmap timeline, or portfolio management, and that is a deliberate line, not a gap we are rushing to close.

The overhead is the process, not the tool

The reason engineering project management gets a bad name is not the tracking. It is the ceremony that accretes around it. A workflow with eleven states. Required custom fields on every ticket. A weekly ritual of updating a status you already communicated in the pull request. The tool grew a feature, someone turned it on, and now it is a tax on every issue forever.

The fix is not a better dashboard. It is less surface area. The best engineering project management setup is the one your team forgets it is using, because filing an issue costs a keystroke and the status is obvious from the work itself. Speed matters here for a concrete reason: if the tracker is slow, people route around it, and a tracker people route around stops being the source of truth. Then you are back to reconstructing state from Slack and memory.

So the lean version has two properties. It is fast enough that using it is never the friction. And it does one thing, issue tracking, well enough that you do not need a second tool to compensate.

Run the work from where you already are

For an engineering team, the highest-leverage property of a tracker is that it can be driven from the terminal, not just clicked through a web app. When the tracker has a real CLI, project management stops being a separate context you switch into and becomes something you script into the work you are already doing.

Every Radial command takes --json, so the same operations your team does by hand also run from a script, a CI job, or an agent:

# File an issue on the engineering team, high priority, from the terminal or CI
radial create "Investigate 500s on checkout" -t ENG -p high --json

# See exactly what is on your plate right now, as data you can pipe
radial list --assignee me --status "in progress" --json

Because --json is on everything, the tracker becomes programmable. A failing CI build can file its own issue. A pre-commit hook can check what is assigned to you. And your coding agent can do the same operations over MCP, because to the API there is no difference between you typing radial create and Claude Code calling the same endpoint. Every credential is a client of the API, not a billed seat, so your agents ride free. That is the shape of engineering project management that fits how software teams actually work in 2026: the human and the agent writing to one shared record, from the terminal, without a per-agent bill.

The bill is part of the overhead too

There is a second kind of overhead that does not show up in the workflow: the invoice. Most trackers are per seat per month, and most now meter AI work on top of that, a credit allowance per seat, overage billing, a separate charge per agent. The number you sign up for is not the number you pay, and the gap grows exactly as your team leans into agents.

Radial is one number: $50 per user, per year, flat, billed annually, locked at the rate you join. No per-agent seats, no AI credits, no usage meter, because there is no AI in the product to meter. The part that makes it a commitment rather than a slogan is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free. This is not anti-AI. Your agent doing real work is great. The tracker is just not where that intelligence should live or get billed.

Where this approach is honestly the wrong fit

A fair pitch names the edges. If your "engineering project management" actually means running a program office, resource-planning across fifty teams, reporting up a burndown to leadership, or managing a hardware project with a fixed-sequence Gantt schedule, a lean issue tracker is not that tool, and Radial is not pretending to be. Jira and the heavier Work OS platforms exist for that breadth, and if it is load-bearing for you, stay.

The lean version is for engineering-led teams that ship software and want the tracking to disappear into the work. If that is you, the overhead you have been tolerating was never the point of project management. It was just the tool getting in the way.

FAQ

What is engineering project management?

It is the practice of planning, tracking, and delivering engineering work. For a software team specifically, that means scoping work into issues, moving them through a workflow, batching them into sprints or cycles, and keeping a shared view of what is in progress, blocked, and shipped. Broader definitions from other engineering disciplines add scheduling, budgeting, and resource allocation for large technical programs, but a software team's version is narrower: it is issue tracking done well, not a program-management suite.

What is the best project management tool for software development?

There is no single answer, because it depends on what you need. Teams that want maximum breadth and configurability tend toward Jira or Azure DevOps. Teams that want speed and a keyboard-first workflow lean toward focused trackers. Teams glued to their repository stay in GitHub Issues until a flat list stops scaling. The honest filter for an engineering team is: pick the fastest tool that does issue tracking well and resist the ones that make you adopt a whole planning methodology to file a ticket. If a scriptable CLI and agents that ride free matter to you, that narrows the field further.

What are the phases of a software development project?

Most frameworks name six: initiation, planning, design, development, testing, and deployment or maintenance. The lifecycle is useful as a mental model, but from a tracker's point of view all six reduce to the same primitives: issues that carry the work, a workflow that reflects where each one is, and cycles that bound how much you take on at once. You do not need a tool with a "phase" feature. You need issues that move.

Do engineers or project managers manage the work?

On lean software teams, increasingly the engineers do, directly, which is exactly why the tracker being fast and scriptable matters. When filing and updating issues costs a keystroke or a terminal command instead of a meeting, engineers keep the record current as a byproduct of doing the work. A dedicated PM role still adds value coordinating across teams and stakeholders, but the day-to-day tracking should not require one. The overhead-heavy setups are the ones that do.

How do coding agents fit into engineering project management?

The same way a teammate does: they read and write the tracker. In Radial, an agent connects over the MCP server or the CLI and can file issues, triage the queue, update status, and close work, using the identical API surface a human uses. Because every credential is an API client rather than a billed seat, running agents against your tracker does not add a line to the invoice. That is the practical version of "the tracker is the shared system of record," a record both the human and the agent write to.

The short version

Engineering project management is a small job wearing a big coat. The job is: write down the work, move it through a workflow, batch it into cycles, and keep one shared view of state. The coat is everything the tools pile on top, the dashboards, the ceremony, the AI meter on the invoice.

Radial is the lean version: a fast keyboard-first tracker, scriptable from the terminal, one flat locked $50 per user per year, and agents that ride free. See the one number on pricing, or read how the same CLI turns the tracker into something you script in the Linear CLI Linear never shipped.

Originally published on the Radial blog.

Screenshots for AI Agents: Giving Your LLM Eyes on the Web

Nico Acosta — Mon, 06 Jul 2026 11:39:03 +0000

Most LLMs process text. But a growing category of agent tasks is fundamentally visual: checking whether a deploy broke a page layout, verifying that an OG card looks right before a post goes live, monitoring a competitor's pricing page for changes. Text cannot do these jobs. A screenshot can.

The pattern is straightforward: capture a screenshot via API, get back a hosted image URL, pass that URL to a vision model. No headless browser to manage, no Puppeteer session to keep alive, no parsing fragile DOM trees.

Why text-only agents hit a wall

HTML is a poor proxy for what a user sees. Dynamic frameworks render client-side; the raw HTML is a template with no content. CSS controls what is visible and what is not. Interstitials, cookie banners, and lazy-loaded images change the actual visual state. A text-based agent scraping HTML sees none of this.

Vision models bypass the problem entirely. They look at the page the way a user does. The prerequisite: they need an image to analyze. That is what the screenshot API provides.

The capture-and-analyze pattern

The core loop for a vision-capable agent:

async function seeUrl(url: string): Promise<string> {
  const res = await fetch('https://api.grabbit.live/v1/grabs', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.GRABBIT_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      url,
      width: 1280,
      height: 720,
      format: 'webp',
    }),
  });

  const grab = await res.json();
  return grab.image_url; // a hosted URL, ready to pass to any vision model
}

The function returns a URL your agent passes directly to whatever vision model it uses as an image input. The image is already hosted; the vision model fetches it. No base64 encoding, no file handling.

Capture params that matter for agents

Three params make the most difference in agentic contexts.

selector waits for a specific element to appear in the DOM, then captures just that element. Useful when you care about one component, not the whole page.

{
  "url": "https://yoursite.com/dashboard",
  "width": 1280,
  "height": 720,
  "format": "webp",
  "selector": "#revenue-chart"
}

The API returns an image of the #revenue-chart element. Pass that to a vision model to read a number, detect a visual anomaly, or compare it to a previous capture.

full_page captures the entire document height, not just the initial viewport. Set this when your agent needs to see content that loads below the fold.

delay_ms adds a fixed wait after page load. If the page fetches data from an API and renders it into the DOM, a delay_ms of 500 to 1000 gives the script time to finish before the capture fires.

Agentic use cases

Automated visual QA. After each deploy, an agent screenshots key pages and passes them to a vision model with a prompt describing what to look for. The model spots a broken nav, a missing hero image, or an overlapping button before a human does.

OG card verification. Before a post goes live, an agent screenshots the /og?title=... route at 1200 by 630, passes the image to a vision model, and confirms the title, author, and brand logo are all present and not clipped. See How to Generate Dynamic OG Images from Any URL for the template pattern this builds on.

Monitoring competitor pages. Capture a competitor's pricing page on a schedule, then diff the image against the previous capture using a vision model. An alert fires when the layout or text changes significantly.

Visual data extraction. Some dashboards render data into charts with no accessible API. A screenshot of the chart, analyzed by a vision model, extracts the numbers without reverse-engineering a private API.

Registering the tool in an agent

The pattern is the same across frameworks: define a function tool that accepts a URL and returns the image_url.

const screenshotTool = {
  name: 'screenshot_url',
  description: 'Capture a screenshot of a web page and return a hosted image URL for visual analysis.',
  parameters: {
    type: 'object',
    properties: {
      url: {
        type: 'string',
        description: 'The page to screenshot.',
      },
      selector: {
        type: 'string',
        description: 'Optional CSS selector. Waits for this element and captures it.',
      },
      full_page: {
        type: 'boolean',
        description: 'Capture the full document height.',
      },
      delay_ms: {
        type: 'number',
        description: 'Milliseconds to wait after page load before capturing.',
      },
    },
    required: ['url'],
  },
};

When the agent framework calls this tool and the function returns image_url, include it in the next LLM message as an image block. The model sees the page and can reason about it.

From agent tool to MCP server

If you use an MCP-compatible host, you can expose screenshot capability as an MCP tool. The agent calls screenshot_url, gets back an image URL, and uses it in the next turn. Grabbit is designed for exactly this: one API key, one endpoint, no browser runtime to maintain.

Go further

For running this pattern on a full page set on a CI schedule, Visual Regression Testing: A Practical Guide covers the screenshot-and-compare approach in depth.

For capturing any URL on demand from your own code, see the Grabbit screenshot API.

Originally published on the Grabbit blog.

Cursor Pricing 2026: Free vs Pro vs Ultra — Which Plan?

Nico Acosta — Mon, 06 Jul 2026 11:12:17 +0000

Cursor is a popular Agentic AI coding tool, helping developers improve productivity, and even helping SaaS founders with no coding background build fully functional systems. Unlike other agentic tools like Copilot or Claude Code which are primarily editor extensions, Cursor is a standalone IDE (Integrated Development Environment) that replaces the need for using VS Code (it is actually a fork of VS Code). It melds a native coding experience with a AI-first conversational coding solution.

Agentic AI tools like Cursor speed development and improve developer performance. The LLM agents inside Cursor do not just blindly add code to your repository. When prompted with a code change, the AI Agents read your existing code, write code that fits into your existing codebase - matching styles and reading across files and modules to ensure that the generated code is compatible with the entire repository.

But, how much does such an AI tool cost? While the Cursor AI pricing page provides the basic details, this post aims to break down the available plans so that your team can determine the price point most appropriate for your usage needs and help you understand when you need to upgrade to a more advanced plan.

What Cursor Brings to the Table

To understand the pricing of Cursor, it is important to understand the features that Cursor brings to your development team. As previously mentioned, Cursor is a full-fledged IDE that developers can use for coding. The AI Agents inside Cursor have many features that improve coding workflows:

Full repository awareness: Code analysis isn't limited to a single function or file—Cursor understands your full repository and how changes affect other files, modules, and dependencies.
MCP integrations: Cursor has native Model Context Protocol support to pull context from outside your repo—APIs, documentation, databases, or internal tools.
Multiple file changes: Plans and applies multi-file diffs when creating code.
Natural language: Build code using plain English prompts.
File safety: Git-based file safety makes it easy to review, accept, reject, or roll back changes.

No matter the pricing tier - these features are included with your Cursor subscription. The major differences between the Cursor pricing plans comes from how much Agentic access is provided, but we will also dig into the subtle differences.

We'll kick off our review of plans designed for a single developer: what Cursor calls "Individual plans." These plans are best for a founder or developer coding alone on a project.

Hobby Tier: Starting with Cursor

Never used Cursor? The free "Hobby" tier lets you test the tool and see if Cursor's workflows fit your existing processes. Being free, the Hobby plan provides very limited access:

Tab completions: Cursor's coding autocomplete feature lets you build faster - by tabbing the suggested autocompletes from Cursor.
Agent requests: Chat with Cursor's agents to code or debug your code.

This is a great way to experiment with Cursor before buying a paid plan. As you might expect, the number of Agent requests is small—you may complete one feature (or only part of one) before running out of credits and being prompted to upgrade.

Get stuck mid-feature on the Hobby tier? You can activate a 7-day free Pro trial to help you complete your project.

Pro ($20/month): The Sweet Spot for Most Founders

The Pro plan is Cursor's most popular tier: at $20/month for one user, it's an easy entry point that won't break the bank. You get everything in Hobby, plus higher limits:

Unlimited tab completions: Tab completions are virtually unlimited on the Pro plan.
Extended limits on Agent Requests: While not unlimited, the number of Agentic Requests is much higher.

The Pro plan also introduces the ability to run Background Agents. You can ask Cursor to work on a task in the background, while you continue to use the Agent in your current coding. The Background agent works asynchronously to the developer's work - coming back only when it has an answer, or has a clarifying question.

The number of Agent Requests and Background Agents provided in Cursor's Pro plan are provided quantitatively. When an Agentic call is made, Cursor breaks the task up for different agents, and utilizes common LLMs (OpenAI, Gemini and Claude are commonly used) to 'solve' the problem. The Pro plan includes a fixed monthly allowance of AI compute, roughly equivalent to what Cursor internally budgets for a $20/month user. Token usage is abstracted away from the developer—there is no visible token counting, only usage-based limits.

Should a developer utilize all of the Agent requests allocated in a month, there are two options: the team can either block overage charges, and advanced agent features pause or degrade until the next billing cycle, or the team can cap the amount of overage charges that can be accrued in the month.

Pro+ ($60/month) and Ultra ($200/month): For Heavy Users

Once developers begin using Cursor, they may find that they become heavy users, and they reach the limits of the Pro plan. The Pro+ and Ultra plans are built for these developers.

For heavy users of Cursor, the Pro+ plan (at $60 per month) provides everything in the Pro plan, but provides 3x more usage with the top models - allowing for more background tasks, and Agentic problem solving.

For extremely heavy users, Cursor's Ultra plan provides 20x the usage of the Pro plan - for $200 a month.

Team and Enterprise plans

For side projects or solo development, Individual plans make sense—you know your usage and can pick accordingly. But as your team grows, managing individual plans becomes a bookkeeping nightmare and introduces security concerns.

This is where Cursor's team and enterprise plans fit in.

Cursor's team plan costs $40 per month per user, fitting between Pro and Pro+ individual accounts.

Beyond centralized billing and easy team member management, the major advantage is improved data isolation and privacy controls. Prompts and code analyzed on a Teams account are not used to train models.

The biggest privacy win? MCP access is controlled at the team level. Proprietary data from MCPs stays managed by your organization—it can't leak to individual accounts when developers come and go.

For teams with stricter privacy requirements, the Enterprise plan adds region-specific data handling (data stays in your country/region), audit logging, and deeper admin visibility. Enterprise pricing isn't published—you'll need to work with Cursor's sales team for a custom contract.

Addons: Bugbot

Cursor offers Bugbot - a product that scans every PR on Github for potential bugs. It acts like a senior dev that reviews the code, looking for bugs in code being submitted for review. The Pro and Teams versions of Bugbot cost $40 per user per month, in addition to the Cursor subscription. While this may seem expensive at first, Bugbot delivers the highest ROI for teams with junior or mid-level developers by catching common bugs before senior engineers need to review the code. It acts as a first-pass reviewer, reducing review noise and protecting senior developer time.

Further extending Cursor: BrainGrid's spec driven development

Cursor's Agentic coding AI raises the bar and improves productivity of development teams. But all developers who use AI know about falling into 'rabbit holes' where the AI is just not interpreting the prompts well, and hours are spent getting the AI back on track and to have it stop making similar mistakes over and over.

Many times, features are built at the prompt with little forethought or planning. As the feature evolves, so too do the prompts and the underlying code.

In traditional development processes, Product Managers work with the stakeholders to plan what the feature looks like, what it should (and should not) do, and build a roadmap of how the feature will evolve. BrainGrid acts as a product-management layer for AI coding workflows - helping developers take ideas for features, and building requirements around the feature. BrainGrid asks clarifying questions to help the product owner better understand what is being built, and what is out of scope. This spec driven development leads to the creation of a requirements document that describes the scope of the feature and what is going to be built. The team can analyze and make changes.

Once the requirements document is approved, BrainGrid creates tasks with prompts that can be fed directly into Cursor. The prompts are highly detailed, which means that there are fewer back and forth iterations with the Agentic AI to actually build the feature. See an example of feature building with BrainGrid and Cursor in our Windsurf vs. Cursor comparison.

Connecting the BrainGrid MCP into Cursor ensures that features are better understood and fleshed out - instead of just building at the prompt. This results in faster development, fewer rabbit holes, and higher productivity.

Starting at $10/month/user (to $75/month/user for enterprises), BrainGrid's product driven specifications gives Cursor additional superpowers, further accelerating your team's development productivity.

Wrapping up

Cursor's paid plans start at $20/month and scale to $200/month for the Ultra tier. For development teams, the Team and Enterprise plans simplify billing while adding privacy and security controls. And for teams going all-in with agentic coding, spec-driven development tools like BrainGrid help you build better prompts—leading to focused code and fewer AI rabbit holes.

To learn more, visit Cursor.ai or explore spec-driven development at BrainGrid.ai.

FAQ

How much does Cursor Team cost?

Cursor Team starts at $40/month per user.

How costly is Cursor?

Plan	Price	Best For
Hobby	Free	Testing Cursor before committing
Pro	$20/mo	Solo founders shipping MVPs
Pro+	$60/mo	Heavy daily users hitting Pro limits
Ultra	$200/mo	Full-time AI-assisted development
Team	$40/user/mo	Startups with 2+ developers
Enterprise	Custom	Regulated industries, large orgs

Is Cursor AI free or paid?

There's a free Hobby tier, but paid plans start at $20/month.

Is Cursor better than Copilot?

They're different tools. Copilot generates code snippets; Cursor understands your full repository and builds code that fits your existing codebase.

Do you need a subscription for Cursor?

Yes, though the Hobby tier is free for testing.

Is Cursor's free plan good?

It's like a taste of ice cream—enough to evaluate, but most real-world development requires a paid plan.

How much do different models cost in Cursor?

By default, Cursor uses Auto mode, that uses internal tooling to pick the bets agent for a given task. This can be overridden, and developers can choose specific Agents (like Opus 4.5, Sonnet 4.5, ChatGPT 5.2, and Gemini 3) for all queries. Cursor has published cost per million tokens for many of the most popular and powerful models in their documentation

Originally published on the BrainGrid blog.

How to Take a Website Screenshot in Node.js (4 Ways)

Nico Acosta — Sun, 05 Jul 2026 11:37:11 +0000

Node.js has no shortage of ways to screenshot a website. The honest list is four: Puppeteer, Playwright, a thin wrapper like capture-website, or a hosted API. The first three all run Chromium on your server; the fourth does not. This guide shows each with working code and the trade-off that decides which one you want.

1. Puppeteer (the default)

Puppeteer is the most common choice and drives headless Chrome directly:

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle0' });
await page.screenshot({ path: 'example.png', fullPage: true });
await browser.close();

The detail that matters is waitUntil: 'networkidle0', which waits for the network to settle before capturing so you do not screenshot a half-loaded page. fullPage: true captures the whole scrolling page. For elements, quality, and the lazy-load gotchas, see full-page screenshots in Puppeteer.

2. Playwright (cross-browser)

Playwright has nearly identical code and adds Firefox and WebKit with one API:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'example.png', fullPage: true });
await browser.close();

The practical wins over Puppeteer are auto-waiting (less timing code) and being able to capture the same page in three engines, including the engine behind Safari. See screenshots in Playwright for the details.

3. capture-website (the short wrapper)

If you just want one screenshot and do not want to manage a browser lifecycle, capture-website wraps Puppeteer into one call:

import captureWebsite from 'capture-website';

await captureWebsite.file('https://example.com', 'example.png', {
  fullPage: true,
});

It still installs and runs Chromium under the hood, so the operational cost is the same as Puppeteer. It just hides the boilerplate. Avoid older packages like node-webshot that wrap the abandoned PhantomJS; do not build new code on them.

The cost the first three share

All three options above mean you run a browser on your server. None of the hard parts are the screenshot call:

Provisioning Chromium. It needs a long list of system libraries. Slim containers and serverless functions hit missing-dependency errors before the first capture.
Memory and zombie processes. A browser not closed on every error path leaks memory and orphans processes under load.
Patching and scaling. Chromium ships security updates constantly, and one browser handles one job at a time, so volume means a pool and a queue.

If screenshots are a production feature rather than a script, this is infrastructure you now own.

4. A hosted API (no browser to run)

A screenshot API runs the browser fleet for you. From Node.js it is one fetch:

const res = await fetch('https://api.grabbit.live/v1/grabs', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://example.com',
    width: 1280,
    full_page: true,
    format: 'webp',
  }),
});

const { image_url } = await res.json();

The response is a hosted image URL:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "format": "webp",
  "bytes": 48210,
  "execution_ms": 1180
}

The library options map onto request parameters: viewport is width (320 to 1920) and height (240 to 1080), full page is full_page, the element pattern is a selector field, and the manual wait becomes delay_ms (0 to 10000). format is png, jpeg, or webp.

Which to use

Already running Puppeteer or Playwright for tests or scraping: add the screenshot call, you are done.
A quick one-off script: capture-website is the least code.
Screenshots are a production feature: an API, so you do not operate Chromium in your Node service at all.

For the framework deep dives, see screenshots in Puppeteer and screenshots in Playwright. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing.

Originally published on the Grabbit blog.

Ralph Wiggum Plugin for Claude Code: Autonomous Coding Guide

Nico Acosta — Sun, 05 Jul 2026 11:12:51 +0000

You know that feeling when you're three hours deep into fixing tests, and each fix breaks something else?

What if you could just walk away? Describe what you want, go grab dinner, and come back to working code?

That's Ralph Wiggum.

Why "Ralph Wiggum"?

Remember Ralph Wiggum from The Simpsons? The kid who keeps trying despite failing spectacularly every single time?

That's exactly what this plugin does. It fails, learns, tries again, and keeps going until it succeeds. No complaints. No giving up. Just persistent iteration until the job is done.

The creator, Geoffrey Huntley, captured it perfectly: "Ralph is a Bash loop."

while :; do cat PROMPT.md | claude ; done

Keep running the same prompt until it works. That's Ralph.

What is the Ralph Wiggum Plugin for Claude Code?

The Ralph Wiggum plugin is Claude Code's official plugin that enables autonomous loops—letting AI work on its own for hours without you watching.

Normal Claude Code: You ask → It does → You check → You ask again → Repeat.

Ralph Wiggum Plugin: You tell Ralph what you want → Walk away → Come back to finished work. The autonomous loop handles everything.

What is an Autonomous Loop in Claude Code?

An autonomous loop is AI that keeps working without you. The Ralph Wiggum plugin creates these autonomous loops in Claude Code.

You give Claude Code a task with clear "done" criteria
Claude Code tries to complete it
When Claude tries to stop, the Ralph Wiggum plugin checks if it's actually done
If not done: Ralph restarts Claude Code with the same task
Claude Code sees previous attempts and tries a different approach
The autonomous loop repeats until done or hits your iteration limit

The key: Each loop is smarter because it learns from previous failures.

flowchart TD
    Start([You: Give task with 'done' criteria]) --> Claude[Claude attempts task]
    Claude --> Ralph{Ralph checks:<br/>Is it done?}
    Ralph -->|Not done| Restart[Ralph restarts Claude<br/>with same task]
    Restart --> Learn[Claude sees previous attempts<br/>tries different approach]
    Learn --> Claude
    Ralph -->|Done| Success([✅ Task Complete])
    Ralph -->|Max iterations| Limit([⏱️ Hit iteration limit])

    style Start fill:#C2E476,stroke:#795BC2,stroke-width:2px,color:#0B211F
    style Success fill:#C2E476,stroke:#795BC2,stroke-width:2px,color:#0B211F
    style Limit fill:#795BC2,stroke:#C2E476,stroke-width:2px,color:#fff
    style Ralph fill:#795BC2,stroke:#C2E476,stroke-width:2px,color:#fff
    style Claude fill:#10312D,stroke:#795BC2,stroke-width:2px,color:#C2E476
    style Restart fill:#10312D,stroke:#C2E476,stroke-width:2px,color:#C2E476
    style Learn fill:#10312D,stroke:#C2E476,stroke-width:2px,color:#C2E476

Why Do We Need This?

The Normal Problem

You: "Add user authentication"
Claude: *generates code*
You: "No, use JWT tokens"
Claude: *updates code*
You: "The password reset is missing"
Claude: *adds password reset*
You: "Tests are failing"
Claude: *fixes tests*

Exhausting and slow.

The Ralph Solution

You: "Add user authentication with JWT tokens, password reset,
and tests with >80% coverage. Done means all tests pass."
Ralph: *works for 2 hours*
Ralph: "Complete. All tests passing."

One detailed instruction. Walk away. Come back to finished work.

When to Use Ralph Wiggum Plugin (And When Not To)

✅ Use Ralph For:

Mechanical tasks: "Add JSDoc comments to every function"
Tasks with tests: Anything that can verify itself automatically
Big refactors: Framework upgrades, dependency updates
Overnight work: Queue it Friday, review Monday

❌ Don't Use Ralph For:

Judgment calls: Architecture decisions, design choices, security code
Vague tasks: "Make the UI better"
Production fires: When things are broken NOW
Quick tasks: If it takes 2 minutes manually, just do it

Rule: If you can describe exactly what "done" looks like, the Ralph Wiggum plugin can probably do it using autonomous loops.

How to Install and Use Ralph Wiggum Plugin: Quick Start Guide

Install

/plugin install ralph-wiggum@claude-plugins-official

Commands

Start an autonomous loop:

/ralph-wiggum:ralph-loop "<task>" --max-iterations 30

Start autonomous loop with auto-stop:

/ralph-wiggum:ralph-loop "<task>" --max-iterations 30 --completion-promise "COMPLETE"

Cancel Ralph Wiggum plugin:

/ralph-wiggum:cancel-ralph

Example: Add Documentation

Bad prompt:

/ralph-wiggum:ralph-loop "Add comments to my functions" --max-iterations 10

Good prompt:

/ralph-wiggum:ralph-loop "Add JSDoc comments to every exported function in src/utils/.

Rules:
- Every exported function gets JSDoc
- Include @param, @returns, @throws
- Use clear descriptions

Done means: Every exported function has complete JSDoc.

Output <promise>DOCUMENTED</promise> when complete." --max-iterations 20 --completion-promise "DOCUMENTED"

Why the good prompt works:

Clear scope (src/utils)
Specific rules
Clear "done" criteria
Safety limit (20 iterations)

The Secret: BrainGrid Makes Perfect Prompts

Here's what everyone misses: The Ralph Wiggum plugin is only as good as your prompt.

Writing good prompts is hard. You need to think through every edge case, acceptance criteria, and implementation detail.

This is where BrainGrid changes everything.

Without BrainGrid

Your vague idea: "Add user authentication"

You write a prompt, but what does "authentication" mean? Email/password? OAuth? Password reset? Rate limiting? The Ralph Wiggum plugin burns iterations guessing.

With BrainGrid MCP

BrainGrid connects to Claude Code via MCP (Model Context Protocol), giving Claude direct access to structured requirements without copy-pasting.

Step 1: Set up BrainGrid MCP

First, connect BrainGrid to Claude Code:

claude mcp add --transport http braingrid https://mcp.braingrid.ai

Verify the connection:

/mcp

You should see braingrid listed. BrainGrid will prompt you to authorize via OAuth in your browser.

Step 2: Create a requirement in BrainGrid

In Claude Code, ask:

"Create a requirement in BrainGrid for user authentication system"

Claude (with BrainGrid MCP) creates a structured requirement with:

Clear description
Acceptance criteria
Technical constraints
Test requirements

Step 3: Refine in BrainGrid dashboard

Head to BrainGrid AI Dashboard and work with the BrainGrid agent:

"Help me refine this requirement and ask any clarifying questions"

The agent helps you catch missing details and edge cases.

Step 4: Break down into tasks

In the BrainGrid dashboard, click "Break down requirement into tasks." BrainGrid generates concrete, implementable tasks tied to REQ-456.

Step 5: Build with Ralph + BrainGrid

Now the magic happens. In Claude Code:

/ralph-wiggum:ralph-loop "Build REQ-456 from BrainGrid" --max-iterations 40

Ralph automatically:

Fetches the full requirement from BrainGrid via MCP
Reads all acceptance criteria
Understands technical constraints
Knows how to verify completion
Builds with complete context

No copy-pasting. No missing details. Ralph just points at the BrainGrid requirement and builds it correctly.

The Difference

Without BrainGrid: Vague prompt → Ralph Wiggum plugin guesses → Wastes iterations → Wrong implementation

With BrainGrid MCP: Detailed requirement → Ralph Wiggum plugin fetches full context → Builds it right the first time

The Complete Workflow

flowchart LR
    A[💡 Rough idea<br/>in Claude Code] --> B[📝 Create requirement<br/>in BrainGrid]
    B --> C[🔍 Refine requirement<br/>in BrainGrid dashboard]
    C --> D[📋 Break down into tasks<br/>in BrainGrid]
    D --> E[🤖 Build REQ-456<br/>with Ralph]
    E --> F[✅ Working feature<br/>with tests]

    style A fill:#C2E476,stroke:#795BC2,stroke-width:2px,color:#0B211F
    style B fill:#795BC2,stroke:#C2E476,stroke-width:2px,color:#fff
    style C fill:#795BC2,stroke:#C2E476,stroke-width:2px,color:#fff
    style D fill:#795BC2,stroke:#C2E476,stroke-width:2px,color:#fff
    style E fill:#10312D,stroke:#C2E476,stroke-width:2px,color:#C2E476
    style F fill:#C2E476,stroke:#795BC2,stroke-width:2px,color:#0B211F

BrainGrid = The thinking phase (what to build)
Ralph = The execution phase (building it)

Most people skip the thinking phase and jump straight to execution. That's why their prompts fail and the Ralph Wiggum plugin spins endlessly in autonomous loops.

Setup guide: BrainGrid MCP Integration

Try BrainGrid free: braingrid.ai

Ready-to-Use Templates

Feature Implementation

/ralph-wiggum:ralph-loop "Build user profile edit feature.

What it needs:
- Form with name, email, bio fields
- Save button calls /api/users/me
- Show success/error messages
- All fields required except bio

Tests: Form renders, validation works, API called correctly

Done means: Feature works and tests pass.

Output <promise>COMPLETE</promise> when done." --max-iterations 30

Bug Fix

/ralph-wiggum:ralph-loop "Fix: Users can submit empty contact form.

Steps:
1. Add validation for required fields (name, email, message)
2. Show error messages for empty fields
3. Prevent submission if validation fails
4. Add test to prevent regression

Done means: Empty form blocked and test proves it.

Output <promise>FIXED</promise> when done." --max-iterations 15

Quick Tips

Prompt Checklist:

✅ Clear scope (what files/features)
✅ Specific requirements (what to do)
✅ "Done" definition (how to verify)
✅ Safety limit (--max-iterations)

Iteration Guidelines:

Simple tasks: 10-20 iterations
Medium features: 20-40 iterations
Complex builds: 40-60 iterations
Always set --max-iterations (never unlimited)

Cost Estimates:

Small task: $5-20
Medium feature: $30-60
Large build: $60-150+

Pro tip: Test manually with one iteration before running 50-iteration loops.

Ralph Wiggum Plugin Troubleshooting

Loop never completes?
Your "done" criteria aren't clear enough. Be more specific.

Same error every loop?
Add to prompt: "If stuck after 10 tries, document the error and stop."

Costs too high?
Lower --max-iterations, use .claudeignore, break into smaller tasks.

Windows issues?
Install jq: choco install jq or use WSL.

Frequently Asked Questions About Ralph Wiggum Plugin

What is the Ralph Wiggum plugin?

The Ralph Wiggum plugin is an official Claude Code plugin that creates autonomous loops. It allows Claude Code to work continuously on a task, automatically restarting and trying different approaches until the task is complete or the iteration limit is reached.

How do autonomous loops work in Claude Code?

Autonomous loops work by: (1) You provide a task with clear "done" criteria, (2) Claude Code attempts the task, (3) Ralph Wiggum checks if it's actually done, (4) If not done, Ralph restarts Claude with the same task, (5) Claude sees previous attempts and tries a different approach, (6) This repeats until done or the iteration limit is hit.

How do I install the Ralph Wiggum plugin?

Install the Ralph Wiggum plugin in Claude Code using:

/plugin install ralph-wiggum@claude-plugins-official

What commands does the Ralph Wiggum plugin support?

The Ralph Wiggum plugin supports three main commands:

Start a loop: /ralph-wiggum:ralph-loop "<task>" --max-iterations 30
Start with auto-stop: /ralph-wiggum:ralph-loop "<task>" --max-iterations 30 --completion-promise "COMPLETE"
Cancel: /ralph-wiggum:cancel-ralph

When should I use Ralph Wiggum plugin?

Use the Ralph Wiggum plugin for mechanical tasks, tasks with automated tests, big refactors, and overnight work. Don't use it for judgment calls, vague tasks, production emergencies, or quick 2-minute tasks.

How much does Ralph Wiggum plugin cost?

Cost estimates for Ralph Wiggum plugin usage:

Small task: $5-20
Medium feature: $30-60
Large build: $60-150+

Can I use Ralph Wiggum with BrainGrid?

Yes! BrainGrid MCP integration works perfectly with Ralph Wiggum plugin. BrainGrid helps create structured requirements that Ralph can fetch and build, resulting in better prompts and fewer wasted iterations.

Conclusion

The Ralph Wiggum plugin removes the iteration tax from mechanical work in Claude Code.

The shift:

Before: 3 hours of back-and-forth implementing a feature
After: 10 minutes writing a clear prompt, then do other work while Ralph builds

Start small. Document one folder. Fix linter errors in one directory. Build confidence in what prompts work.

Then scale up. Queue overnight work. Run parallel loops. Let Ralph handle the boring parts while you focus on hard problems.

Install Ralph Wiggum plugin now:

/plugin install ralph-wiggum@claude-plugins-official

Want perfect prompts every time? BrainGrid helps you think through requirements so the Ralph Wiggum plugin builds it right the first time using autonomous loops.

Try BrainGrid + Ralph free →

Originally published on the BrainGrid blog.

Migrating from Linear to Radial in one command

Nico Acosta — Sat, 04 Jul 2026 13:14:59 +0000

Most people who search "migrate from linear" are not leaving because Linear is slow or badly built. It is neither. They are leaving because something about the shape of the tool stopped fitting: the seat math as the team grew, the AI features arriving whether they were asked for or not, or simply the pull toward a tracker their agents can drive without a per-vendor integration for each one. The decision is the hard part. The data move should not be.

For Radial, the data move is a command. You export your Linear workspace, run radial import --from linear against the file, and your issues, projects, labels, comments, and history come across in a single run. Dry-run it first so you see exactly what lands before you commit.

The two-minute version

If you already have a Linear export on disk, the whole move is two commands:

npm i -g radial.build
radial import --from linear export.json --dry-run

The --dry-run flag does everything except write. It reports how many issues it would create, how many would fail, plus the relations, comments, and new labels it would build, and it surfaces warnings for anything it cannot map cleanly. When the dry run looks right, drop the flag and run it for real:

radial import --from linear export.json -t ENG

The -t ENG puts the imported issues on your ENG team. That is the entire migration for a single workspace. No connect-your-account handshake, no waiting on an import queue, no migration window to schedule.

What actually comes across

The import is a deep import, not a flat issue dump. In one run it brings:

Issues, with their titles, descriptions, and status mapped to Radial's workflow.
Projects, so the structure you had in Linear is not flattened into one bucket.
Labels, created as needed (the dry run tells you how many are new).
Comments, preserved on the issues they belong to.
History and relations, so the links between issues survive the move.

When the run finishes, you get a one-line summary of what landed: issues created, any that failed, plus relations, comments, and new labels created, followed by up to ten warnings for anything that needed a judgment call. Because every command takes --json, you can also pipe that summary straight into a script if you are migrating several workspaces in a loop:

radial import --from linear export.json --dry-run --json

One honest caveat worth stating up front: the import is single-run. Re-running the same file imports it again rather than reconciling, so there is no cross-run idempotency yet. Dry-run first, run once, verify. If you are moving several teams, do them one file at a time and check each summary.

What changes, and what stays the same

The fair thing to do in a migration guide is tell you what you are giving up, not just what you are gaining.

What stays the same. The core loop you are used to in Linear is the core loop in Radial: a fast keyboard-first board and list, issues with statuses and priorities and estimates, projects, and time-boxed Cycles where Linear has cycles. If speed is why you loved Linear, that part carries over; Radial is built the same way, for the same reason. Linear's famous internal target is that nothing in the interface should take more than a few hundred milliseconds to render, and that discipline is the right one. Radial holds the same bar.

What you give up. Radial does not have Linear's full surface area. There is no roadmap or initiative timeline, no built-in insights or velocity dashboards, no Linear Asks-style intake from Slack, and the ecosystem of third-party integrations is smaller. If your team runs on Linear's roadmap and analytics views, that is a real gap to weigh before you export. Better to know now than to find out after.

What changes for the better, if the bill was the reason. This is the part the usual alternatives miss. The most common thing people wire into a modern tracker is an agent, and the most common thing that breaks is cost. A builder in r/Linear put it plainly while comparing agent-delegation setups: the biggest pain point is cost. Radial's answer is structural, not a discount. Every agent credential is a client of the API, not a billed seat, so your agents ride free. And the price you pay is one flat number: $50 per user, per year, billed annually, locked at the rate you join. No AI credit balance, no usage meter, no overage line, because there is no AI in the product to meter.

The commitment behind that is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free. This is not anti-AI. Your agent doing real work is great. The point is that the tracker is not where that intelligence should live or get billed; it is the fast system of record your agent writes to over a real CLI, REST API, and MCP server. One surface, any agent, no per-vendor integration to bolt on for each new one.

FAQ

How do I export my data from Linear?

Linear exports workspace and issue data from Settings > Administration > Import/Export, and it also offers a CSV export for issue lists. Take that file and point Radial at it: radial import --from linear export.json --dry-run. The dry run reads the file and reports exactly what it would create without writing anything, so you can confirm the mapping before the real run.

Does Radial have a CLI to run the migration?

Yes, and the CLI is how the migration runs. Radial is CLI-first by design: radial import --from linear is a first-party command, not a community wrapper. Linear itself ships no official CLI (there are community CLIs and a GraphQL API), so if a terminal-native workflow is part of why you are switching, that is a real difference, not a marketing line. See the Linear CLI Linear never shipped for the fuller story.

Will I lose my comments and history?

No. The import preserves comments on the issues they belong to and brings history and relations across, not just bare issue titles. The dry-run summary counts the comments, relations, and labels it would create, so you can verify the totals against Linear before you commit.

Is Radial just a cheaper Linear?

No, and it is worth being precise: there are trackers cheaper than Radial, and Linear is a genuinely excellent tool. The difference is not the number, it is the shape. Radial is one flat locked price with agents riding free and a pledge that pays you if AI billing ever shows up, versus a per-seat plan with an AI layer that can grow. Pick by what made you leave, not by which line item is smaller. We lay out the full side-by-side in Radial vs Linear.

Can my coding agent run the migration?

Yes. The import is available over the REST API (POST /v1/import) with a scoped API key, so an agent you authorize can run the move, or script it across several workspaces, without a human at the keyboard. Agents are clients of the API, not billed seats, so wiring one up costs nothing extra. Once you are on Radial, your agent files, triages, and closes issues over the MCP server at mcp.radial.build too.

The short version

Moving off Linear is usually gated by the data, not the decision. Radial makes the data the easy part: radial import --from linear brings issues, projects, labels, comments, and history across in one run, and --dry-run shows you the result before you commit. What you migrate into keeps the speed you liked, drops the surface you did not use, and holds one flat locked price with agents riding free.

See the one number on pricing, or read Radial vs Linear for the full comparison before you export.

Originally published on the Radial blog.

Playwright Visual Regression Testing: Catch UI Bugs in CI

Nico Acosta — Sat, 04 Jul 2026 11:37:30 +0000

Playwright has visual regression testing built in. One assertion, toHaveScreenshot, captures the page, diffs it against a stored baseline, and fails the test when the UI changes unexpectedly. The setup is genuinely a few lines. The hard part is not the API; it is keeping baselines stable so CI catches real regressions instead of failing on font rendering. This guide covers both.

The core workflow: toHaveScreenshot

A visual test is a normal Playwright test with one screenshot assertion:

import { test, expect } from '@playwright/test';

test('homepage looks correct', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('homepage.png');
});

On the first run, there is no baseline, so Playwright captures homepage.png and saves it, and the test "fails" once to tell you a baseline was created. On every run after that, it captures a fresh screenshot, compares it pixel by pixel against the saved baseline, and passes only if they match within your threshold.

toHaveScreenshot is the right assertion to reach for: it auto-waits for the page to stop changing and retries until the screenshot is stable, which removes a whole class of flaky-capture bugs. Prefer it over the older toMatchSnapshot.

Updating baselines after an intentional change

When you change the UI on purpose, the baseline is now wrong and the test should fail until you accept the new look. Regenerate baselines with a flag:

npx playwright test --update-snapshots

This rewrites the baseline images for any test whose capture changed. Commit those images so the new baseline travels with the code in Git, and reviewers can see the visual diff in the pull request.

The real problem: CI flake

The most common frustration is tests that pass locally and fail in CI. This is almost never a real regression. It is the rendering environment: a different OS, different fonts, a different GPU, or a different browser build produces sub-pixel anti-aliasing differences that fail an exact-match comparison.

Two fixes, used together:

1. Generate baselines in the CI environment. Do not commit baselines captured on your Mac and expect them to match a Linux CI runner. Generate them inside the same container that runs the tests, commonly the official Playwright Docker image, so the rendering matches.

2. Allow a small diff. Set a tolerance so anti-aliasing noise does not fail the build:

await expect(page).toHaveScreenshot('homepage.png', {
  maxDiffPixelRatio: 0.01, // tolerate up to 1% differing pixels
});

maxDiffPixelRatio and maxDiffPixels are the two knobs. Start strict and loosen only as far as you must to stop false failures, or you will mask real regressions.

Where a screenshot API fits

Playwright's toHaveScreenshot is the right tool for asserting your own components and pages inside a Playwright suite. A screenshot API is not a replacement for it; it is a complementary capture layer for a few specific jobs:

A stable, environment-independent baseline source. Capturing the same URL through a hosted browser fleet gives you a consistent render that does not depend on each developer's machine.
Capturing pages outside your test suite. Monitoring a live production page or a third-party page you do not control, on a schedule, is a capture job, not a Playwright test.
A reference image of the real deployed page to compare against, rather than a locally rendered one.

Here is a baseline capture as a single request:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "png"
  }'

The response includes a hosted image you can store as a reference:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....png",
  "width": 1280,
  "format": "png",
  "bytes": 96420,
  "execution_ms": 1240
}

Width accepts 320 to 1920, height 240 to 1080, full_page captures the whole page, and delay_ms (0 to 10000) lets content settle before the shot. To be clear about scope: Grabbit captures the images. The diffing, the assertions, and the pass/fail live in Playwright or your VRT tool of choice.

Putting it together

Use toHaveScreenshot for component and page assertions inside your Playwright suite.
Generate baselines in the CI container and allow a small maxDiffPixelRatio so you catch real regressions, not font noise.
Reach for a screenshot API when you need a consistent baseline source or to capture pages that live outside the test suite.

For the bigger picture, see the practical guide to visual regression testing and the roundup of visual regression testing tools. For Playwright screenshot mechanics beyond testing, see taking screenshots in Playwright.

Originally published on the Grabbit blog.

Windsurf MCP Servers: Setup Guide + Best Servers (2026)

Nico Acosta — Sat, 04 Jul 2026 11:12:57 +0000

Every time Windsurf's AI writes database code, it guesses at your schema. Every API call gets placeholder responses you'll need to fix manually. That copy-paste cycle kills your momentum—and it doesn't have to be this way.

Model Context Protocol (MCP) servers connect Windsurf to your actual databases, APIs, and external services. Instead of generating boilerplate that needs fixing, Windsurf's agents query your real systems and write code that works the first time.

In this guide, you'll learn what MCP servers are, how to set them up in Windsurf, and which servers will help you ship faster.

What is MCP in Windsurf?

MCP servers are bridges between Windsurf and external services. They give Windsurf's agents context beyond your codebase—databases, APIs, cloud infrastructure, and more.

After connecting a database MCP server, Windsurf's agents can examine your actual tables and columns. The code it generates is based on real queries that retrieve data correctly, and does not rely on placeholder SQL that must be manually updated.

Why MCP Matters for Shipping Faster

The same pattern applies across your entire stack. An API MCP server lets Windsurf call actual endpoints and write code that correctly parses real responses. A GitHub MCP server gives context about open issues and PRs.

Without MCP, you're stuck fixing the same boilerplate over and over—copying real values into placeholder code. With MCP, the agents generate code that works the first time, letting you ship faster with fewer manual fixes.

How to Set Up MCP Servers in Windsurf

Many MCP servers are available for Windsurf. Some install directly from the MCP Marketplace with a few clicks, while others require manual JSON configuration.

Installing from the MCP Marketplace

To access the MCP Marketplace, open Windsurf Settings (on Mac: Windsurf → Settings → Windsurf Settings or press ⌘,). Search for "MCP" and click the link to open the Marketplace.

The marketplace offers many MCP servers ready to install.

For example, the PostgreSQL MCP server walks you through connection setup—host, port, credentials—and automatically populates the JSON config when complete.

Installing MCPs manually with JSON

If your MCP server isn't in the Marketplace, you can add it manually by editing the mcp_config.json file. Access this file from the Marketplace by clicking the gear icon.

Here is an example mcp_config.json file with two MCP servers set up, BrainGrid, and the PostgreSQL set up from the marketplace:

{
  "mcpServers": {
    "braingrid": {
      "args": [
        "-y",
        "mcp-remote@latest",
        "https://mcp.braingrid.ai/mcp"
      ],
      "command": "npx"
    },
    "postgresql": {
      "args": [
        "run",
        "-i",
        "--rm",
        "mcp/postgres",
        "postgresql://admin:admin@example.com:5432/my-secret-database"
      ],
      "command": "docker",
      "disabled": false,
      "env": {}
    }
  }
}

This JSON file includes servers installed via the Marketplace as well as manually added ones. The Marketplace simplifies setup by properly formatting the JSON entry for you. The PostgreSQL MCP server creates a small local Docker container with Postgres utilities and your database connection details.

For BrainGrid MCP installation, follow the official setup guide.

Windsurf MCP Configuration Format

Each MCP entry specifies a command (like npx or docker) and args (the arguments to pass). Windsurf runs these commands when it starts, establishing the MCP server connections.

Top MCP Servers for Windsurf Developers

Databases: There are MCP servers for most major databases and DB-as-a-service platforms (MySQL, postgres, MongoDB, Redis, Neon, etc.)
CloudOps: AWS and Heroku MCP servers give Windsurf insight into how the application is deployed and configured in the cloud. Additionally access to logs and environment specific behavior can help Windsurf improve reliability.
GitHub: Agents can read pull requests, inspect issues, and understand commit history. This repository content does not live in the codebase, but influences how the code should change.
Stripe: Visibility into billing flows, customers, subscriptions, invoices, and webhooks. Agents can debug and reason about how the billing logic interacts with the codebase.
BrainGrid: Takes vague development ideas, turns them into explicit requirements, and breaks those requirements into structured tasks the agents can execute.
Swagger: When agents are able to read the API specs, they can build to existing endpoints, and parse the results in based on actual responses from the API. No more hallucinated or boilerplate API code to be fixed.

Note that each MCP provides a number of tools to Windsurf, and that Windsurf places a cap of 100 tools that can be active. This might mean enabling and disabling MCPs during different phases of coding.

BrainGrid MCP: Spec-Driven Development in Windsurf

BrainGrid is an AI product manager that helps developers plan, specify, and build new features. Often, developers jump right in and start prompting before they have a clear picture of what they're building. Running those initial ideas through BrainGrid turns them into structured requirements.

For example, say you want to add a billing flow to your application. BrainGrid analyzes your existing code and asks clarifying questions: which payment providers, what subscription tiers, how to handle failures. These answers become a requirements document your team can approve—spec-driven development. BrainGrid then breaks the requirements into implementation tasks.

The BrainGrid MCP lets Windsurf access these requirements and tasks directly. Instead of copying prompts into the chat, Windsurf reads the full context and builds the feature.

The result: agents build exactly what you specified, with less cleanup afterward. Less context-switching, faster shipping.

Troubleshooting Common Windsurf MCP Issues

Command not found: If Docker isn't running locally, Docker-based MCPs will fail. Start Docker first.
Missing dependencies: Some MCPs require packages like mcp-remote. Install them before configuring.
Changes not taking effect: After installing new dependencies, restart Windsurf to pick up the changes.

Start Shipping Faster Today

MCP servers give Windsurf's agents the full picture: databases, APIs, issues, designs, and more. With this context, the code they produce is higher quality and far less likely to need the manual fixes you've come to expect from AI-generated code.

When agents build closer to what you actually need, you ship faster. Less time fixing, more time launching.

Ready to go further? BrainGrid adds spec-driven development to your workflow—turning vague ideas into structured requirements that generate precise prompts for Windsurf's agents.

Frequently Asked Questions

What is MCP in Windsurf?

MCP (Model Context Protocol) gives Windsurf's agents context beyond your codebase. This includes cloud services, databases, API specifications, or any third-party service that provides insight into how your application works.

How do I configure MCP servers in Windsurf?

Use the MCP Marketplace for one-click installs, or manually edit the mcp_config.json file with the server configuration.

Where is the Windsurf MCP config file located?

The config file is at ~/.codeium/windsurf/mcp_config.json. The easiest way to access it is through the MCP Marketplace by clicking the settings gear icon.

What MCP servers work with Windsurf?

Any MCP server using stdio (local) or http (remote) transport works with Windsurf.

How does Windsurf MCP compare to Cursor MCP?

Both support MCP, but they use it differently. Cursor treats MCP as a transactional tool—query and respond. Windsurf integrates MCP into its agentic workflow, using the context for multi-step planning and chaining data across tasks.

Why is my Windsurf MCP server not working?

Check the troubleshooting section above. The MCP Marketplace shows connection status—look there for specific error messages to diagnose the issue.

Originally published on the BrainGrid blog.

Migrating off Jira with one command: radial import --from jira

Nico Acosta — Fri, 03 Jul 2026 13:14:34 +0000

Most Jira migration guides are about moving from one Jira to another: Server or Data Center to Cloud, run the Jira Cloud Migration Assistant, plan the maintenance window, pre-load users. That is a real project, and Atlassian's tooling handles it. This guide is about the other migration: the one where you are leaving Jira for a faster, focused tracker and the only thing standing between you and the switch is your data.

For Radial, that part is a command. You export your Jira project, run radial import --from jira against the file, and your issues, projects, labels, comments, and history come across in a single run. Dry-run it first so you see exactly what lands before you commit.

The two-minute version

If you already have a Jira export on disk, the whole move is two commands:

npm i -g radial.build
radial import --from jira export.json --dry-run

radial import --from jira export.json -t ENG

The -t ENG puts the imported issues on your ENG team. That is the entire migration for a single project. No assistant app, no maintenance window, no overage to budget for.

What actually comes across

The import is a deep import, not a flat issue dump. In one run it brings:

Issues, with their titles, descriptions, and status mapped to Radial's workflow.
Projects, so the structure you had in Jira is not flattened into one bucket.
Labels, created as needed (the dry run tells you how many are new).
Comments, preserved on the issues they belong to.
History and relations, so the links between issues survive the move.

radial import --from jira export.json --dry-run --json

One honest caveat worth stating up front: the import is single-run. Re-running the same file imports it again rather than reconciling, so there is no cross-run idempotency yet. Dry-run first, run once, verify. If you are moving many projects, do them one file at a time and check each summary.

Why teams make this move, and why some shouldn't

People do not leave Jira because it is bad. They leave because they adopted it for engineering work and never needed its enterprise breadth, and the weight became a tax they pay every day. If a board that takes seconds to load and a workflow you configured for a week is your pain, a fast tracker fixes it.

But the reason that the usual alternatives miss is the bill. Jira is per seat per month, and its AI layer, Rovo, ships a monthly credit allowance per seat with overage billing, and Rovo Dev is a further charge per developer. The subscription is the base; the AI is a meter. Switch to another per-seat-plus-meter tracker and you have changed the logo, not the trajectory.

Radial is a fast, keyboard-first issue tracker priced at one flat number: $50 per user, per year, billed annually, locked at the rate you join. There is no AI credit balance, no usage meter, and no overage line, because there is no AI in the product to meter. Your agents ride free: every agent credential is a client of the API, not a billed seat. The commitment behind that is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

This is not anti-AI. Your agent doing real work is great. The point is that the tracker is not where that intelligence should live or get billed; it is the fast system of record your agent writes to over a real CLI, REST API, and MCP server.

A fair guide names the gaps, too. Radial does not have Jira's breadth: no portfolio or initiative layer, no burndown or velocity dashboards, no Gantt roadmap, no thousand-app marketplace, no cross-department workflow engine. If you genuinely run fifty teams with fifty workflows and a compliance audit suite, Jira is built for that and Radial is not. Better to know before you export than to discover it after.

FAQ

What will replace Jira for my team?

There is no universal replacement, because teams leave Jira for different reasons. If the pain is speed, a fast focused tracker is the fix; if it is data ownership, the self-hosted field (Plane, OpenProject) is real; if it is the bill that keeps moving, you want a tool with one flat price and no AI meter. Pick by the reason you are leaving, not by whichever tool tops a listicle. We sorted the full field in the best Jira alternative depends on what made you leave.

Is Jira being phased out?

No. Jira remains dominant in enterprise, and Atlassian is migrating Data Center customers to cloud rather than retiring the product. What is shifting is narrower: teams that adopted Jira for engineering but never needed its enterprise breadth are increasingly moving to faster, focused trackers. That is a fit problem, not obsolescence.

How do I export my data from Jira?

Jira can export project data to JSON (and individual issue lists to CSV) from its own admin and search-export tooling. Once you have that file, point Radial at it: radial import --from jira export.json --dry-run. The dry run reads the file and reports exactly what it would create without writing anything, so you can confirm the mapping before the real run.

Will I lose my comments and history?

Can my coding agent run the migration?

Yes. The import is available over the REST API (POST /v1/import) with a scoped API key, so an agent you authorize can run the move, or script it across several projects, without a human at the keyboard. Agents are clients of the API, not billed seats, so wiring one up costs nothing extra. Once you are on Radial, your agent files, triages, and closes issues over the MCP server at mcp.radial.build too.

The short version

Moving off Jira is usually gated by the export, not the decision. Radial makes the export the easy part: radial import --from jira brings issues, projects, labels, comments, and history across in one run, and --dry-run shows you the result before you commit. What you migrate into is a fast tracker with one flat locked price, no AI meter, and a pledge that pays you if we ever add one.

See the one number on pricing, or read why is Jira so slow for the engineering reason the weight is not free.

Originally published on the Radial blog.

How to Screenshot an Entire Web Page on Any Device

Nico Acosta — Fri, 03 Jul 2026 11:38:47 +0000

Full-page screenshots are straightforward on desktop but awkward on mobile, and totally different again when you need them from code. This guide covers the real methods for each situation so you can pick the right one.

The quickest cross-device method

If you are writing code, running a CI job, or building a tool that needs to capture pages from a server or agent, a screenshot API is the only method that works everywhere. The browser runs in the cloud, not on your device.

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

Setting full_page: true tells the renderer to scroll to the bottom of the page and stitch all the sections into one image. The response contains a hosted image_url you can write directly to your database or pass to a front end. No browser install, no Puppeteer, no scrolling logic to maintain.

For a broader look at programmatic capture, see how to screenshot a website from a URL.

On desktop: Chrome DevTools

Chrome includes a full-page screenshot command that requires no extensions.

Open DevTools: F12 on Windows or Linux, Cmd + Opt + I on Mac.
Open the command palette: Ctrl + Shift + P on Windows, Cmd + Shift + P on Mac.
Type full size screenshot and press Enter.
Chrome saves a PNG of the full page to your Downloads folder.

The capture uses the same Chromium engine as most screenshot APIs, so the result looks accurate. The limitation is that it only works from a desktop browser and cannot be scripted. For more detail on this method, see how to capture a full-page screenshot in Chrome.

On desktop: Firefox

Firefox exposes its screenshot tool without DevTools.

Right-click anywhere on the page and choose Take Screenshot.
Click Save full page.
Firefox downloads a PNG of the entire scrollable page.

No keyboard shortcuts to remember and no extensions needed. The output is always PNG.

On Mac: Safari

Safari has no native full-page screenshot shortcut. Your options are:

Use Chrome on the same machine (the DevTools method above).
Install a browser extension such as GoFullPage or Nimbus Capture.
Use Cmd + Shift + 4 to capture the visible area, then scroll and repeat (tedious and imprecise).

If Safari is a hard requirement, a browser extension or the API is the path of least resistance.

On Windows: built-in tools

The Windows Snipping Tool (Win + Shift + S) captures the visible viewport only. There is no built-in way to scroll and stitch from the OS level. Use the Chrome DevTools method or a browser extension to get the full page.

On iPhone (iOS)

iOS 13 and later include a built-in full-page screenshot option inside Safari.

Take a regular screenshot: Side button + Volume Up on Face ID iPhones, or Home + Power on older models.
Tap the thumbnail that appears in the lower-left corner.
Tap Full Page at the top of the edit view.
Tap Done and save to Files.

Two things to know: the capture is saved as a PDF, not a PNG or WebP, and this only works in Safari, not Chrome or Firefox on iOS. If you need an actual image file, use a browser extension or the API.

On Android

Android does not have a single universal answer here.

Samsung Galaxy: Take a screenshot normally (Power + Volume Down), then tap Scroll capture in the overlay that appears at the bottom. Samsung stitches the scrolled sections automatically into one image.
Google Pixel and most stock Android: No built-in scrolling screenshot. The closest native option is Share > Print > Save as PDF in Chrome, which has the same PDF limitation as iOS.
All Android browsers: Several extensions for Chrome on Android (such as GoFullPage) add a one-tap full-page screenshot. This is the practical choice on non-Samsung devices.

Choosing the right method

Situation	Best method
Desktop, one-off manual capture	Chrome DevTools
Desktop, Firefox user	Firefox right-click > Save full page
iPhone, one-off	iOS Safari full page (saves as PDF)
Samsung Android	Scroll capture in the screenshot overlay
Other Android	Browser extension
Server, script, or CI	Screenshot API (`full_page: true`)
Mobile device, need an image file	Screenshot API
AI agent or automated workflow	Screenshot API

The pattern that works everywhere and in every format: the API. Native browser tools are fine for manual one-off captures but differ by platform, change with browser updates, and cannot be automated.

Wrapping up

Chrome DevTools and Firefox cover desktop. iOS gives you full pages but only as PDFs in Safari. Android is split: Samsung has scrolling capture built in, everyone else needs an extension. For anything automated, cross-device, or outside a desktop browser, a screenshot API with full_page: true is the consistent answer. Start capturing full pages programmatically with Grabbit's screenshot API.

Originally published on the Grabbit blog.

DEV Community: Nico Acosta

How to Screenshot a List of URLs (Bulk Capture for Research and Audits)

The short answer

Method 1: a browser extension (for a quick one-off)

Method 2: an open-source script (DIY headless)

Method 3: a screenshot API in a loop (repeatable)

Choosing per-URL options

Bulk screenshots for audits and monitoring

Wrapping up

Claude Code Pricing 2026: Pro vs Max vs Team (Updated June)

How Much Does Claude Code Cost? Quick Overview

API Token Pricing

Claude Pro vs Max: Which Plan Should You Choose?

Claude Code Teams and Enterprise: When Do You Need Them?

How to Reduce Claude Code Costs: Practical Efficiency Strategies

Use /clear between tasks

Use /compact to summarize the conversation

Check your usage with /cost

Configure .claudeignore

Model Selection Strategy

The Biggest Token Saver: Spec-Driven Development

Is Claude Code Worth It? The Solo Founder's Decision Framework

Frequently Asked Questions

How much does Claude Code cost?

Is Claude Code free?

What's the difference between Claude Pro and Max?

Why is Claude Code using so many tokens?

How do I reduce Claude Code costs?

Is Claude Code worth it?

Claude Code vs Cursor: which is cheaper?

What are Claude Code rate limits?

Engineering project management without the overhead

What engineering project management actually requires

The overhead is the process, not the tool

Run the work from where you already are

The bill is part of the overhead too

Where this approach is honestly the wrong fit

FAQ

What is engineering project management?

What is the best project management tool for software development?

What are the phases of a software development project?

Do engineers or project managers manage the work?

How do coding agents fit into engineering project management?

The short version

Screenshots for AI Agents: Giving Your LLM Eyes on the Web

Why text-only agents hit a wall

The capture-and-analyze pattern

Capture params that matter for agents

Agentic use cases

Registering the tool in an agent

From agent tool to MCP server

Go further

Cursor Pricing 2026: Free vs Pro vs Ultra — Which Plan?

What Cursor Brings to the Table

Hobby Tier: Starting with Cursor

Pro ($20/month): The Sweet Spot for Most Founders

Pro+ ($60/month) and Ultra ($200/month): For Heavy Users

Team and Enterprise plans

Addons: Bugbot

Further extending Cursor: BrainGrid's spec driven development

Wrapping up

FAQ

How much does Cursor Team cost?

How costly is Cursor?

Is Cursor AI free or paid?

Is Cursor better than Copilot?

Do you need a subscription for Cursor?

Is Cursor's free plan good?

How much do different models cost in Cursor?

How to Take a Website Screenshot in Node.js (4 Ways)

1. Puppeteer (the default)

2. Playwright (cross-browser)

3. capture-website (the short wrapper)

The cost the first three share

4. A hosted API (no browser to run)

Which to use

Ralph Wiggum Plugin for Claude Code: Autonomous Coding Guide

Why "Ralph Wiggum"?

What is the Ralph Wiggum Plugin for Claude Code?

What is an Autonomous Loop in Claude Code?

Use `/clear` between tasks

Use `/compact` to summarize the conversation

Check your usage with `/cost`

Configure `.claudeignore`