vargHQ/sdk: a JSX layer over Kling, Flux, ElevenLabs and Sora

The problem is orchestration, not generation

Generating one clip is a solved problem with a dozen vendors. Generating a ten-second vertical video with a generated character, a voiceover, background music and burned-in captions means four or five vendors, each with its own auth, polling model, asset upload flow and output format. The glue code is where projects stall. varg's claim is that this glue should look like a component tree, and that the vendor differences should disappear behind one key.

The audience is narrow and identifiable. It is TypeScript developers who already think in React and want video as a build artifact: marketing clips, UGC-style ads, talking-head explainers. The README also targets a second audience directly, agents running in Claude Code, Cursor or Windsurf, which is why the first quickstart path is a skill install rather than an npm install. That framing tells you something about intended usage: short, prompt-driven, regenerated often.

The component tree is the real interface

The README's component table is the substance of the project. Render is the root and takes width, height and fps. Clip is a time segment with duration, transition, cutFrom and cutTo. Inside a Clip you place Image, Video, Speech, Music, Captions, Title and Overlay. A separate set of layout components (Split, Slider, Swipe, Packshot) covers the template shapes that short-form video keeps reusing.

What makes this more than a naming convention is that components return values, not just markup. In the image-to-video example, Image is called as a function and assigned to a const, then passed into Video's prompt object as images: [character]. The same pattern appears in the lipsync example, where an animated Video is passed into another Video's prompt as video, alongside a Speech value as audio. So the tree is really a dependency graph evaluated before rendering, and the JSX is the final assembly step. That is a different mental model from a timeline editor, and it is the reason the caching story can work at all: an unchanged character definition is an unchanged input.

Speech is also used as a value in two places at once, as the audio source for lipsync and as the src for Captions. One generation, two consumers. That is the kind of thing that is annoying to wire by hand across separate vendor SDKs.

One API key, one hosted hop

The architecture diagram in the README is short and worth reading literally. A prompt or JSX file goes to the varg API at api.varg.ai/v2, which fans out to Kling, Flux, ElevenLabs, Wan and others, and the results come back through what the README calls the varg render engine to produce output.mp4. VARG_API_KEY is the only credential the SDK needs. Provider keys are not part of the setup.

That is the central trade-off of the project and the README does not present it as one. You get uniform auth, uniform model naming through varg.imageModel, varg.videoModel, varg.speechModel and varg.musicModel, and presumably uniform billing. You give up direct control of the provider relationship, and every prompt and source asset passes through a third party. Whether that is acceptable is a policy question, not a technical one, but it is the first question to answer.

The README states that identical props produce an instant cache hit at $0, so re-rendering without re-generating costs nothing. It does not state where the cache lives, how it is keyed, or how it is invalidated. The init command is described as setting up cache directories, which suggests at least part of it is local, but that is inference from a parenthetical, not a documented guarantee.

Getting a first render on disk

Two install paths are documented. The agent path is three commands: npx -y skills add vargHQ/skills --all --copy -y to install the skill, export VARG_API_KEY=varg_live_xxx, then a natural-language prompt through claude. The developer path is bun install vargai ai (or npm install vargai ai), then bunx vargai init, which the README says signs you in, installs the agent skill, creates a starter template and sets up project structure. Rendering is bunx vargai render hello.tsx.

Note that ai is a peer dependency, consistent with the Vercel AI SDK foundation named in the description. The package name on npm is vargai, not varg, while the import specifiers are vargai/react and vargai/ai. The CLI is invoked as vargai. That naming split is worth knowing before you go looking for the wrong package.

For cloud rendering the README gives one endpoint, POST https://api.varg.ai/v2/render. No payload schema, no auth header format beyond the API key, no response shape. If you intend to render server-side rather than on a developer machine, that endpoint is the piece you will have to reverse from the docs site, because the README stops at the URL.

Where the abstraction leaks

The component set is tuned for a specific output shape. Every example in the README is 1080x1920, 9:16, five-second clips, captions styled tiktok. The layout components (Swipe, Slider, Packshot, TalkingHead) are ad and social formats. If your work is long-form, multi-track, or needs frame-accurate editorial control, this is the wrong tool, and the Clip model with cutFrom and cutTo is not a substitute for a real timeline.

Model identifiers are passed as strings, kling-v3, sync-v2-pro, eleven_v3, nano-banana-pro. Nothing in the README describes what happens when a provider deprecates one, or whether an unknown string fails at build time or at render time. Given that the SDK fronts multiple vendors with independent release cycles, that failure mode will arrive. Treat model strings as configuration you will be editing, not constants.

Cost is also unaddressed. The cache is described as free on a hit, which implies non-hits are billed, but there is no pricing table, no way to estimate a render before running it, and no documented dry-run flag. For a tool whose whole pitch is regenerating videos often, the absence of a cost preview in the README is the most conspicuous gap.

Compared with calling the providers yourself

The obvious alternative is the Vercel AI SDK directly, which varg is built on. That gives you the same TypeScript ergonomics for text and, depending on which provider packages you install, for speech and image generation, without an intermediary. The difference is compositional: the AI SDK gives you model calls, and you still own the assembly of clips, audio tracks, caption timing and the final mux. varg's contribution is that assembly layer plus the multi-vendor routing behind one key.

A second alternative is a hosted video API that does the whole job, such as a text-to-video service that returns a finished file from a prompt. That is simpler and less controllable: you cannot swap the image model independently of the video model, and you cannot reuse a generated character across clips the way the README's const character pattern does. The choice is between a pipeline you compose and a black box you prompt.

varg sits between those two. It is more structured than a single hosted endpoint and less work than assembling the AI SDK and ffmpeg yourself. The cost of that position is the extra network hop and the dependency on varg's continued operation of api.varg.ai.

Maintenance, licensing and what to pin

The repository is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It also means the licence covers the SDK code, not the API service it talks to. Nothing in the README describes the terms of the hosted API, so the licence on the repository should not be read as the terms under which you may generate video. Those are separate agreements, and the second one is the one that governs your production usage. This is not legal advice; read the API terms before you ship.

The SDK is TypeScript and depends on the Vercel AI SDK, so its upgrade surface includes that dependency's release cadence as well as varg's own. The README documents no versioning policy, no deprecation window for model strings, and no migration guide. The repository shows no retrieved releases, so there is no changelog to check for breaking changes. Pin the vargai version in package.json rather than floating it, and re-run one cached render after each bump to confirm the cache key still matches: if a version change alters how props are hashed, your $0 re-renders quietly become paid ones. That is the specific thing to test, not a general recommendation to monitor.

Editorial conclusion

Adopt varg if your output is short vertical video assembled from generated clips, speech and captions, and if you are willing to send generation traffic through api.varg.ai rather than to Kling, ElevenLabs or the other providers directly. Do not adopt it if you need a self-hosted inference path, if your provider contract forbids an intermediary, or if your pipeline is built around long-form editing rather than component composition. Before committing, verify three things in a test project: that the model identifiers you need resolve through varg.imageModel, varg.videoModel, varg.speechModel and varg.musicModel; that a second run of the same .tsx file actually hits the cache the README describes as a $0 instant hit; and what the varg API does with your prompts and uploaded source assets, because the README does not say.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. vargHQ/sdk on GitHub