DEV Community: Image Splitting Field Notes

Designing a Cost-Aware AI Video Workflow: Show the Price Before Render

Image Splitting Field Notes — Sat, 01 Aug 2026 06:52:20 +0000

AI video forms often make the expensive decision feel like a cheap one. A creator chooses a model, duration, resolution, and audio mode, but the interface hides the consequence until after they press Generate.

That is more than a pricing problem. It is a product-state problem: the cost is derived from the same controls that define the output, so it should update in the same interaction loop.

This post explains the pattern I used while building an image-to-video workflow around Grok Imagine 1.5 Preview.

1. Make cost a derived field, not a checkout surprise

For the current Grok workflow, the supported duration is 1–15 seconds. The UI offers 480p and 720p. In this implementation, 480p is charged at 1.6 credits per second and 720p at 3 credits per second, rounded up to a whole credit.

The estimator can stay intentionally small:

type Resolution = "480p" | "720p";

function estimateCredits(
  duration: number,
  resolution: Resolution,
): number {
  const rate = resolution === "720p" ? 3 : 1.6;
  return Math.ceil(duration * rate);
}

The important part is not the formula. It is where the formula runs. Duration and resolution are already controlled form state, so the estimate belongs beside the Generate button and should change immediately when either control changes.

Do not calculate it only on the server and reveal it after submission. The server should still recalculate the authoritative amount, but the client estimate is what lets the user make a decision.

2. Model capabilities should shape the form

A generic video form tends to expose every control for every model. That creates impossible combinations and forces error handling to do work the interface could have prevented.

Instead, describe each model as data:

const grokImagine = {
  modes: ["image-to-video"],
  durations: Array.from({ length: 15 }, (_, index) => index + 1),
  resolutions: ["480p", "720p"],
  audio: "native",
  defaults: {
    duration: 8,
    resolution: "480p",
  },
} as const;

The form then renders only valid choices. Because this model creates video and audio together, there is no separate audio toggle. Hiding a control is better than showing a switch that does nothing.

This also reduces drift between marketing copy, the form, and the API. The same capability object can power validation, defaults, and explanatory text.

3. Design the default around a first successful result

A default is a recommendation. It should not silently consume most of a new user's allowance.

In this example, an 8-second 480p render costs 13 credits. A new account receives 20 credits, so the default can produce one full result with some room left. Moving the same duration to 720p raises the estimate to 24 credits, and the interface makes that trade-off visible before submission.

This is a useful acceptance test:

Can a new user complete the default workflow with the initial allowance?
Does changing resolution visibly change the estimate?
Does an unaffordable combination become obvious before the API call?
Is the default still long enough to demonstrate the product?

Free credits are not useful if they cannot produce a first result.

4. Put guidance next to the expensive choice

The creator should not need a separate pricing page to understand a control. Short, local guidance works better:

Start at 480p while testing motion and framing.
Move to 720p after the prompt is stable.
Keep the first clip short when exploring a new visual direction.
Describe subject motion, camera movement, and environmental motion separately.

This turns cost visibility into workflow advice instead of a warning banner.

5. Revalidate on the server

The preview is advisory. The API must normalize and validate the same settings before creating a provider task.

A safe request path is:

Parse duration as an integer.
Confirm the selected model supports that duration.
Confirm the resolution is in the model's capability list.
Recompute the cost on the server.
Check the current balance.
Deduct credits and create the asynchronous task.
Refund the deduction if the generation fails.

Client and server can share types and configuration, but the server remains authoritative.

6. Test decisions, not just controls

A useful UI test does more than confirm that a dropdown opens. It verifies the decision loop:

The 8-second 480p default shows 13 credits.
Switching to 720p shows 24 credits.
A 1-second 480p clip rounds up to 2 credits.
Unsupported durations never appear.
The submitted payload matches the estimate the user approved.
A failed generation restores the deducted balance.

These checks protect the promise the interface makes.

Live reference

The finished interaction is available in the MICT Grok image-to-video workflow. I am the builder of MICT; I am linking it as the concrete implementation discussed above, not as an independent recommendation.

Disclosure

I used AI assistance to edit the structure and wording of this article. I verified the technical details and code examples against the implementation before publishing.

Designing a Reliable Async AI Video Pipeline in TypeScript

Image Splitting Field Notes — Fri, 31 Jul 2026 03:46:32 +0000

Calling an AI video API looks simple in a demo:

Send a prompt.
Wait for a response.
Show the video.

In production, the model rarely returns a video in the original HTTP request. It creates a remote job, gives you an external task ID, moves through provider-specific states, and eventually returns either a media URL or an error. Your application has to keep user state, billing state, moderation state, and provider state consistent while that happens.

This article presents a provider-neutral reference architecture for products such as MICT, an AI image and short-video workspace. The code samples are illustrative rather than a verbatim description of MICT's production implementation. The useful part is not a particular API call; it is the set of boundaries around that call.

The real workflow is a state machine

A reliable generation request has more stages than “loading” and “done”:

request
  -> authenticate
  -> validate model settings
  -> moderate input
  -> calculate cost
  -> create and persist local task
  -> reserve or deduct credits
  -> create provider task
  -> attach external task ID
  -> poll provider
  -> normalize provider state
  -> moderate output
  -> complete or fail
  -> refund when required

Treating this as an explicit state machine gives every layer a shared vocabulary. A compact internal set is usually enough:

type GenerationStatus =
  | "running"
  | "processing"
  | "completed"
  | "failed";

Providers can keep their own vocabulary at the edge:

function mapProviderState(state: string): GenerationStatus {
  switch (state) {
    case "waiting":
    case "queuing":
      return "running";
    case "generating":
      return "processing";
    case "success":
      return "completed";
    case "fail":
      return "failed";
    default:
      return "running";
  }
}

The important design choice is that the rest of the product never branches on every provider's spelling. The adapter does that once.

Keep local and external task IDs separate

Create and persist your own task before calling the provider.

const taskId = createLocalTaskId();

await persistGeneration({
  taskId,
  userId,
  status: "running",
});

const externalTask = await provider.createTask(providerModel, input);

await attachExternalTaskId({
  taskId,
  externalTaskId: externalTask.id,
});

The local ID belongs to your product. Use it for:

authorization checks;
generation history;
credit transactions;
support references;
analytics;
idempotency.

The external ID belongs to the provider. Use it only when querying or canceling the remote job.

This separation matters when providers change, when one provider is temporarily replaced, or when a support ticket refers to a local job that never received an external task ID.

Validate settings before money moves

Different video models accept different combinations of mode, duration, resolution, aspect ratio, output count, and audio settings. Do not let the client invent those combinations.

Keep capabilities in a server-side model configuration:

type ModelConfig = {
  modes: Array<"t2v" | "i2v">;
  durations: number[];
  resolutions: string[];
  aspectRatios: string[];
  calculateCredits(input: {
    duration: number;
    resolution: string;
    outputCount: number;
  }): number;
};

Then reject unsupported values before moderation, billing, or provider submission:

if (!config.modes.includes(mode)) {
  throw new RequestError("Unsupported generation mode");
}

if (!config.resolutions.includes(resolution)) {
  throw new RequestError("Unsupported resolution");
}

Client-side validation is useful for feedback. Server-side validation is the boundary that protects your bill and your data.

Put moderation before generation

Input moderation should happen before the provider task is created and before credits are charged.

const moderation = await moderateRequest({
  userId,
  model,
  mode,
  prompt,
  imageUrl,
});

if (!moderation.allowed) {
  return {
    ok: false,
    code: moderation.code,
    creditsCharged: false,
  };
}

This avoids paying the upstream provider for a request your own policy would reject. It also lets the UI distinguish a policy decision from a technical failure.

Output moderation is a separate gate. A provider can successfully generate media that your application should not release. The output should not become completed until that gate passes.

provider success
  -> extract result URL
  -> moderate result
  -> completed

provider success
  -> extract result URL
  -> output blocked
  -> failed with a policy-safe message

Do not collapse input moderation, provider policy errors, and output moderation into one generic “generation failed” toast. They have different retry rules and support paths.

Make credit operations idempotent

The most damaging bugs in an AI generation product are often financial state bugs:

the provider rejected the request but credits stayed deducted;
polling ran twice and refunded twice;
a database write failed after the provider task started;
the browser retried a request after a network timeout.

Every charge should have a stable source key:

await decreaseCredits({
  userId,
  amount: creditCost,
  sourceType: "generation_charge",
  sourceId: taskId,
});

A refund should reference that same source:

await refundCreditsBySource({
  sourceType: "generation_charge",
  sourceId: taskId,
  transactionType: "refund",
});

The database should enforce uniqueness for the relevant source or transaction key. Application-level if (!refunded) checks are helpful, but they are not enough under concurrent polling.

You need at least two refund paths:

The provider task could not be created.
The provider accepted the task, but it later reached a terminal failure.

try {
  const external = await provider.createTask(modelId, input);
  await attachExternalTaskId({ taskId, externalTaskId: external.id });
} catch (error) {
  await refundByGenerationSource(taskId);
  throw error;
}

For terminal failure during polling:

if (status === "failed") {
  await refundByGenerationSource(taskId);
  await markGenerationFailed(taskId, publicErrorMessage);
}

When refunds are idempotent, repeated polling becomes much less frightening.

Polling should be boring

WebSockets can improve perceived responsiveness, but polling is often the most robust first implementation for provider jobs that take seconds or minutes.

The status endpoint should:

authenticate the request;
load the local generation;
verify that it belongs to the user;
return immediately for local terminal states;
query the provider only for non-terminal jobs;
normalize the result;
update local state;
return a small, stable response.

type StatusResponse = {
  status: GenerationStatus;
  progress?: number;
  resultUrl?: string;
  errorCode?: string;
  errorMessage?: string;
};

The client does not need the provider's raw payload. Raw payloads leak implementation details and make frontend behavior depend on unstable third-party schemas.

A reasonable browser loop looks like this:

async function waitForGeneration(taskId: string) {
  while (true) {
    const result = await getStatus(taskId);

    if (result.status === "completed") return result;
    if (result.status === "failed") throw new Error(result.errorMessage);

    await delay(5000);
  }
}

Production code should also stop polling when the component unmounts, pause or slow down in a hidden tab, and apply a maximum client-side wait. The job can continue on the server even if the browser stops asking.

Parse provider results defensively

Even one provider may return different result shapes across models:

{ "resultUrls": ["https://..."] }

{ "video_url": "https://..." }

{ "output": [{ "url": "https://..." }] }

Keep result extraction inside the adapter and accept only a non-empty string:

function extractResultUrl(raw: string): string | undefined {
  const result = JSON.parse(raw);
  const candidates = [
    result.resultUrls?.[0],
    result.urls?.[0],
    result.output?.[0]?.url,
    result.videoUrl,
    result.video_url,
  ];

  return candidates.find(
    (value): value is string =>
      typeof value === "string" && value.length > 0
  );
}

A provider saying success without a usable result URL is not a completed user experience. Keep the job non-terminal or move it to a clearly diagnosed failure path.

Do not let a late success overwrite a failure

Asynchronous systems can produce awkward orderings:

a job appears successful;
output moderation starts;
another process marks the generation failed;
a late update tries to mark it completed.

Use a conditional update:

update generations
set status = 'completed', result_url = $1
where task_id = $2
  and status <> 'failed';

If the update affects zero rows, reload the current state and return that state. Terminal safety decisions should win over late success events.

Preserve error categories

Users need different actions for different errors:

Error category	User action
insufficient credits	add credits or choose cheaper settings
provider unavailable	retry later
input policy blocked	revise the request
provider policy blocked	revise the request
output policy blocked	contact support only if the decision seems wrong
unknown technical failure	retry or contact support with the task ID

Return stable error codes and separately maintain a user-safe message:

throw new RequestError(
  "We could not start this generation right now.",
  "provider_unavailable",
  { creditsCharged: false }
);

Do not expose upstream account balances, internal model routes, or raw policy messages in the browser.

What to test

A happy-path video is not enough. Test the state transitions:

invalid model settings do not charge credits;
input moderation rejection does not charge credits;
provider creation failure refunds once;
provider terminal failure refunds once;
repeated status polling does not duplicate refunds;
one user cannot read another user's task;
provider success without a URL does not become completed;
output moderation failure cannot be overwritten by a late success;
terminal local states do not keep querying the provider;
unknown provider states stay recoverable.

The best tests target invariants:

one accepted generation <= one charge
one failed charged generation <= one refund
completed => usable result URL
failed-by-policy => result URL is not released
task owner => only user allowed to read status

The larger lesson

An AI video interface is a distributed system with a creative UI attached to it. The model call is only one step. The product becomes trustworthy when every other step—validation, authorization, billing, polling, moderation, and failure recovery—has an explicit boundary.

Start with a small internal state machine. Keep provider vocabulary at the edge. Give every charge a stable source. Make refunds idempotent. Treat moderation as part of the lifecycle, not a preflight checkbox. Then make polling intentionally boring.

That foundation is less glamorous than a generation demo, but it is what lets the demo become a product.

Disclosure: This article was prepared for MICT, which is referenced once as the product context for this architecture. AI tools assisted with drafting and editing; the code, claims, and final text were reviewed before publication.

The Pixel Math Behind Seamless Instagram Carousels

Image Splitting Field Notes — Sat, 18 Jul 2026 08:08:14 +0000

A seamless carousel is a geometry problem before it is an export problem.

If one portrait slide is 1080 × 1350 px, the master canvas must be an exact multiple of 1080 pixels wide:

master_width = slide_width × slide_count
master_height = slide_height

Examples:

Slides	Master canvas
3	3240 × 1350
5	5400 × 1350
7	7560 × 1350

Why seams break

The most common failures happen before slicing:

The master image was resized to a width that does not divide into whole pixels.
Text, faces, or logos sit directly on a cut boundary.
Individual tiles are resized again after export.
Filenames do not preserve the posting order.
Different compression settings are applied to different tiles.

A reliable export workflow

Choose the final slide ratio.
Multiply the slide width by the number of slides.
Add guides at every slide boundary.
Finish the composition on the single master canvas.
Export the master once.
Split it into equal horizontal sections.
Test the numbered pieces in an Instagram draft on the actual phone.

For private client artwork, the safest splitter is one that does not upload the source image. I built Image Splitter Online around that constraint: the image is processed locally in the browser, cut lines are previewed before export, and PNG, JPG, WebP, or ZIP output is available without an account.

A small implementation detail

If you are building your own splitter, distribute remainder pixels deterministically instead of rounding every tile independently. For a width W and N columns:

const base = Math.floor(W / N);
const remainder = W % N;

const widths = Array.from(
  { length: N },
  (_, i) => base + (i < remainder ? 1 : 0)
);

That guarantees the exported widths sum back to the source width. It also avoids the one-pixel gaps or overlaps that appear when every cut boundary is rounded separately.

The final check is visual: reconstruct the row from the exported files and verify it matches the master exactly before publishing.