The local image API came from a small integration problem: I already had bots that knew how to call OpenAI-style image endpoints, and I had a local GPU that could run ComfyUI and SDXL. Rewriting every bot to understand ComfyUI workflows would have been the wrong kind of work.
So the API pretends to be the thing the bots already know. It exposes /v1/images/generations and /v1/images/edits, accepts the familiar request shape, builds the right ComfyUI workflow behind the scenes, waits for the image, and returns base64 JSON in the same format the bot expected from a cloud image API.
The constraint is translation. A prompt written for one image API is not automatically a good SDXL prompt. The server can optionally call LM Studio first to rewrite the incoming system-plus-user prompt into SDXL-friendly tags. If the local model is down, it falls back to simpler rule-based extraction.
The config is intentionally plain: ComfyUI URL, checkpoint, image size, steps, CFG, sampler, scheduler, denoise for image edits, LM Studio URL, and server port. The default path was Juggernaut XL through ComfyUI, but the useful part is that the caller does not need to know that.
This is the same pattern I keep liking in home-lab tools: keep the interface stable, replace the backend. The bot sends the request it already knows how to send. The local machine does the expensive work. If I want to swap checkpoints or tune SDXL settings, that happens behind the API boundary.
Notes for next time: compatibility is leverage. A tiny adapter can be more valuable than a new feature if it lets old clients use a new local capability. The goal is not to build an image platform. The goal is to let existing tools point at localhost and keep working.