Fabric accepts image_url or avatar_handle, never both: which to send

On Sume's VEED Fabric 1.0 route, send exactly one visual source: either the image_url of a still you generated and inspected, or an avatar_handle when the user named that avatar. The models overview says you cannot send the two together. It also says the image_url is the preferred source.

What the overview specifies

The body is audio_url, a measured duration_seconds and one visual source. The public model id is veed/fabric-1.0 and the route is POST /v1/veed/fabric-1.0. The older POST /v1/avatar-1.0/image-to-video route is a deprecated compatibility alias that accepts the same body, so integrations can migrate by changing only the URL.

The reason for the exclusion is practical. A still and a stored avatar are two different identities, and the route has to render one face. Choosing in your own code, before the call, makes the request unambiguous and the result predictable.

Why a posed still is preferred

A still you have looked at is a known frame: you have seen the face, the framing and the crop before you spend any per-second charge. A handle points to a stored avatar, which is fine when the user asked for that character, but you did not pick the pose. Fabric is priced per audio second ($0.10 at 480p, $0.1875 at 720p), so spending 20 seconds on a bad frame at 720p costs 20 x $0.1875 = $3.75.

A common pattern is to create an avatar once with Sume Avatar 1.0 at $0.95, keep its handle, and use the handle on Fabric when a named avatar speaks a recorded line. Use the still when you have generated and inspected a specific pose for the shot. Either way, the audio is Sume-hosted, and it is billed by the rounded-up second.

• Audio must be Sume-hosted and under 10 MB.
• Maximum audio length is 300 seconds.
• The model id is veed/fabric-1.0 on both the new and the alias route.

MCP callers

With MCP, the same body goes inside payload on the supported avatar-image-to-video_create tool, per the overview. The one-source rule is the same there.

If you are migrating an old integration from the deprecated avatar image-to-video route, the body does not change, so the visual-source rule carries over unchanged. Review your callers for any that set both fields: the old route accepted the same body, and your code may have been relying on one of the two being ignored. Make the choice explicit in a small helper that takes a still URL or a handle and returns exactly one field, then use it for both routes.

In short, treat the visual source as a required choice made before the call. Prefer the inspected still when you have one, use the handle when the user named the avatar, and never fill both fields to be safe.