DEV Community: Ivanvolt

Charging credits for async AI jobs without double-spending

Ivanvolt — Thu, 27 Aug 2026 03:59:18 +0000

Image and video jobs do not finish in the same HTTP request. They take long enough that a dropped response, a double-click, or a refresh will retry. If you charge on "done", you eat unpaid work. If you charge on "start" and the job dies, you owe people money back. Both bugs showed up in our first design, so we moved the money and the task into one write.

This is how Epochal does it today: a 202 on submit, a durable task, a client request id, and a refund flag that can only flip once. No customer webhooks. The browser polls.

I am writing this as the person who has to explain a missing refund.

The failure that forced the design

A user hits Generate. The server creates a job and charges the quoted cost. The tab dies before the JSON comes back. The client retries with the same payload.

Without a request id you get two tasks and twice the spend. With a request id but a late charge, the retry can create a second task that never got paid. The only version that stayed sane for us:

The client sends clientRequestId.
One database transaction locks the user, checks the in-flight job cap, spends credits, inserts a pending task.
The HTTP response is 202 with the task id. The file is not ready.

Same user + same clientRequestId returns the existing task. No second spend.

// Same user + same clientRequestId → existing row, created: false
const existing = await findTask(userId, clientRequestId);
if (existing) {
  return { task: existing, created: false };
}

await consumeCredits(tx, { userId, amount });
await insertTask(tx, { status: "pending", creditsReserved: true });

The column is unique per user.

Reserve credits and create the task atomically

Spend happens inside the same transaction as the task insert, not after the model returns.

The user row is locked (FOR UPDATE) so two tabs cannot both pass the balance check. Credits live in expiring lots. We spend the lots that expire first, and a cron expires any unused balance and records the change in the ledger.

If the balance is short, we throw before insert. The generate routes map that to 402. No empty task, no "reserved 0 then fail."

Local safety or text-moderation blocks write a failed task with nothing reserved. Those never touch the ledger.

202 means accepted, not completed

Synchronous image generation is deprecated on our API. Submit returns immediately:

HTTP/1.1 202 Accepted
{
  "creation": { "id": "…", "status": "pending" },
  "remainingCredits": 142
}

Statuses are only pending, running, completed, failed. A completed or failed row cannot move back. That sounds obvious until two workers both try to "fix" a stuck job.

The workbench polls the task endpoint while it is active. Each GET asks the server to sync that task before it reads. A slower task-center poll lets users navigate away without losing visibility.

We do not offer "POST this URL when the video is done." Billing uses Stripe webhooks. Generation completion is our problem: client poll, a server-side follow-up after the 202, and a cron that rescans stale pending / running rows.

Refund exactly once

Failure does two things in order: mark the task failed (only if it is not already terminal), then refund if the row is eligible.

The refund is its own transaction. The refund flag is not a record that a refund was attempted. It is a claim that the refund transaction completed.

const [claimed] = await tx
  .update(generationTask)
  .set({ creditsRefunded: true })
  .where(
    and(
      eq(generationTask.id, taskId),
      eq(generationTask.status, "failed"),
      eq(generationTask.creditsRefunded, false)
    )
  )
  .returning({ id: generationTask.id });

if (!claimed) return; // another worker already refunded

await addCredits(tx, userId, task.creditsCost);
await insertLedgerRow(tx, { type: "REFUND", amount: task.creditsCost });

If the add-credits step throws, the transaction rolls back and creditsRefunded stays false. The next retry can try again. That comment is in the orchestrator because we shipped the opposite bug: flag flipped, money never added.

A second cron looks for failed + reserved + not refunded and runs the same claim. I do not trust a single in-process path after a deploy mid-job.

Not every terminal failure is refundable, so refund eligibility is stored explicitly rather than inferred from status = failed.

Completed means we own the output

running means we handed the job off. completed means we downloaded the result, stored it on our object storage, and linked it to the task. That last write is also claimed so two finishers cannot create two library rows.

Upstream success is not a durable result. If persist fails after the file exists, a later sync or the recovery cron can finish the row. Users see the same object in the workbench, the task center, and the library because both tables map to one list item.

Concurrency belongs inside the same lock

In-flight means pending or running. We enforce the user's concurrency limit under the same user lock as the credit spend. That prevents two simultaneous requests from both passing the limit check before either inserts its task.

Over the cap is 429. The pricing UI reads the same plan-cap resolver as the server, so the displayed limit and the enforced limit cannot drift independently.

What I would not do again

Charge after success. You will eat unpaid GPU time on every abandoned tab, and you will invent a "pending charge" state that nobody can explain in support.

Refund with UPDATE … SET refunded = true then a second query for the money. One of those queries will fail. Claim the slot and move the balance in one transaction.

Customer webhooks as the only completion signal. We would have to sign payloads, retry 4xx, and still keep polling for the workbench. Poll + server sync + cron is enough for a product that is a website, not an API company.

Treat "the model finished" as "the user has a file." Until the object is on our storage and linked, the task is not done. People refresh. The row has to survive that.

Try the failure path

Open a model or tool on epochal.app, submit once, then refresh mid-job. The same clientRequestId should not take credits twice.

If you run a similar queue: put the request id, the spend, and the pending row in one lock. Everything after that is catching up.

Best AI Video Generators in 2026 (That Actually Work for Real Content)

Ivanvolt — Thu, 16 Apr 2026 08:59:41 +0000

AI video generation has improved fast.

Most models can now generate impressive clips.

But here’s the real problem:

Most AI video tools don’t work well for actual content creation.

After testing multiple models and tools, I realized something important:

👉 The best AI video generator is not just about quality

👉 It’s about how well it fits your workflow

TL;DR

Veo 3.1 → best for cinematic quality
Seedance 2.0 → best for fast iteration & volume
Kling 3.0 → best balance
WAN → interesting for open workflows
Workflow > model quality

The biggest mistake people make

Most comparisons focus only on output quality.

That’s not how real usage works.

In practice, you need to ask:

Can I reuse outputs?
Can I iterate quickly?
Can I keep consistency across generations?
Can I move from image → video easily?

👉 This is a workflow problem, not just a model problem.

Veo 3.1 — best for cinematic output

Best for:

cinematic shots
brand visuals
high-quality scenes

Tradeoff:

slower iteration
not ideal for volume

👉 Great for “hero content”, not for rapid testing.

Seedance 2.0 — best for iteration

Best for:

fast testing
social content
generating multiple variations

Why it works:

speed > perfection
easier to iterate

👉 In real production, this often matters more than peak quality.

Kling 3.0 — balanced option

Good for:

text-to-video
image-to-video
multiple formats

👉 Not always #1 in one area, but solid across everything.

WAN — worth watching

Why it matters:

more transparent
open-weight ecosystem

Best for:

experimentation
research workflows

The real insight: workflow > model

A real AI video workflow looks like:

Start with prompt or image
Generate candidates
Save strong outputs
Reuse references
Iterate variations
Move into video

👉 This is why image-to-video is becoming critical.

Text alone is unstable.

Images create consistency.

Where most tools fail

Most tools treat every generation as:

a fresh start

So you get:

inconsistent visuals
no continuity
random outputs

What actually works better

A better approach is:

reuse strong frames
build on previous outputs
compare variations
keep everything in one loop

👉 This is where workflow tools start to matter.

Where Epochal fits

While testing, I came across a tool called Epochal.

Instead of focusing on one model, it focuses on workflow:

text → video
image → video
model comparison
saved outputs
iteration loop

👉 It’s closer to a workspace for AI video creation than a single generator.

You can check it here:

👉 https://epochal.app?ref=devto

My practical takeaway

Use Veo for quality
Use Seedance for speed
Use Kling for flexibility
Focus on workflow if you care about real output

Final thought

The future of AI video is not:

one perfect prompt

It’s:

generate → compare → reuse → iterate

That’s where consistency and real content creation start to happen.

If you're curious, I also wrote a deeper breakdown here:

👉 https://epochal.app/blog/best-ai-video-generator-2026?ref=devto

We built an SDK to submit AI tools to directories

Ivanvolt — Fri, 06 Mar 2026 14:41:11 +0000

Launching an AI tool is easy today.

Getting people to discover it is much harder.

Most founders eventually start submitting their tools to directories, product listings, and communities. The problem is that the process is repetitive.

You open a form, paste your URL, write a description, upload an icon, and repeat the same steps across different platforms.

As developers, we automate almost everything else.

So we asked a simple question:

Why are tool submissions still manual?

That’s why we built the Aidirs SDK.

Instead of filling out forms, developers can submit their AI tools programmatically.

All you need is a URL.

The SDK can automatically generate:

• tool name
• description
• icon
• metadata

This means submissions can become part of a developer workflow instead of a manual task.

If you’re curious, you can check the docs here:

https://aidirs.best/api-docs

And if you’re launching an AI tool, you can submit it here:

https://aidirs.best/submit

Aidirs is now listed on Toolify

Ivanvolt — Thu, 05 Mar 2026 06:24:56 +0000

Aidirs, a curated AI tools directory, has recently been listed on Toolify.

You can view the listing here:
https://toolify.ai/tool/aidirs

How Indie Makers Discover AI Tools in 2026 (And Why Directories Still Matter)

Ivanvolt — Wed, 25 Feb 2026 14:41:48 +0000

AI tools are launching faster than ever, but discovery hasn’t changed as much as people think.
After building an AI tools directory, I started to see clear patterns in how indie makers actually get discovered — and what doesn’t work anymore.

AI tools are everywhere — discovery is not

In 2026, launching an AI tool is easy.

Getting it discovered is not.

Product Hunt spikes fade fast. Social posts disappear in hours.

And most indie makers eventually realize the same thing:

Discovery is not about launching louder.

It’s about being findable after the launch.

I learned this the hard way while building an AI tools directory.

What actually drives long-term discovery

After reviewing hundreds of AI tools and submissions, a few patterns became very clear.

1. Search intent beats launch traffic

Most users don’t search for your product name.

They search for:

“AI writing tools”
“best AI tools for developers”
“AI directories”

If your product doesn’t live on pages that rank for these intents, it becomes invisible very quickly.

2. Directories still work — if they’re curated

Not all directories help.

The ones that do share common traits:

Clear categories
Real descriptions (not auto-generated spam)
Clean outbound links
Pages that are indexed and updated

Search engines still treat these as trust signals, not shortcuts.

3. Backlinks matter less than context

A single backlink from a relevant, well-structured page often beats:

10 random links
1 viral tweet
1 short-term launch spike

Contextual placement + relevance > raw volume.

Why I built an AI tools directory

I didn’t build it to “collect links”.

I built it to answer a simple question:

Where do founders actually go after they launch?

The answer was obvious:

They submit to directories
They compare tools
They look for places users already trust

That’s how Aidirs was born — a curated place for AI tools, directories, and rankings.

No growth hacks.

Just structured discovery.

Final thought

Most AI products don’t fail because they’re bad.

They fail because:

They disappear after launch
They aren’t searchable
They aren’t listed where users look

Discovery is not a moment.
It’s infrastructure.

I document these patterns while running a curated AI tools directory: https://aidirs.best

If you’re building an AI product, think less about the launch day — and more about where your product will still be visible six months later.

From Frustration to Fix: How Aluo is Helping Sellers Design Smarter

Ivanvolt — Wed, 06 Aug 2025 08:52:10 +0000

To be honest, when I started working on Aluo.ai, there wasn’t some grand plan. I just got really tired of how frustrating product photos were in e-commerce.

Every seller wants the same thing — images that look clean, professional, and high-converting. But getting there usually means hiring a designer, endlessly tweaking PSD files, or wrestling with some clunky template editor that only gives you so much control.

As a developer, I kept thinking: can’t AI just handle all this by now?

That’s how Aluo started.

You can think of it as a product image generator — but it’s more than that. Upload your product photo (even if it has a messy background), and the system automatically removes the background. Then, with one click, you can apply clean, realistic scene templates: wood surfaces, studio lighting, soft gradients, lifestyle setups, and more.

The best part? You can still make changes. Move things around, tweak colors, add shadows, or just type your edits in plain English and let AI handle the rest.

It’s not meant to replace designers. It’s meant to take away the boring parts — the resizing, masking, recoloring, re-exporting — and let you focus on the vision.

I know there are tools out there that claim to do this. I’ve tried most of them. But I found them either too rigid, too slow, or just… not convincing. Aluo aims to live in that sweet spot: easy enough for non-designers, but good enough that you’d actually want to use the images.

We’ve worked hard on the small things: image clarity, fast rendering, high resolution, soft lighting, realistic reflections, clean cutouts — things that make your product feel real. We also support global sellers, multiple languages, and different style presets depending on the platform you’re selling on.

And yes — it’s already helping real sellers. Cross-border teams, Amazon folks, Shopify brands — they’re saving hours every week and finally getting marketing visuals that don’t look like generic catalog shots.

In future posts, I’ll be sharing more behind-the-scenes — how we made certain tech choices, what surprised us about user behavior, and how I’m building Aluo using modern AI coding tools without even touching much code myself these days.

There’s no magic formula. Just trial, error, and a lot of stubborn optimism. If you’re building something for the ecommerce space, or if you just want to create faster without compromising quality — maybe give Aluo a try.

No pressure. Just a quiet tool built by someone who got tired of Photoshop.

— Ivan, creator of Aluo.ai