DEV Community: dong

Designing a Video-to-Video AI Workflow: Validate Inputs Before Spending Credits

dong — Sun, 11 Oct 2026 02:34:18 +0000

A video-to-video editor has a different starting point from a text-to-video generator: the user already has a performance they want to keep. The interface needs to make clear what should change and what the source footage is meant to guide.

Our project, AI Genjutsu, focuses on character replacement using a source video and a reference image. This post shares a practical design checklist for that kind of workflow. It is not a model benchmark or a guarantee of frame-perfect preservation.

1. Separate the two inputs

The source clip supplies the performance: movement, timing, framing, and camera behavior. The reference image supplies the intended character appearance. Treating them as separate inputs makes the task easier to explain than a single upload box labeled “media.”

A useful interface gives each input its own label, preview, and validation message. If the reference image is missing, tell the user that directly instead of returning a generic generation error.

2. Validate media before requesting generation

An accepted file extension does not tell you whether a video meets a model's requirements. Duration, dimensions, frame rate, codec, and file size can each matter.

For developers, the useful distinction is between three states:

Invalid: the file cannot be used and needs a specific explanation.
Needs preparation: it can be adapted, but the user should understand what will change.
Ready: the prepared inputs satisfy the selected workflow's requirements.

Client-side checks provide quick feedback. The server should still validate inputs before dispatching a paid job; a browser check is not a trust boundary. If preparation changes media properties, validate the prepared output too.

This is a suggested sequence, not an API specification:

choose video and reference
  -> inspect media
  -> explain any required preparation
  -> validate prepared inputs
  -> show a generation quote
  -> request user confirmation
  -> submit the job

3. Make the cost boundary visible

Selecting or preparing a file and submitting it for AI processing are different actions. A user should be able to tell which action spends credits.

Show the quote after the relevant inputs and output options are known. If the user replaces the clip or changes output quality, refresh the quote before allowing submission. On the server, verify that the confirmed quote still matches the requested job.

A disabled button should also explain what is missing: a reference image, a compatible video, or a current quote.

4. Give users a review checklist

“Generation completed” means an output is available. It does not establish that the edit is visually good. For a character replacement, useful review questions include:

Does the character remain recognizable throughout the clip?
What happens when the face turns or leaves the frame?
Are hands, clothing, and subject boundaries consistent?
Does the movement still follow the intended performance?
Did the background change in a distracting way?

Start with a short, continuous shot and a clearly visible subject. A complicated shot with overlapping people makes it harder to isolate why an output looks wrong. Use footage and references you have permission to edit.

Where AI Genjutsu fits

AI Genjutsu is our independent web project for this source-video-plus-reference-image workflow. Generation uses paid credits; it is not a free rendering service. It is not affiliated with or endorsed by Higgsfield.

The product page explains the current upload requirements and workflow. The broader design question is useful beyond our project: how can an AI media interface help users understand the inputs, expected changes, and cost before they start a job?

What validation or preview step has saved your users the most failed generations?

Disclosure: this article was generated by an AI agent at the project owner's request, using the project's public product information. It has not been edited by a human.

Why an AI Image Generation Timeout Should Not Automatically Trigger a Retry

dong — Thu, 08 Oct 2026 08:39:53 +0000

An image-generation request can time out even after the provider has accepted the job.

That creates an awkward situation: the application has no result, but another generation may already be running. Automatically repeating the request can create a second paid job.

This article examines that boundary using the current provider adapter in Nano Banana 2.1, a project I work on. It describes implementation choices and remaining failure cases, not a claim that every recovery scenario is solved.

Separate submission from polling

The adapter exposes two operations:

submit() creates a prediction and returns its identifier.
poll() reads the status of that existing prediction.

A simplified version of the interface looks like this:

interface ImageProvider {
  submit(request: ImageRequest): Promise<{ taskId: string }>;

  poll(taskId: string): Promise<
    | { status: "pending" }
    | { status: "completed"; imageUrl: string }
    | { status: "failed"; error: string }
  >;
}

This separation matters because the operations have different consequences.

Repeating a status request asks about the same job. Repeating submission may create another job.

The adapter performs a single creation request and validates that the response contains a usable prediction ID. It does not contain an automatic retry loop around that POST.

A timeout is an unknown outcome

Consider this sequence:

The application sends a creation request.
The provider accepts it.
The connection fails before the application receives the prediction ID.

The application cannot safely infer that nothing happened.

Avoiding an automatic resubmission reduces duplicate-job risk, but it leaves a recovery problem: without the ID, the application cannot use its normal polling path.

A more complete recovery design would need a documented provider idempotency mechanism or another way to reconcile the original request. Those capabilities should be verified rather than assumed.

Validate successful responses too

A succeeded status is not enough by itself.

In this adapter, the output can be a URL string or an array. The code selects the first array entry when necessary, then checks that the result is an HTTPS URL.

Malformed output becomes an explicit error instead of an apparently successful generation with an unusable result.

That check is only basic validation. It does not prove the URL is reachable, contains a valid image, or has been copied into application storage.

Keep error details out of user records

Provider error bodies can contain prompts or reference-image URLs.

For failed predictions, the adapter keeps a small operational error containing the provider, processing stage, category, and failure code. It does not copy the provider's raw error body into the returned failure message.

This preserves enough information to classify the failure without unnecessarily duplicating user input.

Test the uncertainty boundary

Useful tests for this design include:

A creation request fails without returning an ID: no automatic second POST.
A creation response lacks a valid ID: polling does not begin.
A prediction remains in progress: return pending.
A prediction succeeds with malformed output: return an explicit error.
A prediction fails: return a sanitized failure rather than the raw response.

The main design lesson is to distinguish “the request failed” from “the work never started.” In an asynchronous, paid workflow, those are different states.

Disclosure: This article was drafted with AI assistance using the project's current source code. The interface example is simplified for explanation.

What's the simplest way to change a few words baked into an image?

dong — Sun, 27 Sep 2026 14:02:15 +0000

I keep running into a small, specific image-editing need: a screenshot or graphic has one or two outdated words, and I want to fix the copy without taking on the learning curve of a full image editor.

The right approach depends on how the image was made. If the original file still has an editable text layer, changing the words is straightforward. If the text has been flattened into the image, it becomes a retouching problem too: the old letters need to be removed or covered, the background repaired, and the replacement text made to fit. Adobe's guidance explains the editable-text case: https://helpx.adobe.com/photoshop/desktop/text-typography/get-started-with-text/edit-text.html

For someone who only needs this occasionally, what workflow would you recommend? Is there a lightweight tool that handles this narrow job without requiring me to learn a large editor first?

I've been using PhotextAI for this kind of small text change and found it helpful, so I'm sharing it in case it helps someone else: https://photextai.com/ . I'm a user recommending a tool I've found useful, and I'm interested in other simple workflows people use.

Designing a Guest AI Image Generation Flow Without Letting Free Usage Run Wild

dong — Thu, 03 Sep 2026 08:02:42 +0000

Disclosure: I used AI to help organize and edit this article. The implementation details and engineering decisions come from my own project, and I reviewed the final draft for accuracy.

Letting a visitor try an AI image tool before creating an account sounds simple. Give them a text box, call an image API, and show the result.

That version works until real traffic arrives.

Image generation has a direct cost. Requests take long enough for users to refresh, double-click, or close the tab. Providers fail. Workers restart. A person can switch between anonymous and signed-in sessions. If the free path is only a boolean such as hasUsedTrial, it will eventually charge twice, run twice, or become easy to abuse.

I ran into these problems while building the guest flow behind PicEditor, a browser-based AI image editor. The useful lesson was that a free generation should not be treated like a coupon. It should be treated like a small distributed job with a reservation, a lifecycle, and a cost owner.

The request needs a lifecycle

The first design question was not “Is this user free?” It was “What state is this request in?”

I ended up using a short list of states that correspond to things the server can actually prove:

reserved -> pending -> processing -> completed
                                \-> failed

The browser can display queued as part of the user experience, but the source of truth remains on the server. I deliberately avoided fake progress percentages and messages such as “analyzing your idea” when no such step exists.

This matters more than it may seem. If a visitor refreshes the page after submission, the client should reconnect to the same job instead of creating another provider request. If the same anonymous identity submits again while a job is active, the server should return the existing job or reject the duplicate.

Reserve before calling the provider

Before an image request reaches the model provider, the server performs several checks:

Is guest generation currently enabled?
Did the browser complete the anti-bot challenge?
Is this identity or network already over its free allowance?
Does the identity already have a generation in progress?
Is there enough room in the daily provider-cost budget?

The important part is the order. I do not want two concurrent requests to both read “budget available” and then both spend it.

The simplified flow looks like this:

const reservation = await reserveIdentitySlot(identity);

try {
  await reserveCostBudget(estimatedProviderCost);
} catch (error) {
  await restoreIdentitySlot(reservation);
  throw error;
}

The identity claim uses a conflict-safe database write. The budget uses a conditional update that succeeds only while the new reserved total remains under the cap. If the second operation fails, the first reservation is restored.

It is not a magical global transaction. It is a small reservation protocol with an explicit compensation step. That distinction made the failure cases much easier to reason about.

Keep access policy separate from billing

Another decision that helped was separating how a request is allowed to run from how it is paid for.

The generation record carries an access tier:

type AccessTier = 'paid' | 'free_first' | 'free_slow';

The first successful guest generation can enter immediately. Later free requests can use a slower queue. Paid requests follow the credit path.

This is cleaner than sprinkling checks such as if (isGuest) throughout the workflow. The workflow receives a concrete policy and acts on it. It also means signing in does not silently reset a person's completed guest history.

For the free path, the server also fixes the expensive parameters to a known model, resolution, quality, provider, and one output image. Letting the client choose arbitrary settings would make the cost cap meaningless.

The queue is part of the product

I did not want the second free request to hit a dead end. A slower queue is a more honest trade-off: the request exists, has a real execution time, and will eventually run.

The delay is calculated when the job is created and stored with that job. If an administrator changes the queue configuration later, existing jobs keep their original schedule. That prevents the UI from showing a moving target.

The workflow can wait for either of two things:

the free delay to expire;
a verified upgrade event that allows the same logical job to continue sooner.

The second path must not create a replacement provider request. Payment callbacks, page refreshes, and repeated clicks all need to converge on the same job.

Put the expensive work in a durable workflow

An HTTP request is a poor owner for an image-generation job. The connection may disappear long before the provider finishes.

I use a Cloudflare Workflow for the long-running path. The request handler validates the input, creates a pending history record, and enqueues the workflow. From that point, the workflow owns the job:

validate request
  -> reserve guest entitlement and budget
  -> create generation history
  -> enqueue workflow
  -> submit to image provider
  -> poll for completion
  -> store result
  -> finalize history

Provider submission, polling, and storage are retryable steps. The browser only polls the history ID, so reconnecting does not restart the generation.

Paid generations consume credits inside the workflow. If a later step fails, the compensation step refunds the same usage transaction and marks the job failed. Guest jobs do not need a credit refund, but their claim still needs an accurate final state.

Keeping debit and refund under the same workflow owner removed a class of bugs where the API returned an error but a background request continued spending money.

Anonymous should not mean unowned

Guest files still need ownership and privacy.

Reference images are uploaded to private storage and attached to a server-side anonymous identity. The server checks ownership before using a file in a generation request. Generated outputs also belong to that identity rather than living at an untracked public URL.

If the visitor later signs in, the system links the guest claim, history, and files to the verified account. The same completed guest generation still counts after the identity changes.

Anonymous content is temporary. In my current design it is eligible for cleanup after 72 hours, so the product tells visitors to download anything important. “No sign-up” should not be presented as “permanent storage without an account.”

Fail before spending whenever possible

The cheapest provider call is the one that never needs to happen.

File type, file size, ownership, model capabilities, prompt policy, anti-bot verification, concurrency, and budget checks all happen before provider submission. A rejected prompt should not consume the guest allowance. A malformed upload should not create a generation job.

There is still no perfect abuse-prevention rule. IP limits can affect shared networks, identity limits can be evaded, and CAPTCHA adds friction. I found it more useful to layer several imperfect signals and keep a global kill switch than to pretend one identifier is reliable.

What I would keep if I rebuilt it

The code will change, but I would keep these ideas:

Model free usage as a reservation, not a boolean.
Give each generation a durable server-side identity.
Make duplicate requests converge on the same job.
Reserve estimated cost before provider submission.
Put failure compensation beside the work it compensates.
Keep anonymous files private and temporary.
Show only states and waiting times the server can prove.

The surprising part was that the image model was not the hardest component. The hard part was defining who owns a request while the user, the browser, the worker, and the provider can all disappear independently.

Once the free generation became a proper job instead of a marketing exception, the rest of the system became much easier to explain and test.