I was building an image app for the Tiiny this week and went shopping in the Model Store for something that would do background removal. There are four of them sitting right there. Background-Remove, Object-Remove, Zoom, Outpaint.
So I designed around them, and then went to check the API before wiring it up.
The image endpoint takes model, prompt, negative_prompt, width, height, seed, steps and guidance_scale. That is the whole list. I got it by sending wrong types on purpose and letting the server tell me which fields it validates, so this isn't me guessing from docs.
There is no image input. Send an image or input_image or mask field and it gets accepted and thrown away, so nothing errors and nothing happens. There's no separate edit endpoint either. I tried about a dozen names. /v1/image/edit, /v1/image/inpaint, /v1/image/img2img, all 404.
Then I went and looked at what these models actually are. FLUX.2 klein is an editing model. Black Forest Labs' own API for it is titled generate or edit, and the request body takes input_image and input_image_2.
Which makes the four names make sense in a way I don't love. You can't outpaint from nothing. You can't remove an object from a picture that doesn't exist yet.
So as far as I can tell those models are installable and unusable. You can spend the disk and the NPU units on them and there is no request you can send that hands them a picture.
The one thing on the box that does take an image is chat completions. I sent a test PNG to Qwen3.8-27B and it described it correctly. So an upload does reach a model, just not an image model. Which means the only way to fake editing today is to have a vision model describe your photo and a text-to-image model paint a new one, and that isn't editing. I'm not going to ship an app that pretends it is.
Am I missing an endpoint here? If there's a way to do this that I haven't found, I'd rather be wrong.
If not, this looks like one optional input_image field on the endpoint that already exists, plus a mask for the two variants that want one. That would light up the whole specialist shelf at once instead of one model at a time.
Full writeup with the exact field lists and everything I probed: https://artifacts.semfreak.dev/a/tiiny/tiiny-image-api/
Not missing one — image input isn't supported in the version you're running. It's coming in v1.0, so the four FLUX.2-klein editors will have something to take; the input_image field you identified is exactly the missing piece.
Thank you!
Greatly appreciate the rollout of the new models today--thanks; keep it up! In the meantime, is there any estimate on when we'll see our first model (or first existing model update) that handles image-to-image? Is there some limitation of the hardware that is preventing implementation? I only ask because several image-generation models in the Model Store natively support image-to-image editing outside of the Tiiny ecosystem.
Wish I had found this post 4 days ago! I’ve built apps, workflows, agents, tried command lines with OpenHands and OpenWeb UI, set up an Xinference server etc etc etc…I finally gave up this afternoon. It’s almost bitingly ironic that a niche appliance built for local AI makes it so hard to simply upload a picture to a local model. Do we have a sense of when we might finally see image-to-image…I’m VERY anxious for that feature roll-out!
TiinyImage ships within the next week, provided it clears testing, and it does image-to-image, so the hardware was never the limit. Post your questions and how it feels to use once it's live.