Conut AI — Devpost project page

Inspiration

Every generative model is good at something different, and the differences matter. One model is better at text rendering inside images. Another handles camera motion. Another is cheaper for iteration but worse at the final render. A third is the only one that does a specific effect well.

The practical consequence is that a real creative workflow bounces between five tabs, and every switch resets your context: you re-upload the image, re-write the prompt, re-learn the settings.

Conut AI exists so that the choice of model becomes a parameter, not a different website. One prompt, many models, and you keep the same image and project as you move between them.

What it does

One interface for image and video generation across a stack of current models.

• Image generation and editing
• Video generation, including image-to-video
• Expression and face editing
• A library of effect tools — stylisation, duo scenes, and similar
• Everything shares one project workspace, so an image you generated is available to the next tool

How I built it

The core engineering problem is normalising a set of model APIs that agree on almost nothing.

1. A provider abstraction. Every model gets wrapped in the same interface: submit a job, poll for status, fetch the result. Each provider has its own auth scheme, its own request shape, its own polling model, and its own failure semantics. The abstraction hides all of that behind a uniform contract.

2. Normalised media handling. Providers disagree about input format, acceptable resolution, and file hosting. I keep one canonical asset store and each adapter converts as needed. Inputs must be re-hosted to URLs the provider can reach, which means every request is a copy-then-call rather than a direct pass-through.

3. Job state machine. Generation is slow and unreliable. Jobs exist in a persisted state machine — queued, submitted, polling, succeeded, failed, refunded — so a provider outage produces a clean failure and a credit refund rather than a stuck spinner.

4. Credit accounting. Every tool has a real cost, and the accounting has to match reality: charge on submit, refund on failure, never charge twice on a retry.

Challenges I ran into

Providers fail in incompatible ways. Some return a 200 with an error inside the body. Some time out but complete anyway, so a retry produces a duplicate charge. Some return a URL that expires before you fetch it. I had to treat every provider response as untrusted and build the state machine so that "unknown" is a legitimate state you recover from, rather than assuming success or failure.

Credit errors are worse than generation errors. A failed generation annoys someone. A wrong credit balance makes them think the product is stealing from them. The refund path had to be as reliable as the generation path, which meant making the accounting transactional and idempotent rather than best-effort.

Model choice is not something users want to think about. My first version exposed the model list directly. Most users do not know which model to pick and defaulted to the top of the list regardless of the task. Grouping tools by what you want to do and choosing the model behind it works far better than making the model the headline.

[Add here: one specific provider integration that broke in a way you did not expect, and how you handled it.]

Accomplishments that I'm proud of

• The provider abstraction holding up across a growing list of models without each addition rippling through the app.
• Getting the refund path to be genuinely reliable. Financial correctness under partial failure is the part of this that is actually hard.
• Keeping the media pipeline seamless — the user never thinks about re-hosting or format conversion.

What I learned

Aggregating APIs is a reliability problem disguised as an integration problem. The integrations took a fraction of the time. The rest was handling the fact that ten independent services will each fail differently, and your product has to behave predictably regardless.

The interface should follow the user's intent, not the vendor's catalogue. Exposing capability was easy and made the product worse. Users want "make this image look like a painting," not "choose between four diffusion variants."

[Add here: which tools people actually used most, and whether that matched your assumptions.]

What's next for Conut AI

• Automatic model routing. Pick the model based on the prompt and the reference image instead of making the user choose at all.
• Project memory. Keep the character and style consistent across a series of generations, not just within one.
• Batch generation. Submit a set of prompts and get a grid of variations to compare side by side.
• Team workspaces. Shared asset libraries, because creative work is rarely done alone.

Built With

• react
• supabase