Higgsfield + Claude + Framer: Adding AI Video to a Website

Connecting Higgsfield to Claude

Higgsfield AI MCP links Claude directly to Higgsfield's video and image models over the Model Context Protocol. No separate server to run, no API key to manage. There are two setup paths depending on which Claude interface you use.

Claude web or desktop

Settings → Connectors → Add custom connector → paste https://mcp.higgsfield.ai/mcp → authorize in the browser that opens. You need an active Higgsfield subscription and a Claude account; authorization is OAuth, not an API key.

Claude Code

Run this in a terminal:

claude mcp add --transport http --scope user higgsfield https://mcp.higgsfield.ai/mcp

Claude Code handles authorization via a browser window the same way. Either path exposes the same tools: generating images and video, training a reusable character (Higgsfield calls this Soul ID), and browsing your generation history, all from inside a Claude conversation, without opening the Higgsfield dashboard.

Which Higgsfield plan you actually need

We generated on the Plus plan ($49/mo, or $39/mo billed annually) rather than the cheaper Starter tier ($15/mo), and that was a deliberate hedge, not a requirement we confirmed in advance. Higgsfield's own pricing page lists Starter as "selected models only" and explicitly excludes Google's Veo 3 and Veo 3 Fast. We didn't know ahead of time which model the MCP connector would reach for by default, so we picked the plan that unlocks everything to avoid losing time to a blocked model mid-test.

As it turned out, we ended up specifying Kling 3.0 Turbo directly, a model that Higgsfield's own plan comparison shows as available on Starter too (roughly 23 five-second Kling clips out of Starter's 200 monthly credits). If you know in advance you only need Kling-family models for something like a hero background clip, Starter may be enough. We didn't test that path ourselves, so treat it as a plausible reading of Higgsfield's pricing page rather than something we verified.

One more thing worth checking before you rely on this for client work: we did not independently verify Higgsfield's commercial usage terms for AI-generated video on the Plus plan. Confirm licensing on your own account before you publish generated video on a paying client's site.

Pricing above reflects what was available to us in August 2026. Higgsfield's rates can vary by region and billing cycle, so confirm current pricing on your own account before you commit to a plan.

Generating the clip

We asked for a short, atmospheric loop for a florist's hero section, the kind of thing that's genuinely hard to shoot and license affordably as stock footage, and a reasonable real-world use case for this workflow. The prompt:

Model: Kling 3.0 Turbo, described by Higgsfield as fast text-to-video with single start-frame animation. Settings: 6 seconds, 16:9, 1080p. Cost: 12 credits. Dropping to 720p brings that down to 9 credits, if file weight matters more than resolution for your use case (it usually should; see below).

Generation took roughly a minute. We didn't stopwatch it the way we clocked the 18-minute Framer agent build in our previous piece, so call this an estimate, not a measured figure. The result showed up under Higgsfield's Cinema Studio → My Generations, not under Marketing Studio, because we called the model directly rather than going through a Marketing Studio workflow.

Getting it into Framer

This part had zero friction. Downloaded the clip, dragged it straight onto the Framer canvas in place of the existing hero photo, and Framer created a video element on the spot, no import dialog, no format conversion step. Matching the border radius to the rest of the design took one more click in the Style panel.

The raw file was 6.8 MB for six seconds of video. That's the number that matters more than anything about the generation step itself.

What we expected vs. what happened

The weight problem, and what wasn't the video's fault

We compressed the 6.8 MB export down to 1.6 MB using VidCrush: free, browser-based, no signup, no watermark, well within its 500 MB limit for a file this small. That's a real, honest 76% reduction, and it's the number we'd point anyone to if this is the only step they take.

What we didn't expect: even with the video at 1.6 MB, PageSpeed Insights still reported the total page payload at 6.35 MB on desktop and 6.76 MB on mobile, nearly the weight of the original, uncompressed video file, and the video wasn't the reason. The single largest recoverable chunk PageSpeed flagged was 2.4 MB of unused JavaScript loaded by the page, unrelated to the Higgsfield video itself and most likely runtime and component overhead from the Framer template rather than anything we added. If you're chasing page weight after adding AI video, check total payload before you assume the video is the culprit. On this test site, it wasn't the biggest one.

The accessibility gap, and the fix we didn't fake

PageSpeed's accessibility audit came back at 82/100 with two flags directly relevant here: the page's <html> element had no lang attribute, and the new <video> element had no <track> for captions.

The lang attribute was unrelated to the video, a baseline gap in the test site's settings, fixed in Framer's Site Settings in under a minute.

The missing captions flag is more interesting, because the obvious fix is the wrong one. Our clip has no dialogue and no on-screen text. It's ambient motion, nothing a caption track could meaningfully transcribe. Adding an empty .vtt file just to make the automated check pass would satisfy Lighthouse without fixing anything real: a screen reader user would still land on a video element with no useful information, now dressed up as if it had one.

The more honest fix is to tell assistive technology to skip it, because it's decorative. We replaced Framer's native Video component with an Embed component carrying hand-written markup:

<video autoplay muted loop playsinline aria-hidden="true"
       style="width:100%;height:100%;object-fit:cover;border-radius:16px;">
  <source src="YOUR_VIDEO_URL" type="video/mp4">
</video>

aria-hidden="true" is the point: it removes the element from the accessibility tree entirely, which is appropriate for video that carries no information a non-visual user needs. It's not a universal fix. If the visuals in a clip communicate something real, a product demo, an instructional shot, anything beyond mood and motion, hiding it is the wrong move; you'd want an equivalent text description or real captions instead. Lighthouse's captions rule is a blanket check; it can't tell a decorative loop from an interview. Knowing the difference is the part a tool can't do for you.

The mobile bug that wasn't a bug

Before we got to any of the fixes above, we opened the published page on a real iPhone and found the hero section empty: no video, no fallback image, just blank space where it should have been. It reproduced in both Safari and Chrome on that device, which briefly looked like a real platform limitation rather than a browser quirk.

Navigating to another page and back made the video appear. A second, different iPhone showed the video immediately on first load, no issue. Going back to the first phone with a fresh open, it worked too.

The most likely explanation was a stale cache on that one device, not a reproducible rendering bug in Framer or a compatibility problem with the Higgsfield export. We can't prove the cache theory the way you'd prove a code fix, but the problem didn't reproduce once we tested a second device and reopened the first one fresh. It looked exactly like a bug worth writing up until the mundane explanation held up better than the dramatic one, which is the actual lesson: one phone is not a test suite, and "it's broken on my device" is a hypothesis, not a finding, until you've checked a second device and a hard refresh.

Before and after, verified

Both PageSpeed runs below used the same 1.6 MB compressed video. The only change between them was replacing the native Video component with the Embed + aria-hidden version above, plus adding the missing lang attribute. We re-ran the test with a cache-busting query string to rule out Cloudflare-style edge caching skewing the numbers.

We didn't isolate every variable: the lang fix, the component swap, and the aria-hidden attribute all landed in the same pass, so we can't cleanly credit one change for the full gain. What we can say is that the combined fix moved a real number, not just a cosmetic score: LCP dropped by more than two seconds and Total Blocking Time more than halved.

4.3 seconds of LCP is still outside Google's "good" threshold (under 2.5s). A hero video, even compressed and correctly marked up, is not a free addition to mobile performance. It costs something, and the honest number after our fix is still "needs improvement," not "good."

Two other flags stayed exactly where they were, and neither is about the video: insufficient color contrast somewhere on the page, and links without a distinguishable purpose. Both are pre-existing issues on the test site, worth fixing separately, unrelated to anything in this workflow.

When this is worth doing

Worth it for: a hero section that needs motion and doesn't have stock footage that fits, background loops with no dialogue or informational content, quick concept previews before commissioning real video.

Do the extra work for: anything client-facing. Compress before you publish, mark decorative video as decorative rather than faking captions, and check mobile on more than one device before you call it done.

Skip it for: any video that needs to convey actual information, product demonstrations, testimonials, anything with speech, where a caption track is a real requirement, not one to bypass with aria-hidden.

The generation and the drag-and-drop are the fast part, and neither one is where the risk lives. The risk is in publishing a 6.8 MB file nobody compressed, or a decorative video that either fakes captions or skips the accessibility question entirely. That's still work a person has to do.