Skip to content

feat (fal): Set .providerMetaData for image model responses#6406

Merged
gr2m merged 7 commits intov5from
v5-gr2m/6405-fal-image-provider-meta-data
May 21, 2025
Merged

feat (fal): Set .providerMetaData for image model responses#6406
gr2m merged 7 commits intov5from
v5-gr2m/6405-fal-image-provider-meta-data

Conversation

@gr2m
Copy link
Copy Markdown
Collaborator

@gr2m gr2m commented May 20, 2025

Background

Fal Image Models return extra information besides the images themselves. This pull request exposes that information as .providerMetaData.fal.* on the generateImage() return object.

Example response

{
    images: [
        {
        url: "https://v3.fal.media/files/monkey/YFjatR9EwscWibTqF-NtK.png",
        width: 1024,
        height: 768,
        content_type: "image/jpeg",
        },
    ],
    timings: {
        inference: 0.35681894700974226,
    },
    seed: 731321029,
    has_nsfw_concepts: [
        false,
    ],
    prompt: "A cat wearing an intricate robe while gesticulating wildly, in the style of 80s pop art",
}

Summary

I updated the response schema for Fal's Image Model API responses and set the .providerMetaData key to the return object of FalImageModel#doGEnerate().

I normalized the .nsfw image meta data since Fal models have two variations

  1. has_nsfw_concepts - seems to be the standard one
  2. nsfw_content_detected - only used by https://fal.ai/models/fal-ai/lcm/api#schema-output as far as I can tell

Verification

I altered examples/ai-core/src/generate-image/fal.ts

image

Tasks

  • Tests have been added / updated (for bug fixes / features)
  • Documentation has been added / updated (for bug fixes / features)
  • A patch changeset for relevant packages has been added (for bug fixes / features - run pnpm changeset in the project root)
  • Formatting issues have been fixed (run pnpm prettier-fix in the project root)

Related Issues

Part of #6405

@gr2m gr2m force-pushed the v5-gr2m/6405-fal-image-provider-meta-data branch from 8f19464 to 489e548 Compare May 20, 2025 23:55
@gr2m gr2m force-pushed the v5-gr2m/6405-fal-image-provider-meta-data branch from 0450ffa to ef25ab2 Compare May 21, 2025 00:04
@gr2m gr2m marked this pull request as ready for review May 21, 2025 00:09
targetImages.map(image => this.downloadImage(image.url, abortSignal)),
);
const {
// @ts-expect-error - either image or images is present, not both.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a typesafe way to handle this?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not using image or images, the code is just to filter keys fro responseMetaData. It's the most efficient way as far as I know.

{
width: 1024,
height: 1024,
content_type: 'image/png',
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicates standardized prop?

Comment on lines +130 to +133
...(contentType !== undefined ? { contentType } : undefined),
...(fileName !== undefined ? { fileName } : undefined),
...(fileData !== undefined ? { fileData } : undefined),
...(fileSize !== undefined ? { fileSize } : undefined),
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I normalized some of the providerMetaData properties that I think the way we normalized revised_prompt to revisedPrompt in the Open AI Image model.

Shall I also camelize debug_latents, debug_per_pass_latents, and their respective properties?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder how far we should to here. usually we do this but it is also overhead

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder how far we should to here. usually we do this but it is also overhead

I agree. I think we should do it for properties that we see repeatedly across providers and models. But e.g. not go overboard with things like debug_latents which is specific to a single model from fal

I also wonder if we should pass through provider options that we don't handle ourselves. Otherwise we will always play catch up whenever some model from some provider exposes a new information. We could do it in a way that clearly communicates that we don't take responsibility, like .providerMetaData.fal.unsafe_otherData or similar.

@gr2m gr2m merged commit 3d1dcca into v5 May 21, 2025
8 checks passed
@gr2m gr2m deleted the v5-gr2m/6405-fal-image-provider-meta-data branch May 21, 2025 16:27
@gr2m gr2m added ai/provider related to a provider package. Must be assigned together with at least one `provider/*` label provider/fal Issues related to the @ai-sdk/fal provider labels Oct 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai/provider related to a provider package. Must be assigned together with at least one `provider/*` label provider/fal Issues related to the @ai-sdk/fal provider

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants