The obvious implementation — a balance column plus a nightly job that expires old credits — breaks in annoying ways: the job runs late, a webhook arrives twice, a refund lands after a renewal, and suddenly someone has credits they shouldn't or is missing ones they paid for.

This is how I ended up modelling it on Cloudflare D1 (SQLite) for AI Trend Video, where every generated video costs 2 credits. The short version: store grants, not balances, and let the database compute what is spendable right now.

Rules first

Before any SQL I wrote the rules down, because every bug I'd had before was a rule I hadn't decided:

1. One-time credits never expire.
2. Each paid subscription invoice grants one period of credits. They expire at the end of that period. No rollover.
3. A future period (e.g. the remaining months of a yearly plan) is not spendable before it starts.
4. Spend subscription credits first, earliest expiry first, then permanent credits.
5. If a generation fails, every reserved credit goes back to the source it came from — and a refund into an expired period does not resurrect it.
6. Expiry must never depend on a scheduled job.

Two tables

Permanent credits are a plain counter:

CREATE TABLE credits (
  account_id TEXT PRIMARY KEY REFERENCES accounts(id),
  balance    INTEGER NOT NULL DEFAULT 0 CHECK (balance >= 0)
);

Subscription credits are one row per paid invoice, with its own window:

CREATE TABLE subscription_periods (
  invoice_id      TEXT PRIMARY KEY,          -- Stripe invoice: idempotency for free
  subscription_id TEXT NOT NULL,
  account_id      TEXT NOT NULL,
  starts_at       INTEGER NOT NULL,
  ends_at         INTEGER NOT NULL CHECK (ends_at > starts_at),
  granted         INTEGER NOT NULL CHECK (granted > 0),
  remaining       INTEGER NOT NULL CHECK (remaining >= 0),
  UNIQUE (subscription_id, starts_at)
);

Using the invoice ID as the primary key means a duplicated invoice.paid webhook simply fails to insert. The UNIQUE (subscription_id, starts_at) catches the other path where the same period could be granted twice (checkout-return reconciliation racing the webhook).

A yearly plan doesn't get one big row: each paid yearly invoice creates 12 one-month rows, so a yearly subscriber gets exactly the monthly allowance, and a partial refund can revoke months from the last one backwards.

The wallet is a view

Nothing ever "expires" credits. The view just doesn't count periods that aren't live at query time:

CREATE VIEW wallet AS
SELECT c.account_id,
  c.balance AS permanent_credits,
  COALESCE((SELECT SUM(remaining) FROM subscription_periods p
            WHERE p.account_id = c.account_id
              AND p.starts_at <= unixepoch() AND p.ends_at > unixepoch()), 0)
    AS subscription_credits,
  (SELECT MIN(ends_at) FROM subscription_periods p
   WHERE p.account_id = c.account_id
     AND p.starts_at <= unixepoch() AND p.ends_at > unixepoch())
    AS subscription_expires_at
FROM credits c;

Rules 2, 3 and 6 are now just a WHERE clause. The UI reads subscription_expires_at to show "12 credits, expire Nov 26".

Spending: a trigger with a window function

Creating a job is spending. An AFTER INSERT trigger on jobs reserves the cost, and aborts the insert if the wallet can't cover it — so there is no way to create a job without paying for it, even under concurrent requests.

The interesting part is splitting the cost across several live periods in expiry order. A running sum does that:

CREATE TRIGGER reserve_credits AFTER INSERT ON jobs BEGIN
  SELECT RAISE(ABORT, 'insufficient_credits')
  WHERE (SELECT permanent_credits + subscription_credits
         FROM wallet WHERE account_id = NEW.account_id) < NEW.credits_cost;

  -- take from live periods, earliest expiry first
  INSERT INTO job_subscription_credits (job_id, invoice_id, credits)
  SELECT NEW.id, invoice_id, MIN(remaining, MAX(0, NEW.credits_cost - previous))
  FROM (
    SELECT invoice_id, remaining,
      COALESCE(SUM(remaining) OVER (ORDER BY ends_at, invoice_id
        ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS previous
    FROM subscription_periods
    WHERE account_id = NEW.account_id
      AND starts_at <= unixepoch() AND ends_at > unixepoch() AND remaining > 0
  )
  WHERE NEW.credits_cost > previous;

  UPDATE subscription_periods
  SET remaining = remaining - (SELECT credits FROM job_subscription_credits
                               WHERE job_id = NEW.id AND invoice_id = subscription_periods.invoice_id)
  WHERE invoice_id IN (SELECT invoice_id FROM job_subscription_credits WHERE job_id = NEW.id);

  -- whatever subscriptions didn't cover comes from permanent credits
  UPDATE credits
  SET balance = balance - NEW.credits_cost
      + COALESCE((SELECT SUM(credits) FROM job_subscription_credits WHERE job_id = NEW.id), 0)
  WHERE account_id = NEW.account_id;
END;

previous is "how much the earlier-expiring periods already cover". Each period gives min(remaining, cost - previous) until the cost is met. The CHECK (balance >= 0) is a last line of defence.

The job_subscription_credits table is the receipt: it records exactly which invoice paid for which part of which job. That receipt is what makes rule 5 possible.

Refunding exactly once, to the right place

Video generation fails sometimes. When a job flips to failed, a second trigger returns the credits — once:

CREATE TRIGGER refund_failed AFTER UPDATE OF status ON jobs
WHEN NEW.status = 'failed' AND OLD.status != 'failed' AND OLD.refunded = 0 BEGIN
  -- subscription part goes back to its own period (still bound by that period's window)
  UPDATE subscription_periods SET remaining = remaining +
    (SELECT credits FROM job_subscription_credits
     WHERE job_id = NEW.id AND invoice_id = subscription_periods.invoice_id)
  WHERE invoice_id IN (SELECT invoice_id FROM job_subscription_credits WHERE job_id = NEW.id);

  -- permanent part goes back to permanent
  UPDATE credits SET balance = balance + NEW.credits_cost
    - COALESCE((SELECT SUM(credits) FROM job_subscription_credits WHERE job_id = NEW.id), 0)
  WHERE account_id = NEW.account_id;

  UPDATE jobs SET refunded = 1 WHERE id = NEW.id;
END;

Because credits return to their original period row, a failure that's discovered after the period ended returns credits into a row the wallet view no longer counts. No accidental conversion of expiring credits into permanent ones, no extending expiry.

The OLD.refunded = 0 guard plus refunded = 1 makes it idempotent: a late "failed" webhook arriving after a 5-minute recovery cron already handled the job does nothing.

(My production version recomputes remaining from granted - revoked - spent instead of adding back, so it also stays correct when a Stripe refund has revoked part of the same period in between. Same idea, more terms.)

Money refunds

I never issue refunds from code; they're done by hand in Stripe. The charge.refunded webhook then claws back credits: a monthly refund revokes a proportional share of that period (rounded down); a yearly refund revokes months from the last one backwards. Because grants are rows, this is an update on specific rows rather than guessing what to subtract from a single balance.

Was it worth it?

The schema is bigger than balance INTEGER. But:

• there is no expiry cron to forget, run late, or run twice;
• every webhook is idempotent by primary key;
• "why do I have 6 credits?" is answerable with one query over grants and receipts;
• the app code can't overspend, because the database refuses the insert.

If you're building anything with credits plus subscriptions — AI generation, API calls, exports — I'd start with grants + a view from day one.

You can see the wallet in action (account menu shows permanent credits, monthly credits and their expiry) on aitrendvideo.net. Questions about the Stripe side are welcome in the comments.

The fix doesn't need a bigger model. It's a compositing step you can do entirely in the browser with the Canvas API. In this tutorial we'll build it piece by piece:

1. A brush tool that records strokes in image coordinates, not screen coordinates

2. Two masks from the same strokes: one for the model, one for compositing

3. A compositing function that merges only the brushed pixels back into the full-resolution original

4. The practical limits: mobile memory, seams, and retries

This is the approach I use in production at peopleremover.com, a browser tool to erase people from photos. (If you want the architecture story and the Cloudflare Workers side, I wrote that up on DEV. This post is only the front-end pixel work.)

Step 1: Record strokes in image space

The editor canvas is displayed at whatever size fits the screen, maybe 800px wide, while the image underneath is 6000px wide. If you draw the mask directly on the display canvas, you'd be stuck with an 800px mask.

Instead, store strokes as data in the original image's coordinate system and render them at any size you need later.

type Point = { x: number; y: number };
type Stroke = { points: Point[]; radius: number }; // radius in image pixels

const strokes: Stroke[] = [];
let current: Stroke | null = null;

function toImageSpace(e: PointerEvent, canvas: HTMLCanvasElement, imgW: number): Point {
  const rect = canvas.getBoundingClientRect();
  const scale = imgW / rect.width; // display px -> image px
  return {
    x: (e.clientX - rect.left) * scale,
    y: (e.clientY - rect.top) * scale,
  };
}

canvas.addEventListener('pointerdown', (e) => {
  const displayRadius = brushSize / 2;              // what the user sees
  const scale = image.width / canvas.getBoundingClientRect().width;
  current = { points: [toImageSpace(e, canvas, image.width)], radius: displayRadius * scale };
  strokes.push(current);
});

canvas.addEventListener('pointermove', (e) => {
  if (!current) return;
  current.points.push(toImageSpace(e, canvas, image.width));
  redrawOverlay(); // render strokes semi-transparent over the preview
});

canvas.addEventListener('pointerup', () => { current = null; });

Keeping strokes as data also gives you undo for free: strokes.pop() and redraw.

Step 2: Render two masks from the same strokes

You need the selection in two different formats:

• Model mask: an opaque black-and-white image, where white means "regenerate" and black means "keep". This is what most inpainting APIs expect.

• Alpha mask: a transparent image where the brushed area is opaque. This is what Canvas compositing expects.

A common mistake is making the black-and-white mask and then trying to use it for compositing. Canvas composite operations read the alpha channel, not brightness, so a black pixel counts as fully opaque. Rendering both from the stroke list avoids a slow pixel-by-pixel conversion.

function renderStrokes(
  ctx: OffscreenCanvasRenderingContext2D,
  strokes: Stroke[],
  color: string
) {
  ctx.strokeStyle = color;
  ctx.fillStyle = color;
  ctx.lineCap = 'round';
  ctx.lineJoin = 'round';
  for (const s of strokes) {
    ctx.lineWidth = s.radius * 2;
    ctx.beginPath();
    if (s.points.length === 1) {
      // a single tap: draw a dot
      ctx.arc(s.points[0].x, s.points[0].y, s.radius, 0, Math.PI * 2);
      ctx.fill();
      continue;
    }
    ctx.moveTo(s.points[0].x, s.points[0].y);
    for (const p of s.points.slice(1)) ctx.lineTo(p.x, p.y);
    ctx.stroke();
  }
}

function buildMasks(w: number, h: number, strokes: Stroke[]) {
  // Model mask: black background, white strokes
  const model = new OffscreenCanvas(w, h);
  const mctx = model.getContext('2d')!;
  mctx.fillStyle = '#000';
  mctx.fillRect(0, 0, w, h);
  renderStrokes(mctx, strokes, '#fff');

  // Alpha mask: transparent background, opaque strokes
  const alpha = new OffscreenCanvas(w, h);
  renderStrokes(alpha.getContext('2d')!, strokes, '#000');

  return { model, alpha };
}

Canvas antialiases stroke edges, so the alpha mask comes with a one- or two-pixel soft edge built in. That's usually enough to hide the seam without growing the selection.

Step 3: Call the model

The model gets the full frame plus the model mask. It will probably process at a lower resolution than your original, and that's fine. Send it whatever it accepts and don't try to fight it.

One detail matters more than it looks: give every request an idempotency key. Mobile networks drop requests constantly, and users double-tap buttons. Without a stable ID, a retry creates a second paid generation.

// Create the ID once per edit and reuse it on every retry of that edit.
async function requestInpaint(image: Blob, mask: Blob, requestId: string): Promise<string> {
  const form = new FormData();
  form.append('image', image, 'image.png');
  form.append('mask', mask, 'mask.png');
  form.append('requestId', requestId);

  const res = await fetch('/api/inpaint', { method: 'POST', body: form });
  if (!res.ok) throw new Error(`Inpaint failed: ${res.status}`);
  const { jobId } = await res.json();
  return jobId; // poll this until the result is ready
}

const requestId = crypto.randomUUID();
const jobId = await requestInpaint(imageBlob, maskBlob, requestId);

On the server, if a requestId has already been seen, return the existing job instead of creating a new one.

Step 4: Composite only the brushed pixels

This is the core of the whole technique. Start from the untouched original, scale the model output up to full size, clip it to the alpha mask, and draw it on top.

async function compositeResult(
  original: ImageBitmap,
  generated: ImageBitmap,
  alphaMask: OffscreenCanvas
): Promise<Blob> {
  const { width: w, height: h } = original;

  // Generated pixels, upscaled and clipped to the selection
  const patch = new OffscreenCanvas(w, h);
  const pctx = patch.getContext('2d')!;
  pctx.imageSmoothingQuality = 'high';
  pctx.drawImage(generated, 0, 0, w, h);
  pctx.globalCompositeOperation = 'destination-in';
  pctx.drawImage(alphaMask, 0, 0);

  // Original + patch
  const out = new OffscreenCanvas(w, h);
  const octx = out.getContext('2d')!;
  octx.drawImage(original, 0, 0);
  octx.drawImage(patch, 0, 0);

  return out.convertToBlob({ type: 'image/png' });
}

destination-in keeps the existing content (the generated image) only where the new drawing (the mask) is opaque. Everything outside the brush comes straight from original, pixel for pixel.

For the next edit, use this composite as the new "original" so edits stack instead of resetting.

Why the patch still looks sharp enough

The brushed area is generated at, say, 1024px and stretched across a 6000px frame, so inside the selection you're looking at upscaled pixels. In practice this works better than you'd expect. Inpainted areas are usually background: sky, pavement, grass, walls, where low detail is less noticeable. On large photos where you'll zoom in or print, generating at 2K noticeably improves the patch. That's the reasoning behind offering an HD mode instead of upscaling the whole image.

Step 5: The limits you will hit

Canvas memory on phones. A 25-megapixel image is about 100 MB of raw RGBA per canvas, and this pipeline holds several at once: original, patch, output and masks. iOS Safari will refuse to allocate large canvases and fail with no helpful error. Cap your input size (I use 25 MP / 20 MB), check that getContext actually returned a context, and show a clear error instead of producing a blank file.

Color space and metadata. convertToBlob writes a PNG without EXIF or ICC profiles, and the pixels come from the browser's decoded canvas color space. For most photos nobody will notice. Photographers who work in wide-gamut profiles will, so say so in your UI.

Shadows and reflections. This one is about the user, not the code, but it causes the most "the AI failed" complaints. If someone brushes a person but not their shadow, the model can't remove what it wasn't told about. Teaching users to include shadows solves more quality issues than any model upgrade. I put together a step-by-step guide to removing people from photos with mask examples for exactly this reason.

Beyond people

Nothing in this pipeline is specific to people. The same strokes → masks → model → composite flow handles:

• Clutter like bins, wires, cars and signs, anything you want to remove unwanted objects from pictures

• Date stamps, captions and overlaid words, for erasing text from images (thin strokes work best here)

On mobile, the built-in tools on newer phones (iPhone Clean Up, Magic Eraser, Galaxy AI) run similar pipelines on-device. I compared them with browser-based options in a roundup of phone apps for removing people from photos if you're curious how they stack up.

Wrap-up

The main takeaway: don't let the model's resolution become your output resolution. Generate small, composite big, and keep your original pixels as the source of truth. It takes about 60 lines of Canvas code and makes a bigger difference than switching models.

If you want to see the result, People Remover runs exactly this flow. Upload a photo, brush, and compare the full-size download against your original. Questions about the Canvas side, or better approaches to edge blending? Leave a comment.

So I decided to build a unified layer on top of all of them — a single interface where users could pick the right model for the right job without managing multiple accounts, API keys, or pricing spreadsheets.

This post is a technical breakdown of how I architected that pipeline, the abstraction challenges I hit, and why I ended up with a Next.js + Supabase stack orchestrating models from Replicate, Runway, and others.

The Core Problem: Every API Speaks a Different Language

If you've ever integrated more than one generative video API, you know the pain. Request payloads differ wildly:

• Model A wants a prompt string and a num_frames integer.

• Model B uses text instead of prompt, and measures duration in seconds, not frames.

• Model C requires a base64-encoded image for image-to-video, while Model D only accepts a public URL.

• Some return a polling URL. Others return a webhook endpoint. Some just block for 90 seconds.

My first instinct was to write thin adapters inside my route handlers. That lasted about three models before the code became a mess of if/else branches.

The Architecture I Landed On

I settled on a three-layer architecture:

plain

User Request → Validation Layer → Orchestrator → Model Adapter → Provider API
                     ↓
            Supabase (Queue + Storage)

Next.js (App Router) handles the frontend and API routes.
Supabase stores user jobs, credits, and generated asset metadata.
Vercel hosts everything with edge functions for low-latency validation.

The key insight was treating each model as a plugin that implements a common interface:

TypeScript

// lib/video-models/types.ts
interface VideoModelAdapter {
  id: string;
  name: string;
  supports: ('text-to-video' | 'image-to-video')[];
  
  // Normalize user input into provider-specific payload
  buildPayload(input: UnifiedInput): ProviderPayload;
  
  // Normalize provider response into our standard job format
  parseResponse(raw: unknown): JobResult;
  
  // Some models are fast, some are slow. We track this per adapter.
  estimatedDuration: number; // in minutes
}

This means adding a new model is just writing a new adapter file. No touching the core orchestrator.

Handling the Async Nature of Video Generation

Video generation isn't instant. Even the fastest models I work with take a minute or two. The slow ones can run for several minutes.

I initially tried synchronous API routes with maxDuration cranked up on Vercel. That was a mistake. Timeouts, cold starts, and failed retries made the UX terrible.

Now the flow looks like this:

1. User submits a request.

2. We validate credits, run content moderation (more on that below), and enqueue a job in Supabase.

3. The API returns immediately with a jobId.

4. A Vercel Cron job polls pending jobs and dispatches them to the right adapter.

5. When the provider finishes, a webhook updates the job status and pushes the result URL to the client via Supabase Realtime.

TypeScript

// app/api/video/generate/route.ts
export async function POST(req: Request) {
  const body = await req.json();
  
  // 1. Validate user credits via Supabase
  const { data: user } = await supabase
    .from('users')
    .select('credits')
    .eq('id', userId)
    .single();
    
  if (!user || user.credits < modelCost) {
    return Response.json({ error: 'Insufficient credits' }, { status: 402 });
  }

  // 2. Moderation check before burning credits
  const moderation = await moderateContent(body.prompt);
  if (moderation.flagged) {
    // We don't deduct credits for policy violations
    return Response.json({ error: 'Content violates usage policy' }, { status: 400 });
  }

  // 3. Create job record
  const { data: job } = await supabase
    .from('jobs')
    .insert({
      user_id: userId,
      model: body.model,
      status: 'pending',
      input: body,
    })
    .select()
    .single();

  return Response.json({ jobId: job.id, status: 'pending' });
}

Content Moderation: Don't Let Users Burn Your Budget

This was a hard lesson. Early on, a few users submitted prompts that generated NSFW content. The upstream provider still charged me for the inference. I ate the cost, and the user got a free video.

Now I run moderation before the job enters the queue. I use Hive AI's moderation API to scan both text prompts and input images. If it flags something, we reject immediately — no credits deducted, no API call made.

It's a small latency hit on submission (a few hundred milliseconds), but it saves real money on the backend.

The Prompt Translation Problem

Here's something nobody tells you: the same prompt produces wildly different results across models.

"A cyberpunk cat walking through a neon-lit street, cinematic lighting, 4k"

• One model gives you a beautiful 5-second clip.

• Another model ignores the "cinematic lighting" entirely and produces a flat render.

• A third model interprets "4k" as a style token and breaks the composition.

I don't try to "fix" prompts automatically — that feels like a black box users can't trust. Instead, I expose model-specific prompt tips in the UI and let users iterate. The adapter layer just passes the prompt through faithfully. The only transformation I do is stripping provider-incompatible parameters (like aspect ratios some models don't support).

Image-to-Video: The URL vs. Base64 Headache

Several providers require a publicly accessible image URL for image-to-video generation. But users upload images from their local machine.

My solution: when a user uploads an image, I immediately store it in Supabase Storage with a public URL, then pass that URL to the provider. The adapter doesn't care where the image came from — it just receives a imageUrl string in the normalized input.

TypeScript

// Inside the image-to-video adapter
async buildPayload(input: UnifiedInput): Promise<ProviderPayload> {
  return {
    image: input.imageUrl, // Already a public Supabase Storage URL
    prompt: input.prompt,
    num_frames: 81, // Provider-specific default
  };
}

What I'd Do Differently

1. Start with the queue architecture. I wasted time trying synchronous flows. Video generation is inherently async. Embrace it from day one.

2. Track per-model costs obsessively. I now log every inference call with provider, duration, and cost. It made pricing my credit packs much easier when I moved to Creem for payments.

3. Don't over-abstract too early. My first adapter interface had 12 methods. I trimmed it to 4. You only really need: buildPayload, parseResponse, checkStatus, and cancelJob.

Wrapping Up

Building this pipeline taught me that the hard part of AI video tools isn't the AI — it's the orchestration. Normalizing APIs, handling failures gracefully, and keeping users informed while their videos render in minutes is where the engineering effort actually lives.

If you're building something similar and want to compare notes, feel free to reach out. And if you're curious to see the end result, I've been shipping it live at https://www.froging.ai — a unified AI video generator where you can switch between models without switching tabs.

I ran into this repeatedly while generating avatars for side projects and team pages. The faces were always off-center, the shoulders got cropped out, or the detail vanished after platform compression. So I built Square Face Generator — an AI Avatar Generator specifically designed for the constraints of profile pictures across every platform.

Here is why generic image generators fail at avatars, and how I fixed it.

The Square Crop Problem

When you prompt a standard image model with "professional headshot, 1:1 ratio," two things usually go wrong:

1. Composition drift: The model was trained predominantly on 3:4 and 16:9 photography. It centers the body, not the face, leaving too much headroom or cutting off the chin after a square crop.

2. Detail loss at small sizes: Avatars are often viewed as tiny circles or squares. A model optimized for 1024×1024 landscape art wastes tokens on background detail you will never see.

The result? You generate ten images, pick the best one, open Photoshop, manually reframe it, and hope the face survives the compression. That is not a workflow; it is a chore.

Designing an AI Avatar Generator for Square Crops

I approached Square Face Generator as a specialized pipeline rather than a generic wrapper around Stable Diffusion or Flux. The core differences:

1. Face-Centered Composition

The prompt engineering and LoRA fine-tuning both bias toward tight facial framing. The model learns that "avatar" means "face fills 70% of the canvas," not "person standing in a field."

2. Native 1:1 Output

Instead of generating a large image and cropping down, we generate at the target square resolution. This preserves facial detail and avoids the "zoomed in" blur you get from aggressive down-cropping.

3. Style Versatility

Because avatars serve different contexts, the AI Avatar Generator supports multiple aesthetic modes:

• Photorealistic — for LinkedIn and professional profiles

• Pixel art / 8-bit — for gaming communities and retro branding

• 3D render — for Metaverse and VRChat identities

• Minimalist flat — for corporate team pages

Each style maintains the same square-face composition rules, so your avatar looks intentional rather than accidental.

Real Use Cases Where Square Avatars Matter

I originally thought this was a niche problem. It is not.

One game developer used this AI avatar generator to produce 500 NPC profile icons for a Steam game in a single afternoon. A marketing team generated consistent 1:1 team avatars for their "About Us" page without hiring a photographer.

The Technical Stack (For Fellow Builders)

If you are curious how the pipeline works under the hood:

• Next.js frontend for instant preview and drag-to-download

• Supabase for auth and lightweight usage tracking

• ComfyUI + FLUX.1-dev with a custom LoRA trained on tightly cropped portrait photography

• Vercel edge caching for sub-second generation previews

• Output locked to 1:1 aspect ratio with face detection post-processing as a safety net

The entire stack is optimized for one job: generate a square face that looks good everywhere. No bloat, no unrelated features.

Try It Yourself

If you have ever uploaded an AI-generated portrait only to watch the platform crop off your eyebrows, you know the pain.

You can generate a perfect square avatar in seconds at squarefacegenerator.ai. The AI Avatar Generator is free to try — no account required for your first few generations. Pick a style, describe the look you want, and download a 1:1 image ready for any platform.

What Is Next

We are shipping two features based on early feedback:

• Batch generation — upload a CSV of names/roles and get a matched set of team avatars

• API access — integrate the square-face pipeline into your own app or game

If you have a use case that needs square avatars at scale, leave a comment. I am actively prioritizing the roadmap based on what builders actually need.

Resources

• Square Face Generator — AI Avatar Generator optimized for 1:1 square profile pictures

• This Person Does Not Exist — Classic random face generator (no control over style)

• Aragon AI — Professional headshot generator (great for photos, not stylized avatars)

I build focused AI tools at LuTa Tech. Follow for more write-ups on generative media, Next.js architecture, and shipping fast.

I spent the last few months building AI Picture Checker — an AI Image Detector that identifies not just whether an image is synthetic, but which model likely created it. Here is what I learned along the way, and how the tool works under the hood.

Why Existing Tools Fall Short

Most AI image detectors on the market give you a simple "AI vs Real" percentage. That is useful, but not enough. When you are moderating a marketplace or verifying a news photo, you need context:

• Was this created by Midjourney (characteristic smoothing and texture repetition)?

• Does it carry DALL·E's subtle color banding?

• Or is it a Flux image with its distinct micro-texture patterns?

Generic classifiers often miss these nuances because they are trained on broad "synthetic vs authentic" labels without model-specific fingerprints.

How Our AI Image Detector Works

The core of AI Picture Checker is a multi-task deep learning pipeline trained on a curated dataset of millions of images:

1. Feature Extraction: We use a Vision Transformer (ViT) backbone to capture high-frequency artifacts — the telltale signs left by diffusion models and GANs.

2. Binary Classification: A head predicts the probability that the image is AI-generated.

3. Source Attribution: A second head classifies the likely source model across 80+ generators, from Midjourney and DALL·E to Gemini, Ideogram, and lesser-known tools.

4. Deepfake Detection: A specialized face-analysis branch flags AI-manipulated portraits and face swaps.

The result is not just a score. You get a structured report: confidence percentage, suspected model, and a plain-English summary.

Real-World Detection Examples

Here is a real detection result from AI Picture Checker — an image generated by Gemini, analyzed in seconds:

Result breakdown:

• AI Probability: 100.0%

• Source Attribution: Gemini (99.5% model match)

• Summary: Strong indicators of AI generation detected

This is exactly what separates a real AI Image Detector from a simple binary classifier. It does not just say "AI" — it tells you which model.

Three more cases from recent usage:

In each case, the user saved hours of manual review by running the image through this online AI photo detector first.

Building for Scale and Privacy

Two constraints drove the architecture:

• Privacy: Images are analyzed in real-time and not stored permanently. We do not build user galleries or training datasets from uploads.

• Speed: The model runs on optimized inference endpoints. A 10MB JPG returns results in under 3 seconds.

If you are building a content moderation pipeline, you can integrate the AI Picture Checker API to batch-process uploads automatically.

Try It Yourself

Whether you are verifying a single suspicious photo or screening thousands of user uploads, an AI Image Detector should be part of your workflow.

You can check if an image is AI-generated instantly at aipicturechecker.com. No signup is required for the first few checks — just drag, drop, and get your report.

What Is Next

We are expanding the model to detect:

• Partially AI-edited images (AI inpainting + real photo composites)

• Video frame-level detection for short-form content

• PDF and document image screening

If you have a use case that is not covered yet, drop a comment. I read every piece of feedback and it directly shapes the roadmap.

Resources

• AI Picture Checker — Free online AI Image Detector with source attribution