DEV Community: GridPort

Claude Code's ELI5 Skill Explained: How It Works, Setup, and When to Use It

GridPort — Tue, 25 Aug 2026 04:50:28 +0000

This article reflects Claude Code's spec as of August 2026. Since Claude Code updates frequently, check the official docs for the latest behavior.

Type /eli5 <topic> into Claude Code, and the ELI5 skill generates a jargon-free, diagram-heavy HTML explainer on the spot.

It went viral in August 2026 after Anthropic's own dev team mentioned they use it internally.

This post covers how ELI5 works, how to install it, what happened when we pointed it at one of our own technical topics, and what to watch out for before using it at work.

What is the ELI5 skill?

"ELI5" stands for "Explain Like I'm 5." Type /eli5 <topic> in Claude Code, and it produces a single HTML artifact (Claude's panel-style output format) aimed at someone with zero background on the topic, built from big visuals and minimal text.

Unlike a normal chat reply, which tends to come back as a wall of text, the output is locked to three constraints:

Output format: not a chat reply, but a single standalone HTML artifact
Information density: "few words." It's built to avoid long explanations.
Mode of expression: "big pictures." Structure gets shown visually instead of described in prose.

The skill was published by Thariq Shihipar of the Claude Code team, who introduced it on X on August 21, 2026 as "a skill people at Anthropic have been using a lot lately." It's distributed through the community marketplace anthropics/claude-plugins-community.

Why does the actual behavior differ from "explain to a 5-year-old"?

Looking at ELI5's SKILL.md, there's a mismatch between the description field, which controls when the skill triggers, and the body text, which actually shapes the output:

---
name: eli5
description: Explain a topic like I'm a 5 year old. Use when the user types /eli5 <topic> or asks for a dead-simple picture explainer of how something works.
---

# eli5

Explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words.

Topic: $ARGUMENTS

The description still says "like a 5-year-old," but the body, the part that actually drives the model, has been changed to "someone who knows nothing about this topic."

That's a deliberate choice: literally targeting a 5-year-old's vocabulary tends to tank explanation accuracy, so the body is tuned instead toward "strip out assumed background knowledge" rather than "talk like you're speaking to a child."

Installing and using ELI5

You can install ELI5 through Claude Code's plugin system in two commands. The plugin itself is distributed free under the MIT license (Claude Code usage still follows your existing plan's pricing).

# 1. Add the community marketplace
claude plugin marketplace add anthropics/claude-plugins-community

# 2. Install eli5 (specify the marketplace after @)
claude plugin install eli5@claude-community

Check that it installed correctly:

claude plugin list

eli5@claude-community
Version: 1.0.0
Scope: user
Status: enabled

Basic usage

Just follow /eli5 with whatever you want explained:

/eli5 how does RAG actually work
/eli5 how does auth work in this project
/eli5 why is the sky blue

Left to its own devices it sometimes generates fewer diagrams than you'd like. If you want it to lean harder into visuals, adding an explicit condition like "include at least 3 SVG diagrams" makes the output more consistent.

Trying it on RAG

We asked ELI5 to explain RAG (retrieval-augmented generation) to see what the output actually looks like.

Prompt used:

/eli5 Explain how RAG works in a simple way. Don't just use text —
include at least 3 SVG diagrams. Show the flow of gather documents →
split them → search → generate an answer as a flowchart with arrows.

The recreated output boiled the process down to four steps: gather documents, chop them into small pieces, find similar chunks, read and answer. It used emoji and short phrases to fit everything on one screen:

📚 Gather documents: collect all the internal docs and PDFs
✂️ Split into chunks: break long documents into readable pieces
🔍 Find similar chunks: pick only the chunks close to the question's meaning
✍️ Read and answer: the AI reads the selected chunks and writes an answer

Bottom line: question → find documents → read and answer. That's it.

This is meant as an entry point for grasping what the mechanism even is, not a technically precise spec.

Using ELI5 at work: what to keep in mind

ELI5 is designed to optimize for "gets the idea across" over "is precisely correct." Keep these three things in mind when using it for actual work.

Where ELI5 shines

Explaining to non-engineers: turn how an AI system works into a single shareable slide for internal proposals or client materials
Onboarding: give new team members a visual first pass at how auth flows or module structure work before they dig into code
Incident retrospectives: lay out where a problem started, what it touched, and what ultimately happened, in chronological order
Checking your own understanding: if you can't turn something into a diagram, that's usually the part you don't actually understand yet

Where ELI5 falls short

Because it optimizes for ease of understanding, it's not a good fit for:

Verifying exact specs, numbers, or conditional branches
Checking edge cases and boundary conditions
Auditing security issues
Actually fixing code

For that kind of work, use ELI5 to get the big picture first, then switch to normal Claude Code instructions or official documentation to nail down the details.

Try it yourself

Start with something simple like /eli5 why is the sky blue and see how different the output feels from a normal chat response.

It's also a quick way to turn trending technical terms into a shareable visual explainer. Worth keeping in your toolkit.

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

Stop Comparing GPU Clouds Only by $/hour

GridPort — Mon, 24 Aug 2026 01:43:07 +0000

GPU Cloud Research · #002 — 11 min read

The cheapest GPU instance is not always the cheapest way to finish a workload.

GPU cloud comparison pages usually begin with the same number:

How much does this GPU cost per hour?

It is a useful number. But it is rarely the full cost.

A low hourly rate can quickly lose its advantage when a user spends an hour configuring an environment, reruns a failed job, downloads the same model again, pays for storage while no GPU is running, or waits for a compatible GPU to become available in the region where the data is stored.

The more useful question is not: which GPU has the lowest hourly price? It is: how much will it cost to complete this workload successfully?

For this article, GPU Cloud Research reviewed a database of 131 unique Reddit threads posted since January 2025 and selected 80 evidence units related to GPU cloud costs.

The cases show that the practical cost of GPU infrastructure includes much more than compute.

Total workload cost may include:

GPU compute
Environment setup
Failed runs and retries
Persistent storage
Data transfer
Idle or stopped-instance charges
Model loading and initialization
GPU availability
Network and storage performance
Engineering and operational labor
Model quality
Workflow restrictions

Once these factors are included, the cheapest GPU by the hour may no longer be the cheapest option.

1. Cheap GPU capacity can become expensive

Marketplace-style GPU clouds can offer attractive hourly rates. For flexible experiments and price-sensitive workloads, that can be valuable.

The problem begins when the low price is offset by unreliable execution or repeated operational work.

In one case, a fine-tuning user reported trying multiple lower-priced GPU instances but encountering repeated failures and troubleshooting. The user eventually began looking for alternatives because the failed runs outweighed the hourly savings. [1]

Another user completed three hours of LoRA training, but could not retrieve the output at a usable speed. The GPU computation had finished, but the actual workload had not: the trained files still needed to be downloaded. [2]

A separate commenter reported losing roughly $5–$7 in one day due to migration work, unavailable GPU capacity, and repeated downloads. [3]

Other users described model downloads consuming close to an hour of billable time, instances hanging or crashing, and recurring deployment work taking one to two hours. [4][5]

These are individual experiences, not platform-wide reliability measurements. However, they reveal a common cost pattern:

A low hourly rate has little value if the workload must be restarted, repaired, or manually rebuilt.

The relevant metric is not the cost of one GPU-hour. It is the cost of one successfully completed training run, generated video, benchmark, or inference job.

2. Compute is only one billing meter

GPU pricing is highly visible. Storage and data movement are often less visible until a workload is already running.

One user ran an RTX 5090 instance for approximately ten minutes and then downloaded around 23GB of data. The reported data-transfer charge exceeded the cost of the GPU session itself. [6]

Storage can create a different tradeoff.

Persistent storage preserves models, environments, checkpoints, and outputs between sessions. But for infrequent users, the monthly storage charge may exceed the cost of the occasional GPU usage.

A daily user with a workspace below roughly 200GB concluded that rebuilding the environment with a ten-minute installation script was preferable to paying for a region-locked network volume. [7]

Another user repeatedly destroyed GPU instances to avoid storage charges, but then had to solve the problem of moving environments and preserving state between sessions. [8]

The opposite decision can also be expensive. A user who relied on temporary storage lost training data and checkpoints after an instance ended. [9]

Storage also has little value if the stored workspace is tied to a region where compatible GPUs are unavailable. Users have reported paying to retain a workspace while being unable to start the GPU they needed in that region. [10]

Storage should therefore not be evaluated as a separate price line. Its value depends on:

How often the environment is reused
How long rebuilding takes
How much data must be downloaded again
Whether storage can move across regions
Whether compatible GPUs are consistently available
How costly it would be to lose a checkpoint

Sometimes persistent storage lowers total cost. Sometimes automation and reconstruction are cheaper. The correct answer depends on the workload.

3. A more expensive service may cost less overall

A higher hourly price does not automatically mean higher total cost.

Users may rationally pay more for templates, faster onboarding, managed environments, reliable storage, or easier operations.

In one discussion, users described paying more for a provider because LoRA training and video-generation environments were nearly ready to use. A cheaper marketplace was reportedly available, but some users continued choosing the more expensive option because the setup experience saved time and effort. [11]

Another user became tired of spending around 30 minutes comparing providers, connecting through SSH, and installing vLLM or Ollama for every experiment. The user eventually built a command-line tool to automate the process and reduce the risk of forgetting to terminate instances. [12]

This operational time is often excluded from GPU cost calculations. But engineering time is not free.

A service that costs more per GPU-hour may still be cheaper when it reduces:

Setup time
Deployment work
Failed runs
Incident investigation
Environment reconstruction
Billing mistakes
Employee interruptions

This does not mean premium providers are always cheaper. It means the price of human labor should be included in the comparison.

4. Compare cost per completed output, not cost per hour

Even when two instances run without failure, their hourly rates still do not reveal which one is more economical.

The GPU must fit the workload. A faster GPU can lose its advantage if model loading, storage I/O, CPU performance, or network communication becomes the bottleneck.

One user reported that cloud RTX 5090 instances required approximately ten minutes to load WAN models for each run. Because models stayed loaded more effectively on the local machine, a local RTX 5070 Ti completed the overall workflow faster. [13]

Another user reported spending about 35 H100 hours per month on QLoRA and inference for 7B–30B models. After reassessing the workload, the user estimated that an RTX 5090 could perform the same work for roughly $12 per month instead of approximately $60, with the same evaluation results. [14]

The reverse can also happen. In a provider-affiliated vLLM benchmark, B200 had the highest hourly price among the tested GPUs but achieved the best reported cost per million tokens for the stated workloads because its throughput offset the price premium. [15] This should be treated as a technical benchmark rather than independent user sentiment, but the underlying lesson is important.

The cheapest GPU depends on what is being measured. Useful metrics include:

Cost per generated image or video
Cost per million tokens
Cost per completed training run
Cost per experiment
Cost per checkpoint
Cost per successful deployment
Cost per employee task completed

Hourly price is an input. Completed output is the result.

5. Cloud versus local is a utilization question

The same principle applies when comparing GPU rental with hardware ownership.

Buying a GPU can look cheaper after enough rental hours. But the true comparison also includes:

Purchase cost
Electricity
Cooling
Storage
Maintenance
Depreciation
Resale value
Hardware downtime
Upgrade cycles
The employee time required to operate it

Cloud GPUs remain attractive for occasional use, uncertain workloads, short-term projects, and validation before a major hardware purchase.

One user rented a cloud RTX 5090 for several days before considering a $2,499 purchase, using the rental period to measure the actual speed improvement for a ComfyUI workload. [16]

A startup used cloud H100s to validate its software, but planned to move toward local hardware because predictable product pricing and customer deployment mattered more during commercialization. [17]

These cases suggest that cloud and local infrastructure are not always direct competitors. Cloud may be used for:

Initial validation
Temporary peak capacity
Large training runs
Access to new GPU generations
Workloads with irregular demand

Local hardware may become more economical when usage is frequent, predictable, and sustained.

6. API versus self-hosting has no universal winner

The same company can reach different conclusions depending on model quality, task type, privacy requirements, and utilization.

In one Reddit discussion, two companies reported opposite completed decisions. One moved routine work to a self-hosted GLM model while retaining Anthropic Opus for selected research and R&D tasks. Another modeled the economics repeatedly and kept managed APIs because weaker self-hosted models and operational work shifted the cost into employee and engineering time. [18]

At high utilization, self-hosting can make more sense. One company reported processing roughly 70–120 million tokens per day, with peaks around 330 million, on local multi-GPU systems. It still used Gemini Flash for some workloads, creating a hybrid rather than fully local architecture. [19]

Another 40-user company invested approximately €26,000 in a self-hosted Qwen and OpenWebUI environment integrated with Active Directory, while retaining an external search API. [20]

Privacy and regulation can also justify a higher cost. A B2B AI company reported that private LLM deployments were substantially more expensive than commercial APIs, but continued offering them to customers that required greater control over sensitive data. [21]

Conversely, one self-hosting user calculated local GPU options at roughly $49–$69 per month after including capital cost, power, always-on storage, depreciation, resale value, and maintenance. At the user's current usage level, a $19.99 managed subscription remained the preferred choice. [22] These prices are a January 2026 snapshot, but the TCO framework remains useful.

Cost is not always the final reason, either. A Claude Pro subscriber moved to local models after usage and chat-length limits repeatedly interrupted work. The local models were described as less capable, but the user reported getting more work done because the workflow was no longer interrupted. [23]

The best model on a benchmark is not necessarily the model that creates the most business value.

A better GPU cloud comparison checklist

Before selecting a GPU cloud, estimate the cost of completing the actual workload. Ask:

How long does the full workflow take, including setup and data movement?
What happens when an instance fails or is interrupted?
Where are models, datasets, checkpoints, and outputs stored?
Is storage portable across regions and GPU types?
How often will the workload run?
Can a cheaper GPU complete the job with the same quality?
Does a more expensive GPU finish enough faster to reduce cost per output?
How much employee time is required to operate the environment?
Are privacy, SLA, support, or capacity guarantees part of the requirement?
Would an API, cloud GPU, local system, or hybrid architecture best match actual utilization?

The comparison should end with a unit that reflects the business or research result.

Not $ per GPU-hour. But $ per completed workload.

Conclusion

GPU hourly pricing is easy to compare because it is visible and standardized. The costs that determine whether a project succeeds are less visible.

Setup time, failed jobs, storage, transfers, idle resources, unavailable capacity, model loading, network performance, engineering labor, and workflow restrictions can all change the result.

This is why the cheapest GPU instance is not always the cheapest GPU infrastructure.

The more useful comparison is not how cheaply a GPU can be started. It is how reliably and economically the workload can be completed.

Research note

This article is based on GPU Cloud Research, a qualitative analysis of Reddit discussions about GPU infrastructure. The research database contains 131 unique Reddit threads published from January 1, 2025 onward. Eighty evidence units were selected for Article #002.

Reddit posts represent individual experiences and discussions. They do not measure provider market share, overall failure rates, or current official pricing. User-reported prices should be treated as snapshots from the date of each post. Provider-affiliated benchmarks are treated as technical references rather than independent customer evaluations.

Source Notes

Reddit threads referenced in this article, in order of appearance.

R065 — Vast.ai bad experience — r/LocalLLaMA
R070 — 3 hours of LoRA training completely wasted on... — r/StableDiffusion
R075 — Alternatives to RunPod — r/comfyui
R104 — RunPod a million times slower on I/O than Vast — r/comfyui
R111 — RunPod ComfyUI alternative — r/comfyui
R101 — I think that price is too much — r/vastai
R063 — PSA: don't bother with network volumes on RunPod — r/StableDiffusion
R076 — How can I save my progress between different server instances — r/LocalLLaMA
R102 — Preventing lost data from ai-toolkit once RunPod... — r/StableDiffusion
R110 — What's going on with RunPod today or lately, there... — r/RunPod
R093 — How many of you actively use RunPod — r/comfyui
R008 — I got tired of spending 30 minutes setting up GPU... — r/mlops
R072 — RunPod insanely slow to load models — r/comfyui
R127 — Spent months renting H100s for 7B models like an... — r/deeplearning
R128 — Benchmarking LLM inference on RTX Pro 6000 SE — r/LocalLLaMA
R066 — Rent RunPod 5090 vs purchasing $2,499 5090 for 24... — r/StableDiffusion
R049 — Recommendation for production hardware for... — r/LocalLLaMA
R123 — Anybody ran the numbers and decided self-hosting... — r/mlops
R125 — Local setup — r/LocalLLaMA
R126 — What are companies actually using for self-hosted... — r/LocalLLaMA
R124 — The real cost of hosting an LLM — r/LocalLLaMA
R130 — AI seems to be being deeply subsidised — r/selfhosted
R131 — Comment on local vs. Claude Pro workflow — r/ClaudeAI

Originally published on Compute Cluster.

Local AI, Cloud GPUs, or APIs? Four Questions to Answer Before Comparing Cost

GridPort — Fri, 21 Aug 2026 10:28:10 +0000

“Should I buy local hardware or rent GPU capacity?”

Price alone cannot answer that question. The decision may also involve control, data-handling requirements, and where each part of a workload should run.

This guide separates the local-versus-cloud debate into four practical questions. By the end, you should know what to verify before comparing prices and which deployment options are worth testing first for your workload.

In this article, hosted options include self-managed rented GPU infrastructure, managed dedicated endpoints, and shared model APIs. They differ in pricing, tenancy, data handling, and operational responsibility. “Cloud” is convenient shorthand, but it is not a single deployment model.

TL;DR: Four questions that shape the decision

💰 ROI: Which cost structure fits after both options meet the required quality?
🔧 Control: How much of the model, data path, update cycle, and operation do you need to manage?
🔐 Constraints: Which data is permitted to go to which environment?
🔀 Routing: Does every task need to run in the same place?

Why “local or cloud?” is not enough

A recent r/LocalLLM discussion about whether systems beyond 128 GB are financially viable is a useful example. The original post argued that large local stacks often fail an ROI test and recommended cloud access for larger models. Replies pushed back that local hardware can be an enthusiast purchase and emphasized privacy, control, and the freedom to experiment.

A separate r/macbookpro discussion included a self-described lawyer distinguishing public documents from privileged material, a systems administrator concerned about ITAR and DOD information, and a user who gathered current information with an online model before passing it to an offline model for deeper work.

Examples: lawyer and privileged material · systems administrator and ITAR/DOD · online-to-offline workflow

None of these are really answers to the same question. Each commenter was solving something different, and the local-versus-cloud framing flattens all of it into one debate.

There's another reason the binary framing fails: deployment isn't a single spectrum running from “local” at one end to “cloud” at the other. It's a bundle of separate decisions. A system may run on owned or rented hardware, on-premises or in a data center, as a dedicated or shared service, and under your operation or a provider's. Ownership, location, tenancy, and operational responsibility do not have to move together.

Four questions to separate before deciding

1. 💰 “Will this pay for itself?” — the ROI question

Before comparing prices, check technical feasibility. Both options must do the required job at acceptable quality. Benchmark representative tasks across model and quantization, context length, output quality, concurrency, and latency. A cheaper system that misses the target isn't a cheaper equivalent—it's simply a different product.

If both options clear that gate and the goal is financial return, start with a workload — not a model-size threshold and not the price of a GPU in isolation.

A useful comparison looks more like this:

Annual local cost
= hardware amortization
+ power and cooling
+ storage and networking
+ maintenance and replacement risk
+ engineering time

Annual hosted cost
= compute usage
+ persistent storage
+ data transfer
+ idle, startup, and recovery overhead
+ engineering time

The workload inputs matter just as much as the prices: prompt and output lengths, peak concurrency, latency targets, duty cycle, utilization, and expected growth.

Consider a deliberately simplified example. A $12,000 workstation used for four years starts at $3,000 per year before power, maintenance, and engineering time. Hosted compute at an assumed $5 per hour starts at $1,200 per year when used for 20 hours a month, but reaches $7,200 per year at 120 hours a month—before storage, data transfer, or migration work. These illustrative numbers do not identify a winner. They show how duty cycle alone can reverse the comparison.

Concurrency is particularly easy to underestimate. The PagedAttention paper behind vLLM explains how large, dynamically changing KV caches can limit batch size. Its evaluation found that better KV-cache management changed throughput by 2–4× at a similar latency level in the tested systems. In other words, a cost model based on single-user tokens per second may say little about production economics.

If those workload inputs have not been measured, a short on-demand rental or API trial can collect real demand, concurrency, and utilization data before buying. But renting is not automatically low commitment: reservations, migration work, persistent storage, data transfer, and provider-specific integration create costs of their own. Buying becomes a financial argument when repeated usage produces a credible break-even case.

2. 🔧 “How much control do I need?” — the control question

For some teams and individual builders, maximizing financial return is not the only objective.

Local deployment can provide more direct control over model files, update timing, data paths, offline availability, and experimentation without per-request charges.

But this is a transfer of responsibility, not literal independence. Local operation also makes you responsible for patching, authentication, backups, capacity planning, hardware failure, and eventual replacement.

That trade may still be worthwhile. A lab, hobbyist, or engineering team can rationally pay for control and experimentation even when the hardware does not produce the best spreadsheet ROI. The important thing is to name that value honestly instead of forcing it into a cost-per-token argument.

3. 🔐 “Which deployments are we allowed to use?” — the constraint question

Some workloads face contractual, confidentiality, export-control, residency, or internal-policy requirements that rule out particular providers, regions, or data flows.

That does not mean every cloud service is unavailable to every regulated organization.

For example, in the United States:

HHS guidance says HIPAA-covered entities and business associates may use cloud services for ePHI when they enter into an appropriate business associate agreement and otherwise comply with the HIPAA Rules.
22 CFR 120.54 describes conditions under which sending, taking, or storing certain encrypted technical data is not treated as an export, reexport, retransfer, or temporary import under ITAR.
ABA Formal Opinion 512 tells lawyers using generative AI to evaluate confidentiality, informed consent, terms of use, privacy policies, and vendor safeguards rather than imposing a universal ban on cloud tools.

These are US-specific examples, not legal advice. Requirements vary by jurisdiction, contract, client, data type, and system design.

The practical question is narrower than “Is this industry allowed to use cloud?” Ask instead: Which data may go to which processor, in which region, under which contract and controls? Confirm that boundary before optimizing cost.

Sources: HHS guidance · 22 CFR 120.54 · ABA Formal Opinion 512

4. 🔀 “Which part of the workload belongs where?” — the routing question

Local and cloud do not have to be mutually exclusive.

Work can be routed by data sensitivity, freshness, latency, model capability, or burstiness.

The Reddit example above — online retrieval followed by deeper offline processing — is one possible pattern, not a universal architecture. Research on local-cloud LLM inference offloading similarly treats placement as a per-task decision involving response quality, latency, usage cost, and resource constraints.

A system might keep sensitive processing inside a controlled environment, send approved low-risk tasks to a hosted model, and rent additional GPUs for temporary peaks. Splitting work by requirement is also a valid architecture.

Further reading: Local-cloud LLM inference offloading

Three operational checks to include in the comparison

The four questions above help decide where a workload belongs. The following checks test whether the comparison still holds once the system is operated in practice.

Cloud cost needs active controls

Cloud cost is not self-governing. Budgets, quotas, anomaly alerts, and a named owner belong in the design.

Cloud providers offer cost-anomaly tooling because unexpected spend must be detected and investigated. AWS notes in its Cost Anomaly Detection documentation that billing-data delays can mean an anomaly takes up to 24 hours to detect after usage occurs. An alert is useful, but it is not an instantaneous kill switch.

Self-hosting is not secure by installation alone

Self-hosting is not private or secure by default, either. It describes who operates the stack, not where it runs; the hardware may be in your building or rented elsewhere. A joint SentinelOne and Censys investigation recorded 175,108 internet-reachable Ollama hosts across 130 countries over 293 days. That does not mean every host was compromised, but it does show how easily infrastructure assumed to be private can become publicly reachable.

A self-hosted service still needs deliberate network binding, authentication, patching, segmentation, and monitoring. The security boundary comes from the architecture and its operation — not the GPU's location alone.

External APIs and local hardware both need contingency plans

Local infrastructure requires upfront capital, power, maintenance, spare capacity, and a replacement plan. Hosted infrastructure introduces dependencies on provider availability, policy, pricing, geography, and regulation.

Those external conditions can change. According to Anthropic's account of the event, a US export-control action led the company to suspend access to Fable 5 and Mythos 5 on June 12, 2026. The restrictions were lifted on June 30, and access was restored in stages: Fable 5 returned globally on July 1, while Mythos 5 remained limited to approved organizations at that time.

The lesson is not that hosted APIs are uniquely unreliable. It is that external APIs are dependencies that need an explicit contingency plan, just as local hardware needs recovery and replacement plans.

Conclusion: Choose the decision criteria before the provider

Before committing, find the row that best describes the real driver:

Situation	Sensible first move	Verify before committing
Quality or performance is uncertain	Benchmark representative tasks	Model, quantization, context, output quality, concurrency, and latency
Demand is uncertain	Run a short on-demand trial	Actual usage, utilization, migration effort, storage, and data transfer
Usage is sustained and predictable	Model the buy-versus-rent break-even point	Full operating cost, growth, maintenance, and replacement risk
Control is valuable even without ROI	Consider owned or self-managed infrastructure	Patching, authentication, backups, capacity, and recovery ownership
A law, contract, client term, or policy limits data flow	Define the permitted boundary first	Data type, processor, region, contract, logs, and administrative access
Tasks have different needs	Route them across suitable environments	Sensitivity, freshness, capability, latency, burstiness, and failure paths

Local hardware, rented GPUs, managed endpoints, and shared APIs are implementation choices within a wider deployment design. The first decisions are the required quality, cost structure, control boundary, permitted data flow, and routing policy—not the provider or hardware.

There is no need to move workloads that already fit an API onto local infrastructure. However, when control requirements or data boundaries are clear, local or hybrid deployment may be worth evaluating. Compare prices only after those conditions are defined.

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

MiniMax H3 Beyond Basic Generation: R2V, Video Editing, Voice Cloning, and Agent-Written Prompts

GridPort — Wed, 19 Aug 2026 02:07:11 +0000

Most MiniMax H3 tutorials stop the moment text-to-video or image-to-video produces a usable clip.

That is enough to prove the model runs, but it misses the part that makes H3 interesting: reference-to-video (R2V). With R2V, images can define identity and style, video can define motion or camera work, and audio can define a voice—all within one generation context.

In practice, adding more files isn't the hard part. The real challenge is telling H3 exactly what each reference controls, what must remain unchanged, and what may be transformed.

This guide focuses on four practical skills:

Skill	What it gives you
Mixed-reference R2V	Reuse identity, style, motion, camera work, and audio
Instruction-based video editing	Change one part of a clip while preserving the rest
Voice-timbre transfer	Generate new dialogue using a consented voice reference
Agent-written prompts	Convert a rough brief into H3's structured prompt format

Before you start

This article assumes that MiniMax H3 already runs in ComfyUI. The official ComfyUI integration requires version 0.30.0 or later and provides T2V, I2V, and R2V templates under Template Library → Video.

Two details are easy to overlook:

H3-Base generates at 768p. MiniMax's separate H3-Regenerate-2K stage produces 2K output, but that module is not currently part of the open-weight release.
R2V uses a different checkpoint from T2V and I2V. In ComfyUI, use the ref2va weights for reference-driven generation, not the fl2va weights.

1. Think in reference roles, not reference files

H3-Base-Ref2VA accepts a mixed context of:

Up to 9 images
Up to 3 video clips
Up to 3 audio clips
Up to 12 files in total

Each video or audio clip must be between 2 and 15 seconds, and the total duration for each media type cannot exceed 15 seconds.

Those limits are generous, but filling every slot rarely improves the result: a short target clip can't express twelve competing ideas clearly, so start with the smallest reference set that describes the shot.

For example:

<Picture 1>: character identity
<Picture 2>: costume and color palette
<Video 1>: body movement and camera motion
<Audio 1>: voice timbre

Then state those jobs directly in the prompt:

<Picture 1> defines the character's face and hairstyle.
<Picture 2> defines the wardrobe and blue-silver color palette.
<Video 1> defines the walking motion and slow left-to-right tracking shot.
<Audio 1> is the voice-timbre reference for the character.

The order matters. ComfyUI identifies references by the order in which they are connected, so <Picture 1> in the prompt must really be the first connected image.

A reliable R2V workflow

Decide what the final 4–15 second clip should accomplish.
Assign one explicit role to each reference.
Remove references that do not contribute to that result.
Describe the action chronologically.
Specify camera movement, dialogue, ambience, effects, and music.
Check every label against the order of the connected inputs.

References carry reusable traits. The prompt decides what those traits do over time.

2. Edit video by separating preservation from change

R2V can also behave like an instruction-based video editor. Give it a source video, identify what must remain stable, and describe the local change.

Typical edits include:

Replacing a character or object
Changing the background
Relighting a scene
Transferring a visual style
Adding a localized effect
Preserving or replacing the original audio

A prompt like "make this warmer" rarely gets useful results. What works better is a small edit specification with an explicit preservation contract.

Here is a relighting example:

subject_definitions:
<Video 1> is the source video. It shows a product on a table in daylight.

summary:
[video editing] Relight <Video 1> as a warm evening interior.

retention_analysis:
<Video 1> (composition, camera movement, product position): fully_preserved.
Only the lighting condition changes.

detailed_description:
The target video keeps the composition and timing of <Video 1>.
[Shot 1] Replace the daylight with warm evening light entering from the left.
Soft amber highlights move across the product. The camera, product, table,
background geometry, and duration remain unchanged.

overall_soundscape:
Reuse the original quiet room tone without modification.

non_diegetic_music:
N/A

This structure reduces a common failure mode: the model "helpfully" redesigns the entire shot when only one attribute should change.

Use fully_preserved for composition, motion, timing, or audio that must remain intact. Use an explicit transfer or replacement instruction only for the attributes that should change. If a section is irrelevant, write N/A instead of leaving the intent ambiguous.

3. Treat voice cloning as timbre transfer—not signal copying

With an audio reference, H3 can generate new speech that follows a speaker's vocal characteristics while producing new audio for the target scene.

A minimal prompt might look like this:

<Subject 1> is the character shown in <Picture 1>.
<Audio 1> is the consented voice-timbre reference for <Subject 1>.
Use <Audio 1> only as a timbre reference; do not reproduce its original words.

<Subject 1> turns toward the camera and says:
<d>[Japanese] こんにちは、今日は新商品をご紹介します。</d>

For cleaner transfer, use a short recording with:

One speaker
Little or no music
Minimal room echo
No overlapping dialogue
A speaking style close to the desired output

Consent is part of the workflow

Only use a voice when you have the speaker's informed consent or another clear legal right to use it. Do not imitate a real person deceptively, and disclose synthetic media where appropriate. A technically successful clone can still violate privacy, publicity, copyright, platform, or employment rules.

Check this before the audio ever enters the workflow, not as a final QA step tacked on afterward.

4. Let an agent write the structured prompt

MiniMax includes an official h3-prompt-writing skill in the H3 repository. It's a Markdown-based instruction package, portable to any coding agent or harness that can read a SKILL.md file and its local references.

Install it with:

npx skills add https://github.com/MiniMax-AI/MiniMax-H3 --skill h3-prompt-writing

The skill first selects the input mode:

Mode	Purpose
T2VA	Generate an audiovisual timeline from text
I2VA	Continue forward from a first frame
FL2VA	Connect supplied first and last frames
L2VA	Build toward a supplied last frame
Ref2VA	Generate from mixed image, video, and audio references

For the base modes, it produces three sections in this order:

integrated_multimodal_description
overall_soundscape
non_diegetic_music

For full-reference Ref2VA, it uses six:

subject_definitions
summary
retention_analysis
detailed_description
overall_soundscape
non_diegetic_music

Handing this to an agent works well because the task is mechanical: preserve exact field names, resolve labels, arrange events chronologically, keep the sound synced to the visual timeline.

A practical request to the agent can be short:

Use the MiniMax H3 prompt-writing skill.

Mode: Ref2VA
Duration: 8 seconds
Picture 1: character identity
Video 1: camera motion only
Audio 1: consented voice-timbre reference

Goal: The character walks into a small studio, stops at the desk,
looks at the camera, and says “Build the first version today.”
Preserve the character identity and the reference camera motion.
Generate quiet room ambience. No music.

The resulting prompt should still be reviewed. Check that every reference exists, every preservation rule is intentional, the dialogue fits the duration, and the generated structure has not introduced details you did not ask for.

Common failure modes

1. A reference has no declared job

If the prompt does not say whether a video controls motion, style, composition, or all three, the model has to guess.

Fix: assign a role to every input.

2. The edit and preservation rules conflict

“Keep the original lighting” and “change the scene to sunset” cannot both be true.

Fix: separate preserved attributes from transferred or replaced attributes.

3. Too much story for the duration

A 6-second clip cannot reliably contain an establishing shot, three actions, a costume change, a camera orbit, and two lines of dialogue.

Fix: choose one visual beat, or increase the duration within H3's 15-second limit.

4. Voice audio contains music or multiple speakers

The reference no longer represents one clean voice identity.

Fix: prepare a rights-cleared, single-speaker sample with minimal background sound.

5. The open-weight license is treated like a permissive OSS license

It is not. The MiniMax H3 Community License currently excludes the European Union, the United Kingdom, the Republic of Korea, and the United States from its applicable territory. It also restricts use and display of the model's outputs outside that territory, requires separate authorization for certain commercial products above the stated revenue threshold, and includes labeling obligations.

Fix: read the current license before downloading the weights, deploying a service, or publishing an output. If your use crosses jurisdictions, get qualified legal advice. Because the restriction covers display of outputs, I have intentionally not embedded an H3-generated video in this cross-post.

Pre-generation checklist

[ ] The target duration and aspect ratio are defined.
[ ] Every image, video, and audio input has one explicit role.
[ ] Reference labels match ComfyUI's connection order.
[ ] Preserved and changed attributes do not conflict.
[ ] The action fits within 4–15 seconds.
[ ] Camera, dialogue, ambience, effects, and music are specified.
[ ] Voice and visual references are consented or rights-cleared.
[ ] The deployment and publication plan complies with the current license.

Final takeaway

The skill in advanced H3 prompting has little to do with cinematic paragraph length. It comes down to a clear contract between the references and the target clip:

What does each reference control?
What must remain unchanged?
What should change, and when?
What should the audience hear at each moment?

Once those decisions are explicit, R2V becomes much more predictable. And an agent can handle much of the repetitive prompt structuring for you.

Official references

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

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.