DEV Community: PixQuill

7 Image Model APIs I Integrated. Here's What Each One Got Wrong.

PixQuill — Tue, 20 Oct 2026 04:47:42 +0000

I needed a way to run the same prompt across multiple image models without rewriting everything seven times. So I integrated seven vendors behind one prompt box.

The abstraction leaked in every direction. Every API got something wrong in a way that cost me a day, then a week, then a month.

These are the specific failures, in the order they broke me.

1. Parameter names are all different, and all wrong

Nobody agrees on how to specify a resolution.

// vendor A
{ "size": "1024x1024" }

// vendor B
{ "width": 1024, "height": 1024 }

// vendor C
{ "aspect_ratio": "1:1", "resolution": "2K" }

// vendor D
{ "output_size": "1024x1024" }

The fourth one is the killer. output_size looks right, gets a string, returns a 200 response, and the output is 768px. No error. Nothing in the logs. You find out three weeks later when you try to print something at 18x24.

Vendor D's actual fix was output_size: "1024_1024" with an underscore. There was no documentation for it. Someone's gist had it.

2. Error shapes are all different, and three of them are 200 OK

This is the single most expensive thing I hit.

// vendor E, actual failure
{ "error": { "message": "Content policy violation", "code": "safety" } }

// vendor F, same failure, HTTP 200
{ "status": "success", "data": [{ "url": null }] }

// vendor G, same failure, HTTP 200
{ "task_status": "failed", "fail_code": 1003 }

Vendor F returns status: "success". That string is the whole reason it took me a month to notice.

Every adapter now has an explicit check that the output URL is non-null and that the pixel dimensions match what was requested. Not because the APIs document it, but because they don't.

3. Reference images have seven different syntaxes

When you attach an image and refer to it in the prompt, every vendor invented its own convention.

Vendor	Syntax for "the jacket in image 1"
A	`the jacket in image 1`
B	`the jacket in <image-1>`
C	`the jacket in @Image1`
D	`the jacket in [Image 1]`
E	`the jacket in [0]`
F	`the jacket in {image_0}`
G	`the jacket in the first attached image`

Vendor E is zero-indexed. Vendor G requires prose and ignores any syntax you give it.

The failure mode is silent again: you attach two references, write [Image 1] intending the first one, and get output that used the second. No warning. The image just has the wrong jacket.

I now have a translation layer with an explicit index map, and I assert that the resolved reference count matches the attachment count before the call goes out.

4. Billing units are incomparable

This took real arithmetic to get right.

Vendor	Billed by	Effective cost of one 2K run
A	per megapixel	cheapest at low res, scales badly
B	per run, flat	cheapest at high res
C	per run, tiered by model	mid
D	per output image, x4 for batch	depends on batch size
E	per compute second	varies 3x with prompt length
F	per run plus output storage	storage dominates at scale

Vendor E bills by compute second, which means the prompt itself is an input to the cost. A longer prompt with the same output costs more. That is not something I would have guessed, and it showed up as a cost spike that looked like a bug.

The practical fix: never show a user a single price. Show them the price for the specific model at the specific resolution they are about to pick. The price before the click is the only honest price.

5. Rate limits are per-vendor, per-model, and sometimes per-tier

// what I assumed
if (rateLimitOk) generate();

// reality
if (
  orgLimitOk &&
  keyLimitOk &&
  modelLimitOk &&
  tierLimitOk &&
  concurrentJobLimitOk
) generate();

Vendor B's limit is per organization. Per key. Per model. Separately. So one popular model can exhaust your quota while four other models sit idle.

The only workable pattern was a token bucket per vendor-model pair with independent backoff. Retry-with-jitter on 429, and never let one vendor's 429 stall the others. That is the failure mode where one rate limit takes down your entire console.

6. Async semantics differ, and one of them lies

Four of the seven return a job you poll. Three return a URL immediately. One returns a URL immediately that 404s for about ninety seconds.

// the lying one
const { url } = await createJob(payload);
// url is real, url is ready, url is not there yet

I now HEAD the returned URL before returning it upstream. It looks like paranoia until you ship it, and then it saves you a class of user-facing 500s.

7. The "no retouch" problem, and the tool I built to hold all this

Each of these fixes is small. The problem is that there are seven of them, per vendor, and every new model release reintroduces them.

So I put all of it behind one console. PixQuill runs more than twenty image models across seven vendors from a single prompt box. The resolution normalization, the error-shape checks, the reference-index translation, the per-model pricing, and the per-vendor rate-limit buckets all live underneath. The prompt goes in, images come out.

I did not build it to hide the differences. I built it because each vendor's difference is a legitimate reason to pick that vendor, and none of them are a reason to make the user learn that vendor's particular way of doing things.

The pattern across all seven

Every failure above was a silent success. A 200 response. A status of "success". An output that exists, is non-null, and is wrong.

Not one of these APIs raises an exception when it fails you. They return valid-looking data and let you discover the problem later, downstream, usually when someone asks why the print came out at half size.

That is the real cost of multi-model integration. Not the adapters. The verification you have to write yourself, because nobody else is going to.

If you are integrating image models right now, budget for the assertion layer. It is not optional, and it is not in any of the docs.

I asked 6 image models the same thing. Only 1 followed the brief.

PixQuill — Mon, 12 Oct 2026 02:12:13 +0000

I built a stack of six image APIs in two weekends. Six clients, six rate limits, six ways a generation can silently fail. Last Tuesday I ran the same prompt through all of them and stacked the results in a grid. Five out of six were beautiful. One was correct.

The brief was simple. A 16:9 hero image for a fintech landing page: a 30-something professional at a standing desk, muted palette, abstract data in the background, no text anywhere in frame. Five of the six models produced something I would happily put in a mood board. The sixth produced the only one I could actually ship: 16:9, no text, muted palette, person looking roughly the right direction, and the abstract-data background sitting where I asked for it.

That gap is the whole story.

The metric I now use

I stopped judging these models on aesthetic quality. Aesthetic is taste, and taste is a fight nobody wins on a forum. The only thing I care about is brief adherence: did the model respect the ratio, the palette, the negative space, the "no text" instruction, the subject, the framing? A gorgeous image with the wrong aspect ratio is a reject. A flat image that hits every line of the brief is a keep.

On that axis, the six models cluster in ways that don't match their public leaderboards. The leaderboard tells you which model a thousand people upvoted the most. It does not tell you which model will respect your aspect_ratio: "16:9", your no_text: true, and your "this is a B2B audience" framing on the same run.

What I actually learned

One model dominates for "literal" briefs. When the prompt is mostly instructions and the visual style is conventional — corporate, product, e-commerce — one of the six almost always wins, and the margin is not close. It's also not the model with the most Instagram screenshots.
A different model wins the moment the brief asks for typography or layout. If you need legible in-image text, exact placement, or a strong graphic-design feel, the leaderboard favourite falls apart and a less popular one takes over.
For concept art and character consistency, a third model pulls ahead. It's the slowest of the six. It is also the one where "make her wear the jacket in image 2" actually works.
The remaining three are situational. Each is the best at one thing I rarely need, and mediocre at the five other things I do.

The mistake I see in every "X vs Y" thread is treating the question as if it has one answer. The model I'd pick for a Saturday-morning book cover is not the model I'd pick for a Monday-morning Stripe banner.

What I did about it

I got tired of running six tabs, six auth tokens, six credit balances. So I moved everything into a single browser console that exposes the same six models behind one prompt box, one credit wallet, and one button to "run on all six". I attach reference images, type the brief once, and the console gives me a grid. I keep one, the rest go to the library.

The interesting part is not the grid. It's that the grid makes the brief-adherence gap obvious in a way six separate tabs never did. When you see all six outputs side by side, you stop arguing about which model is "best" and start asking which one is best for this specific job. The console does the boring part; I do the taste part.

The cost-per-image is visible before I run, failed runs refund automatically, and I haven't opened Figma for cover work in three weeks.

The takeaway

Stop asking "what's the best AI image model". There isn't one. The right question is "which model follows the brief I actually have, today, for this specific output". And the only honest way to answer that is to put your real brief in front of all the candidates at once and let them fight.

Once you start doing that, the rankings change every project. That's the point.

I Built a Free File Conversion Platform That Runs Entirely in Your Browser — No Uploads, No Tracking, No Login

PixQuill — Wed, 10 Jun 2026 02:24:54 +0000

I Built Free Browser-Based File Tools That Run Without Uploading Your Files
Why I Built File Convert Factory
Most online file converters require you to upload your documents to a server.
That means your PDFs, Word files, images, or spreadsheets are processed somewhere you don't control.
As someone who works with sensitive documents daily, that always bothered me.
So I decided to build something different.
I built File Convert Factory, a free browser-based platform that handles file conversions and text utilities completely on the client side.
No uploads.
No tracking.
No login required.
Everything runs directly in your browser.
What File Convert Factory Includes
The platform includes tools across multiple categories:
• File conversion tools
• Text utilities
• Document processors
• Developer helpers
Some of the most popular tools include:
PDF to Word Converter
Image Format Converter
Text Repeater
Batch File Processor
Document Compressor
Why Browser-Based Tools Matter
Client-side tools offer several advantages:
🔒 Privacy First – Your files never leave your device.
⚡ Fast Performance – No server processing delays.
🌍 Works Anywhere – Convert files even with a slow or offline connection.
This approach makes file handling safer and faster.
The Goal
The goal is simple:
Create a place where anyone can convert files and process text instantly without worrying about privacy or installing heavy software.
You can try it here:
https://file-convert-factory.org/
One tool I use constantly is the Text Repeater, which generates structured text locally for testing and formatting:
https://file-convert-factory.org/en/tools/text-repeater
What's Next
File Convert Factory is growing quickly and new tools are being added regularly.
If you have ideas for converters or utilities you'd like to see, feel free to share them!