DEV Community: GridPort

Your LLM Runs Locally. Your Data Might Not.

GridPort — Tue, 18 Aug 2026 02:48:36 +0000

When sensitive or regulated data enters an LLM workflow, teams often make a quick decision: if it cannot go to a public cloud API, run the model locally.

That may be right. But a local GPU or selected region does not determine the full data path. Prompts may stay local while RAG components, embeddings, logs, backups, or administrative access cross a different boundary.

This field guide helps engineers, security teams, and technical leaders:

Understand why a local model is not necessarily a local data path
Trace data from input through processing, storage, and deletion
Ask for the owners and evidence needed before choosing self-hosting, isolated infrastructure, or a managed service

This article does not recommend a specific vendor and is not legal advice. Requirements vary by jurisdiction, data type, contract, and professional obligation.

Why “local” is not the end of the decision

It often starts with a clear rule. A criminal defense lawyer may decide not to enter client files into a general-purpose cloud AI service before reviewing confidentiality safeguards, contracts, retention, training use, and consent. The American Bar Association’s Formal Opinion 512 does not impose a blanket ban; it requires lawyers to evaluate the tool and protect client information.

An EU-based company may similarly restrict personal data from a US region. But the rule is not simply “US cloud prohibited”: the GDPR allows some transfers under a valid mechanism. The European Data Protection Board’s guidance explains the available routes.

“Regulated data” is not one universal category. Personal data, health information, payment data, privileged communications, export-controlled information, and trade secrets can produce different obligations.

Still, once a team decides that a public API is not acceptable, the next question arrives immediately: what hardware, exactly?

The answers are predictable — a $6K Mac Studio, a pair of used 3090s for $4K, a $16K rack. A legal or contractual constraint gets converted, in a single conversation, into a hardware purchase decision. That conversion happens so quickly that almost nobody stops to ask whether the box actually satisfies the requirement.

It is not just where the GPU sits

Data residency often gets treated as a map problem: pick the region, pick the provider, done. Region is important, but it is only one part of the data flow.

An AI service can have separate locations and policies for model execution, request storage, application logs, traces, abuse monitoring, customer support, backups, and administrative access. This does not mean that every EU inference endpoint sends prompt content elsewhere, or that every form of cross-border access is automatically unlawful. It means that a region selector is not a complete architecture diagram.

The honest version of “where does this run?” has at least seven layers:

Where the model executes
Where prompts, files, and outputs are stored — and for how long
Where embeddings, vector data, and retrieved documents are processed
Where logs, traces, telemetry, and error reports go
Where caches, queues, temporary files, backups, and snapshots live
Which subprocessors receive or can access the data
Who has administrative or support access to any of the above

The places to check are the service-specific data-residency documentation, data processing agreement, subprocessor list, logging configuration, retention policy, and support-access model — not only the marketing page.

The same inspection applies to a self-hosted system. A model can run on a local GPU while an observability SDK exports traces, an embedding call goes to an external API, a vector database is managed in another region, or a crash reporter captures part of a prompt.

“Local model” does not necessarily mean “local data path.”

The description reaches review before the architecture does

Another risk rarely appears in the infrastructure budget: the system may be described to legal, insurance, or procurement reviewers before its operating boundaries are clear.

Consider the phrase “autonomous decision engine.” A reviewer may reasonably hear that as a system making consequential decisions without human approval. The engineering team may only mean a tool that drafts recommendations for a person to review. Those are materially different control models, but a vague description can make them sound identical.

The lesson is not to market around compliance review. It is to describe the system accurately enough that reviewers do not have to infer what it does.

Before the build starts, write one paragraph covering what data enters, what the model produces or decides, what actions it can take, where human approval is required, where data is retained, and what happens when the system is wrong or unavailable.

Have the people who will actually approve the system review it early. Vocabulary is not merely a marketing afterthought here; it is part of the governance surface.

A blanket ban can create a shadow-AI problem

An air-gapped environment can be appropriate for some threat models. But “no cloud APIs” is a policy statement, not by itself a complete security architecture.

If a policy prohibits the available tools without providing a usable alternative, some people may look for another route: a personal account, a browser extension, an unreviewed open-source UI, or a script that bypasses the normal controls.

That does not make the policy unnecessary. It means the control has to include an approved way to complete the work.

The useful framing is not simply “cloud versus local.” It is:

Can people complete the intended task inside the approved boundary, with controls that are visible and supportable?

Open weights do not remove every dependency

It is tempting to assume that open weights settle the dependency question. A provider cannot revoke access to a copy of the weights you already possess, so the system must be independent.

The first sentence may be technically true. The conclusion does not always follow.

MiniMax H3 provides a concrete 2026 example. H3 is a video-generation model rather than a text LLM, but its license illustrates a dependency question that applies to downloadable models across an AI stack. Its community license defines an “Applicable Territory” that excludes the United States, the European Union, the United Kingdom, and the Republic of Korea. The relevant rights are granted only within that territory. The exact terms are in the official MiniMax H3 Community License Agreement, and users in excluded territories can apply for separate authorization.

The important distinction is:

Possessing model weights is not the same as having the legal, technical, and operational ability to deploy them for your use case.

The license is only one dependency. A self-hosted system may still rely on a model repository, tokenizer, container registry, proprietary runtime, update channel, or a small group of staff who know how to operate it. Test whether the deployment can actually be rebuilt without the original provider.

Treat availability as a design input

Managed APIs can become unavailable because of capacity constraints, provider incidents, account problems, policy changes, or regional restrictions. Self-hosted infrastructure has its own failure modes: hardware faults, broken model artifacts, unavailable operators, and delayed security patches.

The relevant question is not “Which option never fails?” It is:

What happens to this workflow when the selected option fails tomorrow?

An acceptable answer may be automatic failover, a second approved provider, a smaller local model, a manual queue, or a documented decision to pause the workflow. The important part is that the answer exists before the outage.

Eight questions to answer before deployment

This is a minimum-viable design review, not a universal statement of legal requirements. Not every team needs every control on day one. The goal is to decide explicitly which controls your data, industry, contracts, and risk level require. The lifecycle approach is consistent with the NIST Generative AI Profile and the UK National Cyber Security Centre’s Guidelines for Secure AI System Development.

What data enters the system? Classify prompts, files, RAG sources, and tool inputs. Define prohibited data and remove unnecessary identifiers where practical.
What leaves the application boundary? Trace inference, embeddings, reranking, moderation, tool calls, observability, and crash reporting — not just the primary model request.
Where does the data persist? Check prompts, outputs, logs, vector stores, caches, queues, temporary files, snapshots, and backups. Set retention deliberately, including whether data can be used for provider training or service improvement.
Who can access or redirect it? Include end users, application operators, provider support, subprocessors, and anyone able to change logging, region, retention, or outbound connections. Use least privilege and managed secrets.
How will you detect and contain a failure? Decide what must be logged, where audit records are exported, who responds to an incident, and how you will detect abnormal access, prompt injection, bulk extraction, or unexpected outbound traffic.
How does deletion actually work? Define retention by data type and verify whether deletion reaches replicas, indexes, backups, snapshots, and derived datasets. Keep production data out of development and evaluation unless explicitly approved.
What evidence proves the design is operating as intended? Keep a current data-flow diagram, configuration records, relevant contracts and license terms, and test results. For important controls, record an owner, evidence, last review date, and accepted residual risk.
What happens if a dependency disappears tomorrow? Plan for provider, region, account, model, operator, or license unavailability. Confirm that essential data and configurations can be exported and that the deployment can be rebuilt or replaced.

Higher-risk environments may need deeper controls for isolation, encryption, supply-chain integrity, patching, recovery testing, and jurisdiction-specific evidence. The eight questions above tell you where that deeper work is needed.

What this does not settle

These questions do not decide whether you should self-host, rent isolated infrastructure, use a private cloud, or choose a compliant managed endpoint. A well-operated managed service can be safer than a poorly maintained local server; an isolated deployment can meet requirements that a shared API cannot. The answer depends on the data, threat model, workload, internal capability, cost, and tolerance for operational responsibility.

The narrower point is this: regulated data is not merely a hardware-buying trigger. Before choosing the box or endpoint, trace the data path, define the operating boundary, identify who can change it, and decide what happens when a dependency fails. That is the design work that prevents an expensive surprise during a review, incident, or outage.

This article was edited with AI assistance, and the cover image was AI-generated. The final content and cited sources were reviewed before publication.

If you have been through a security, privacy, insurance, procurement, or legal review for an AI system, what evidence actually mattered — and what turned out to be noise?

Using PixelRAG with Claude Code (August 2026) — Visual RAG for Documents with Tables and Diagrams

GridPort — Mon, 17 Aug 2026 05:01:56 +0000

PixelRAG is a visual RAG tool that treats web pages, PDFs, and images as screenshots rather than text — preserving the layout of tables and charts so you can search and reference them as-is.

This post covers installing it as a plugin, actual usage, how it differs from traditional text-based RAG, and the gotchas you're likely to hit — all from a Claude Code user's perspective.

What you'll get out of this post

You're an intermediate engineer already using Claude Code for real work
You need to search or understand documents where tables, diagrams, and layout matter
You want to know how this differs from traditional text RAG (embeddings + a vector DB)

What is PixelRAG?

PixelRAG renders documents — web pages, PDFs, images — as screenshots and feeds those images directly to the model. The visual structure that HTML parsing normally destroys — tables, charts, layout, infographics — stays intact, so the model can actually answer questions about them.

PixelRAG is an open-source project built around "Visual Retrieval-Augmented Generation," made up of 5 components:

Component	Role
`pixelrag-render`	Converts documents (web pages, PDFs) into image tiles (via Playwright/CDP)
`pixelrag-embed`	Vectorizes tile images and builds a FAISS index
`pixelrag-index`	Runs the full source → ingest → embed → index pipeline
`pixelrag-serve`	Serves a FAISS search API (CPU/GPU)
`pixelrag-train`	Fine-tunes Qwen3-VL-Embedding via LoRA

These are all now bundled into a single pixelrag package, installable with one pip install pixelrag. As a Claude Code user, the first thing you'll actually touch is the pixelshot command (shipped by pixelrag-render) and the "pixelbrowse" plugin that wires it into Claude Code.

flowchart LR
    A[URL / PDF] --> B["pixelshot<br/>(generates image tiles)"]
    B --> C["tile_0000.jpg ..."]
    C --> D["Claude Code's Read tool"]
    D --> E["Claude understands it visually"]
    C -.->|optional| F[pixelrag-embed / index]
    F --> G[FAISS index]
    G --> H[pixelrag-serve search API]

How this differs from traditional text RAG

Row/column relationships in tables (these tend to break down under text extraction)
The actual content of charts, diagrams, and infographics
Meaning carried by layout itself (emphasis, the position of annotations, etc.)

Setting up PixelRAG

Setup is straightforward: either clone the repo and run it locally, or add the plugin via the marketplace.

Before you start

Python 3.12+ (per requires-python in pyproject.toml)
Claude Code CLI already installed
License: Apache-2.0 (commercial use allowed)
Note: the repo's pyproject.toml includes environments = ["sys_platform == 'linux'"], meaning the GPU-dependent parts (embed/serve/train) assume Linux. This shouldn't matter much if you're only using the screenshot feature (pixelshot), but on Mac/Windows you're safer running it through WSL.
Cost note: the pixelshot screenshot feature just runs Playwright/Chromium locally, so there's no extra cost beyond your normal Claude Code token usage. Building your own index with embed/serve/train, however, needs a GPU, and if you use a cloud GPU for that, you'll pay for that usage separately.

Installation

The official plugin/setup.sh looks like this:

#!/bin/bash
# One-liner that installs pixelrag and registers it as a Claude Code plugin
set -e

# Install pixelrag into an isolated environment via uv
uv tool install --from "$REPO_DIR" pixelrag 2>/dev/null || \
    uv tool upgrade --from "$REPO_DIR" pixelrag

# Install Chromium for screenshots
uvx playwright install chromium 2>/dev/null || true

Option 1: Clone the repo and run it locally

git clone https://github.com/StarTrail-org/PixelRAG.git
cd PixelRAG
./plugin/setup.sh
claude --plugin-dir ./plugin

Option 2: Install via the marketplace

pip install pixelrag                                # installs the pixelshot command
claude plugin marketplace add StarTrail-org/PixelRAG
claude plugin install pixelbrowse@pixelrag-plugins

With the plugin installed, Claude is set up to call pixelshot via Bash and then read the generated images with the Read tool.

Using PixelRAG with Claude Code

Once installed, you just pass a URL in regular conversation and it works.

claude -p "Look at https://news.ycombinator.com and summarize the top stories"

In an interactive session, you can also use the slash command:

claude --plugin-dir ./plugin
# inside the session
/screenshot https://example.com

Under the hood, Claude runs something like the following pixelshot command via Bash:

# Screenshot a URL (tile height optimized to 1568px for Claude's vision model)
pixelshot https://example.com --output /tmp/pixelbrowse --tile-height 1568 --wait-network-idle

# Process multiple URLs in parallel
pixelshot url1 url2 --output /tmp/pixelbrowse --tile-height 1568 --wait-network-idle --workers 4

# Render a PDF
pixelshot document.pdf --output /tmp/pixelbrowse

Output is saved with a naming pattern like /tmp/pixelbrowse/<domain>.png.tiles/tile_0000.jpg, and Claude reads it in as an image to understand the content.

Gotchas, troubleshooting, and where this is useful

The following notes come straight from the official SKILL.md and matter in practice.

Forgetting --wait-network-idle gives you a blank page
Sites that render via JavaScript will get captured before they've finished loading if you skip this flag, leaving you with an empty screenshot. Always include it when targeting a URL.

Stick with the default --tile-height of 1568px
Claude's vision models downscale images whose long edge exceeds 1568px (Sonnet/Haiku) or 2576px (Opus) before processing them. Leave the default at 8192px and the text becomes too compressed to read.

If text is too small to read, crop and re-read it
The official workflow is to crop the relevant region with Pillow and feed it back through the Read tool.

Where PixelRAG is useful

Searching specs, IR documents, and anything else with tables and charts that text extraction tends to mangle
Checking your own site's UI for visual bugs (e.g. "screenshot http://localhost:3000 and tell me if anything looks broken")
Understanding papers or scanned PDFs where layout carries meaning

Wrapping up

PixelRAG specializes in exactly what traditional text RAG struggles with: searching documents while preserving tables, diagrams, and layout.

Wiring it into Claude Code doesn't require an MCP server at all — it's a skill-only setup that comes down to a single pixelshot command. Before using it in production, check the official repo for the latest status.

Official repo: https://github.com/StarTrail-org/PixelRAG
Official site: https://pixelrag.ai
Plugin-only README: https://github.com/StarTrail-org/PixelRAG/blob/main/plugin/README.md

📌 This post reflects information as of August 2026. Since Claude Code updates frequently, check the official docs for the latest specifics.

This article was edited with AI assistance.
*Originally published in Japanese on EdgeHUB.

Building a Custom MCP Server for Claude Code — A Fortune-Telling Tool with FastMCP

GridPort — Thu, 13 Aug 2026 15:04:18 +0000

"MCP servers sound complicated" — if that's your reaction, FastMCP might change your mind. It handles almost all the plumbing for you. Add one decorator to a plain Python function, and you've got a custom tool Claude Code can call.

In this post, we'll build a small fortune-telling tool as a learning exercise, and walk through what FastMCP is actually doing for you along the way.

What is MCP, anyway?

MCP (Model Context Protocol) is a common standard for giving AI models like Claude "external tools" to work with.

An AI model itself is great at generating text, but on its own it can't do concrete things like "tell today's fortune based on the date" or "query an internal database."

That's where an MCP server comes in: you register callable tools on it, and Claude Code invokes them whenever it needs to.

Hand-writing an MCP server from scratch is a fair amount of work, but with FastMCP you can build a working fortune-telling tool that Claude Code can call in just a few dozen lines of code.

Why FastMCP makes this easy

Normally, an MCP server has to implement a lot of low-level protocol details — what message format to use, how to advertise the list of available tools, and so on. FastMCP takes care of all that "plumbing" for you.

All you do as a developer is write a normal Python function and mark it with @mcp.tool. FastMCP inspects the function's argument types and return type to auto-generate the schema (the "instruction manual") that gets handed to the AI. Since none of the transport or protocol details are something you need to think about, anyone who's written a basic web app can have their first tool running in a few minutes.

Note on decorator syntax: the standalone fastmcp package (what we're using here) accepts a bare @mcp.tool, no parentheses needed. If you're instead using the MCPServer bundled with the official mcp Python SDK, the decorator requires parentheses: @mcp.tool(). Mixing the two up is a common source of confusing errors, so if you copy code from a different MCP tutorial, double-check which package it's using.

Setting up the Python environment

You'll need Python 3.10 or later.

python --version

If it's not installed, grab it from python.org.

Then create and activate a virtual environment:

# macOS / Linux
python -m venv venv
source venv/bin/activate

# Windows
python -m venv venv
venv\Scripts\activate.bat

Once activated, you should see (venv) at the start of your prompt.

Install FastMCP:

pip install fastmcp

That's it — no database, no config files.

Building the fortune-telling tool

Create a project folder and, inside it, a server.py file with the following:

import random
from datetime import date
from fastmcp import FastMCP

# Create the server ("uranai" is Japanese for "fortune-telling" — the name of this tool group)
mcp = FastMCP("uranai")

@mcp.tool
def fortune(name: str, birthday: str = "") -> str:
    """Tells today's fortune based on a name (and optionally a birthday)."""
    # Seed the RNG with name + birthday + today's date, so the result
    # stays the same for a given person on a given day, but changes daily.
    seed = f"{name}|{birthday}|{date.today().isoformat()}"
    rng = random.Random(seed)

    levels = ["Great luck", "Good luck", "Modest luck", "Luck", "Fading luck", "Bad luck"]
    items = ["reading a book", "taking a walk", "coffee", "sleeping early", "a new app", "cleaning"]
    colors = ["red", "blue", "green", "yellow", "white", "purple"]

    return (
        f"Today's fortune for {name}\n"
        f"Fortune: {rng.choice(levels)}\n"
        f"Lucky activity: {rng.choice(items)}\n"
        f"Lucky color: {rng.choice(colors)}\n"
        f"Lucky number: {rng.randint(1, 49)}"
    )

if __name__ == "__main__":
    mcp.run()

Three things matter here:

FastMCP("uranai") creates the server instance.
Adding @mcp.tool to the function is all it takes to turn it into something Claude can call.
The docstring (the """...""" part) is what the AI reads to decide when to use this tool — write it clearly.

The trick worth noting is seeding the random number generator with today's date. That gives you fortune-telling-app behavior for free: the same person gets the same result if asked again on the same day, and a different result the next day.

Starting the server

From the project directory, run:

python server.py

If it starts without errors, you're ready to connect it to Claude Code.

Connecting to Claude Code

If you don't have the Claude Code CLI installed yet, install it first — see the official installation docs for your platform (macOS, Linux, or Windows).

Then register the server:

claude mcp add uranai -- python /path/to/server.py

Replace /path/to/server.py with the actual path (if you're using a virtual environment, point to that environment's Python executable to be safe).

Restart or reload Claude Code, and the uranai server should be recognized. You can check connection status with the /mcp command.

If you're using the Claude desktop app instead, add this to your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "uranai": {
      "command": "/path/to/venv/bin/python",
      "args": ["/path/to/uranai/server.py"]
    }
  }
}

(On Windows, command would instead point to something like C:\\Users\\yourname\\uranai\\venv\\Scripts\\python.exe.)

Try it out

Open Claude Code, ask it for your fortune, and approve the tool call when prompted. You should get back a fortune generated by your own tool.

Ideas for taking it further

Once the basics work, adding more tools is just a matter of writing another function and decorating it with @mcp.tool:

Tarot / omikuji mode: expand the pool of results and messages for more variety.
Zodiac-based fortunes: parse the birthday into a zodiac sign and tailor results accordingly.
External API integration: pull in weather or calendar data to add some real-world flavor.
Persisting results: log fortune history to a file or database.

If things get heavier — image generation, larger-scale analysis — you don't have to run this on your laptop. You could offload the compute to a GPU cloud instance and expose the MCP server from there instead.

Wrapping up

With FastMCP, building an MCP server comes down to "write a Python function, add @mcp.tool." We walked through the whole loop here — environment setup, writing the tool, connecting it to Claude Code, and confirming it works — using a fortune-telling tool as the example.

The same pattern scales to far more useful things: wrapping internal tools, automating repetitive tasks, and more. Fortune-telling is just the toy example — try swapping in your own idea next.

📌 This post reflects Claude Code's behavior as of June 2026. Since Claude Code updates frequently, check the official docs for the latest details.

This article was edited with AI assistance.
*Originally published in Japanese on EdgeHUB.

6 Claude Code Skills You Should Actually Install (2026 Edition)

GridPort — Mon, 10 Aug 2026 04:58:48 +0000

Claude Code now has dozens of skills and plugins available, both official and community-built. Installing them indiscriminately backfires: when several skills cover the same territory, Claude has to guess which one to use, and that guesswork shows up as unpredictable behavior.

Based on what's available as of July 2026, this post narrows the field down to 6 skills that actually move the needle in day-to-day work, along with the selection criteria behind the picks and the install commands. It also covers what to watch for when rolling these out to a team.

The 6 skills at a glance

A typical dev cycle runs design → implementation → review → security → testing, then loops back to design. Each of the 6 skills below maps to one of these phases.

flowchart LR
    A[Design<br/>skill-creator] --> B[Implementation UI<br/>frontend-design]
    B --> C[Review<br/>code-review]
    C --> D[Security<br/>security-guidance]
    D --> E[Testing<br/>playwright]
    E --> A

Skill	Phase	What it does
superpowers	Development discipline	Forces steps like "clarify requirements before writing code" and "identify root cause before fixing a bug"
skill-creator	Design (meta: builds skills)	Walks you through a Q&A to generate a custom SKILL.md for your own workflows
frontend-design	Implementation (UI)	Generates frontends with a deliberate aesthetic direction instead of generic "AI-looking" UI
security-guidance	Security	Detects roughly 25 vulnerability patterns in real time on every edit
playwright	Testing	Drives a browser to run E2E tests and verify behavior
discord	Notifications / remote control	Sends run notifications and lets you operate Claude Code remotely from your phone

Three criteria guided this selection:

Keep exactly one skill per phase.
Installing multiple skills that cover the same phase makes Claude hesitate over which one to invoke, which leads to unpredictable behavior.

Prefer official or well-established plugins.
A SKILL.md someone wrote as a side project is riskier to depend on than something maintained by Anthropic or widely used across the ecosystem (high weekly install counts, for example) — the latter is more likely to keep being maintained.

Start with these 6, add more only when you actually need to.
Add anything beyond this baseline only once you hit a task you find yourself repeating almost identically every time. Things like test generation, changelog formatting, or company-specific checklists are worth building yourself with skill-creator — but only after you've used the core 6 enough to know exactly what you need.

The 6 skills in detail

1. superpowers (enforces development discipline)

What it does: Claude Code tends to jump straight into implementation, skipping requirements clarification and root-cause analysis. Superpowers forces steps like "clarify requirements before adding a feature" and "identify the root cause before fixing a bug." Built by developer Jesse Vincent, it was added to the official plugin marketplace in January 2026.

Install

/plugin install superpowers@claude-plugins-official

Usage: No special invocation is needed after install — just ask Claude to implement something as usual, and it will automatically walk through clarify requirements → design → implement → test. If you only want a specific phase, like brainstorming or test-driven development, you can call the relevant sub-skill directly, e.g. /superpowers:brainstorming.

2. skill-creator (a skill for building skills)

What it does: Walks you through an interactive Q&A to build a SKILL.md tailored to your own team's workflows. This is an official Anthropic plugin, and one of the most widely used skills in the ecosystem.

Install

/plugin install skill-creator@claude-plugins-official

Usage: Typing /skill-creator starts an interactive Q&A. Answer questions about the goal of the skill you want, expected inputs, and expected outputs, and it generates a SKILL.md template. Save it under .claude/skills/, then call it with /skill-name to test and refine it. It's best to build one skill per purpose — e.g., a standardized meeting-notes format or a code review checklist — rather than one catch-all skill.

3. frontend-design (frontend UI generation)

What it does: Instead of generic "AI-looking" defaults, this generates UI with a deliberate aesthetic — brutalism, glassmorphism, and so on. It's an official Anthropic skill with a large install base.

Install

/plugin install frontend-design@claude-plugins-official

Usage: When asking for UI, be explicit about both the skill and the style you want — e.g., "Using the frontend-design skill, build an admin dashboard with a brutalist aesthetic." Follow-up nudges like "make it more monochrome" or "give it more whitespace" refine the result while keeping the original direction.

4. security-guidance (security scanning)

What it does: On every code edit, it scans for roughly 25 vulnerability patterns — injection, unsafe deserialization, dangerous DOM API usage, and more — using regex-based real-time detection. It also layers in an LLM-based diff review at the end of each turn and a cross-file review at commit time, for a three-tier check. This is a free, official Anthropic plugin.

Install

/plugin install security-guidance@claude-plugins-official

Usage: No explicit invocation is needed — a background scan runs automatically on every edit. When it flags a vulnerability, it proposes a fix on the spot, which you can review and choose to apply. If you'd rather batch a review before committing, you can also ask it to actively review a specific scope of changes.

5. playwright (browser automation)

What it does: Drives a browser to handle navigation, form input, screenshots, and console log inspection. There are two ways to install it: Microsoft's official Playwright MCP, or a CLI+Skill setup (playwright-cli install --skills) that's more token-efficient.

Install

# MCP approach
claude mcp add playwright

# CLI+Skill approach
playwright-cli install --skills

Usage: With the MCP approach, register it with claude mcp add playwright, then ask Claude to test something like a login form — it will drive the browser and return screenshots and results. With the CLI+Skill approach, call /playwright after install and specify the test scenario step by step.

6. Discord (notifications / remote control)

What it does: Sends Claude Code's run results to Discord, and lets you pair with a bot via DM to remotely generate code or manipulate files from your phone. It combines an MCP server with Agent Skills.

Install

/plugin install discord@claude-plugins-official

Usage: After installing, DM the bot on Discord and it replies with a pairing code. Enter that code in Claude Code to complete the link. From there, the /discord command handles run notifications and lets you remotely generate code or manipulate files via Discord.

Rolling this out to a team

Commit skills to the project-level .claude/skills/ directory rather than your personal home directory (~/.claude/skills/), so the whole team shares the same 6 skills.

For production repos where you want to avoid Claude auto-triggering a skill at an unintended moment, set disable-model-invocation: true in the SKILL.md frontmatter. This disables Claude's automatic invocation from conversational context, restricting it to explicit /skill-name calls only.

security-guidance is designed with the assumption that it will produce some false positives, so it's worth agreeing as a team on how much to trust its findings. Discord involves managing bot tokens and notification channels, so decide in advance who's allowed to notify or operate through which channel. It's also worth restricting which marketplaces are allowed for installs — official (claude-plugins-official) or internally vetted ones only.

Wrapping up

Once these 6 skills cover discipline, design, implementation, security, testing, and notifications, the next step is to use skill-creator to turn your own team's repeated workflows into SKILL.md files.

The generic skills above won't catch your company's specific review standards or release process — and that's exactly where building your own skills pays off the most.

For more on how skills work under the hood, see the official Claude Code docs.

📌 This post reflects information as of July 2026. Claude Code updates frequently, so check the official docs for the latest specifics.

This article was edited with AI assistance.
*Originally published in Japanese on EdgeHUB.

How to Run MiniMax H3 on 16GB VRAM with ComfyUI

GridPort — Thu, 06 Aug 2026 03:09:48 +0000

On August 3, 2026, MiniMax H3 was released with open weights, and ComfyUI shipped native support for it on the same day.

It's a next-generation model that handles text, images, and audio together, generating video with stereo audio — but there are some practical caveats that official blog posts and early reviews haven't covered much: the resolution ceiling for local runs, and regional restrictions in the commercial license.

This article covers setup on ComfyUI 0.30.0+, model selection by VRAM, how to use the three workflows (T2V/I2V/R2V), and licensing caveats, as of August 2026.

In my testing, the pruned INT8 diffusion model combined with the NVFP4 AWQ text encoder allowed MiniMax H3 to run on a GPU with 16GB of VRAM. Depending on your environment, you may still need to adjust settings such as resolution and video duration.

What is MiniMax H3?

MiniMax H3 is a video generation model released with open weights by China's MiniMax on August 3, 2026.

It's the third generation of the Hailuo series, and the first model the company has released weights for. ComfyUI added native support on release day.

Key specs:

Model architecture: 33.1B-parameter single-stream omni transformer (about 13B of that is in AdaLN-modulation branches, which don't need to be loaded for inference-only use)
Text encoder: Qwen3-VL-32B
Output: up to 15 seconds, 24fps, with stereo audio
Supported tasks: Text-to-Video (T2V), Image-to-Video (I2V, with start/end frame specification), Reference-to-Video (R2V)
Supported languages: 11 languages, including Japanese
Checkpoints: two families — FL2VA (handles T2V/I2V) and Ref2VA (handles reference-driven R2V)

Getting Started with MiniMax H3 in ComfyUI

Here's how to get MiniMax H3 running locally in ComfyUI, from setup through generation.

Step 1: Update ComfyUI to the latest version

Launch ComfyUI and update to the latest version before proceeding. Once the update finishes, move on to installing the model data.

Step 2: Get the model data

Next, download the model data needed for video generation.

The model is distributed via the Comfy-Org/MiniMax-H3 repository on Hugging Face. MiniMax's official repo (MiniMaxAI/MiniMax-H3) contains every precision and format, weighing in at around 498GB — but if you only download the files ComfyUI actually needs, it's more like a few dozen GB.

You need three pieces of model data for video generation:

Video model data
Text encoder
VAE

Once you load the workflow, a list of required downloads appears. Download them in order, or use these commands to grab everything at once:

# Video model data
cd ComfyUI/models/diffusion_models
wget https://huggingface.co/Comfy-Org/MiniMax-H3/resolve/main/diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors

# Text encoder
cd ComfyUI/models/text_encoders
wget https://huggingface.co/Comfy-Org/MiniMax-H3/resolve/main/text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors

# VAE
cd ComfyUI/models/vae
wget https://huggingface.co/Comfy-Org/MiniMax-H3/resolve/main/vae/minimax_h3_audio_vae_fp32.safetensors
wget https://huggingface.co/Comfy-Org/MiniMax-H3/resolve/main/vae/minimax_h3_video_vae_fp16.safetensors

Step 3: Launch ComfyUI and open the workflow

This guide uses the official combined workflow.

Download the official workflow from Comfy's docs.

(Source: docs.comfy.org)

Drag and drop the downloaded workflow file into the ComfyUI canvas, then confirm the nodes have loaded correctly.

Step 4: Enter a prompt and start generation (T2V)

MiniMax H3's text-to-video mode can produce high-quality video from a fairly simple prompt.

Write your scene description in natural language in the prompt field, then click the "▷Queue" button to start generation.

Video generated with MiniMax H3 (ComfyUI):

Prompt used:

Emotional anime character film. The girl from Picture 1 in her original scene: a warm sunlit wooden hallway indoors, lit by dramatic warm golden backlight and soft ambient fill, deep soft shadow falloff into rich amber tones. Warm monochromatic palette with golden light and soft blue accents from her eyes. Emotional motif: a desperately reaching hand and a single falling tear. The environment is constant throughout.

SHOT 1: The scene opens exactly on Picture 1, the girl reaching desperately toward the camera; her eyes well with tears as the golden backlight pulses slightly brighter, dust motes drifting past as the camera executes a slow, deliberate push-in on her straining fingers and glistening eyes.

SHOT 2: Cut to an extreme close-up profile as her tear finally spills down her flushed cheek; the camera glides slowly alongside her face as loose strands of hair sweep across in the warm draft, her collar and necktie trembling faintly.

SHOT 3: Cut to a low, tilted wide shot: she loses her balance and tips forward, her twin tails sweeping wildly, the retreating figure's footstep fading further out of frame; the warm light flares gently along her damp eyes before the frame settles into a soft freeze as her hand falls just short.

Audio: soft ambient room tone, a trembling desperate breath, rustling fabric and a faint hair ornament chime, receding footsteps on wood, and a swelling emotional piano-and-strings score that resolves to a hushed, breathless quiet on the final beat.

Step 5: Generate video from an image (I2V)

MiniMax H3 can also generate video using a single reference image.

The workflow is available on the same official workflow page.

Structure your prompt by shot (SHOT 1–3), then click "▷Queue" to start generation.

Video generated with I2V:

Common Errors and Fixes

MiniMax H3 nodes don't show up in ComfyUI
Your ComfyUI version is older than 0.30.0. Update to the latest version. Note that Desktop and Cloud versions track stable releases, so the update may lag behind.

Running out of VRAM / high memory usage
Use pruned int8 instead of bf16 for the diffusion model, and nvfp4 AWQ for the text encoder. If it's still tight, lower the megapixel count in the Resolution Selector or shorten the duration.

Generation fails at low resolutions like 256p
MiniMax H3's minimum resolution is 384p. Anything at or below 256p will fail — pick from the resolution presets in the template instead.

No audio in the output video
Check that both minimax_h3_video_vae_fp16.safetensors (video) and minimax_h3_audio_vae_fp32.safetensors (audio) are loaded, and that the VAEDecodeAudio node is connected to the SaveVideo node.

Not sure which checkpoint to use for I2V
Use the FL2VA family for T2V and I2V (including start/end frame specification), and the Ref2VA family for reference-driven R2V. These are separate weights — the workflow won't function correctly if you mix them up.

MiniMax H3 Licensing and Commercial Use

MiniMax H3 is released under a custom license called the "MiniMax H3 Community License."

The main terms confirmed at the time of writing are as follows:

Item	Details
Applicable Territory	Available worldwide, except for "Excluded Territories": the EU, UK, South Korea, and the US
Japan	Not listed as an Excluded Territory. Under the current license, both use and commercial use within Japan appear to be within scope
Commercial use	Permitted free of charge, but the "MiniMax H3" attribution must be displayed in the commercial product's UI
Revenue threshold	If annual revenue exceeds $20 million, separate written permission from MiniMax is required
Other	Using outputs to improve other AI models (e.g. distillation) is prohibited. Redistribution requires marking modified files and including a NOTICE file
Governing law	Hong Kong SAR law

(Information as of August 2026.)

This regional-restriction clause has been a talking point on overseas technical blogs covering MiniMax H3.
If you're planning to integrate it into a commercial service, check the original license text (the LICENSE file on Hugging Face) with your legal team before making a decision.

Nothing in this article constitutes legal advice.

MiniMax H3/LICENSE: https://huggingface.co/MiniMaxAI/MiniMax-H3/blob/main/LICENSE

Wrapping Up

This covered how to use MiniMax H3, the latest release in open video generation models.

It's one of the most capable open-weight video generation models currently available, and it's well worth exploring while it's still fresh.

This article was edited with AI assistance.
*Originally published in Japanese on EdgeHUB.

I Reviewed 100 Reddit Threads About GPU Clouds. Price Was Only Part of the Story.

GridPort — Tue, 04 Aug 2026 11:07:58 +0000

When engineers compare GPU clouds, the conversation usually starts with three familiar numbers:

GPU model
VRAM
Hourly price

Those numbers matter.

But they do not always tell us whether a workload will actually finish efficiently.

A cheap GPU can become expensive when a failed job has to be repeated. A more powerful GPU can still produce a slower workflow when storage, system RAM, model loading, or data transfer becomes the bottleneck.

To understand what engineers actually care about, we reviewed 100 unique Reddit threads about GPU infrastructure decisions published between January 2025 and July 2026.

The discussions covered:

Model training and fine-tuning
LLM inference
ComfyUI and image generation
Private LLM deployments
Managed APIs
Rented GPU instances
Local hardware

The most surprising result was this:

Price was the primary pain point in 23 of the 100 threads. However, in 74 threads, cost was not the primary decision criterion.

Price was important, but it was only the beginning of the decision.

Here are three patterns that stood out.

1. The Cheapest GPU Can Produce an Expensive Workflow

Hourly pricing is easy to compare.

The cost of completing a workload is much harder.

The real cost may also include:

Failed runs
Repeated environment setup
Persistent storage
Idle instances
Data transfer
Engineering time
Troubleshooting and recovery work

In one discussion, a user tried multiple low-cost marketplace instances for a fine-tuning job.

Crashes, failed downloads, and unusable environments consumed both time and budget without completing the intended work.

Other users described the opposite decision. They continued paying more for a managed platform because its templates and simpler setup saved enough time to justify the higher hourly rate.

The relevant unit is therefore not always the GPU hour.

It may be the completed workload.

2. A Faster GPU Does Not Guarantee a Faster Workflow

A workload does not run on a GPU specification alone.

It runs on a complete system.

In one discussion, a cloud RTX 5090 produced a slower end-to-end image-generation workflow than a local RTX 5070 Ti.

The cloud GPU was more powerful, but several models had to be loaded repeatedly during the workflow.

Other discussions showed that having enough VRAM did not always mean that a workload would run successfully.

Performance and compatibility could also depend on:

System RAM
Storage throughput
Model-loading behavior
Network transfer
CPU performance
Container restrictions
Regional host configuration
Software compatibility

The best GPU on paper is not necessarily the best environment for the actual job.

3. Engineers Choose Environments, Not Just GPUs

GPU clouds are also working environments.

They must be:

Configured
Stopped
Restarted
Preserved
Monitored
Reproduced
Recovered

One developer described repeatedly spending around 30 minutes comparing providers, connecting through SSH, and installing tools before testing a model.

Forgotten instances also created billing risk.

Another user destroyed instances after every session to avoid ongoing storage charges. However, destroying the instance also removed the configured environment, creating additional work to preserve and restore progress.

This is why operational questions often become important:

Can compute stop without deleting the workspace?
Are storage charges easy to understand?
Can checkpoints survive a restart?
Can the environment be reproduced?
Can a failed job resume?
Can instances terminate automatically?
How much setup is required for each session?

A platform does not need to eliminate all operational work.

The important question is whether that work matches the team’s skills, time, and operating model.

Four Types of Fit

The discussions became easier to understand when we grouped GPU infrastructure decisions into four types of fit.

Economic Fit

Does the total cost match the usage pattern?

This includes compute, storage, idle time, failed runs, setup, and recovery work.

Workload Fit

Can the complete workload run effectively?

This includes the GPU, VRAM, system RAM, storage, network, interconnects, and software environment.

Operational Fit

Can the user operate and restore the environment?

This includes setup, billing visibility, stop-and-restart behavior, checkpoints, automation, and reproducibility.

Risk Fit

Are the remaining risks acceptable?

This includes reliability, capacity availability, data handling, region, vendor lock-in, support, and runtime control.

A provider can look attractive on one dimension and still be a poor fit on another.

Three Questions to Ask Before Comparing Providers

Before opening a GPU pricing table, it may help to answer three questions.

What must work?

Define the complete workload, not only the GPU.

Include system memory, storage, software, data transfer, latency, concurrency, and scale.

What must survive?

Decide which datasets, checkpoints, models, containers, and configured environments must remain recoverable after compute stops or a host disappears.

What must never happen?

Identify the unacceptable outcome.

That might be:

Runaway cost
Lost training progress
Unavailable capacity
Data exposure
Vendor lock-in
Insufficient runtime control

These questions will not identify one universal winner.

They will identify the trade-offs that actually matter for the workload.

The Main Takeaway

The 100 discussions did not point to one best GPU cloud.

They showed that AI engineers are not simply selecting a machine.

They are choosing a combination of:

Cost
Workload capability
Operational burden
Risk

The better question may therefore be:

Which environment lets me finish this workload at a cost, operational burden, and level of risk I can accept?

What matters most in your own GPU infrastructure decisions after hourly price?

Storage, availability, setup time, system RAM, stop-and-restart behavior, privacy—or something else?

This article is a condensed adaptation of our full research report, which includes the research methodology and representative source discussions:

https://lp-soroban.highreso.jp/compute-cluster/blog/gpu-cloud-research-001.html?utm_source=devto

This article was edited with AI assistance. The research data, analysis, examples, and conclusions were reviewed by the author.