# Image-Studio is built around the 524 that ends a long generation > A Wails desktop client for OpenAI-compatible image upstreams, with two transports for the same work because long generations get cut off behind Cloudflare and Nginx. It ships no default upstream, no hosted web version, and a troubleshooting page that tells you to check curl before filing a bug. **RoseKhlifa/Image-Studio** — 开源image2调用图像生成/编辑桌面客户端 · SSE 流式保活,兼容 Cloudflare 524/504 超时截断 · Wails (Go + React/TS) · 数据 100% 本地 - Repository: https://github.com/RoseKhlifa/Image-Studio - Stars: 490 · Forks: 52 - Language: Go - License: AGPL-3.0 - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/rosekhlifa-image-studio ## A proxy timeout is a transport problem The problem this client is built around is specific and unglamorous: a long image inference request gets disconnected behind a proxy. The failure appears as a 524 or a 504, which are proxy-level errors meaning an upstream did not answer in time. For an image model that can take minutes to produce a result, an intermediary that times out at thirty or sixty seconds will cut every long request, no matter how well the client behaves. The project's answer is to change the transport rather than to retry harder. It supports two shapes of upstream API. The Responses API mode can use HTTP server-sent events or WebSocket mode, and either keeps the connection active while the model works. The Images API mode is compatible with the standard generation and edit endpoints, which is what a compatible upstream that only offers those routes will have. That is the design decision in one sentence. Streaming exists so the proxy sees bytes moving rather than a silent request, and WebSocket is offered for upstreams where the connection is long-lived by design. The choice between the two is a property of the upstream, not of the client. The guidance is that the Responses API suits long inference and resists the timeout errors, while the Images API suits a compatible upstream offering only the standard image endpoints. ## No default upstream, so the first screen is a form The project ships with no default upstream configured, and that is stated as a feature of the setup rather than an omission. On first launch you open the upstream configuration screen and fill in four things: the API form, the base URL, the API key, and the identifiers for both a text model and an image model. Two model identifiers rather than one, because the client itself needs a text model for whatever it does around the image call, and the two are not the same model. After that the flow is short. Enter a prompt, set the aspect ratio, quality, output format and style, and either click the generate button or press the platform shortcut for enter. If the built-in aspect ratios do not cover what you need, there is a dialog for saving custom width and height ratios. The configuration screen also carries a test-connection action, and the troubleshooting section tells you to use it first. That is the single most useful thing in the interface for anyone diagnosing a failure: it confirms the four values against the upstream before anything else is attempted. A companion project handles prompt discovery. It runs as a separate site, browses prompts, and imports them into the desktop client in one action rather than making you copy text between a browser and an application. ## Troubleshooting starts by saying it is not a bug The section on what to check before opening an issue is the most distinctive page in this repository, because it argues against itself. It opens by saying that most reports of generation failure, save failure or model unavailability are not defects in the client. They come from upstream configuration, key permissions, gateway timeouts, model capability, or differences between compatible implementations. Then it gives five steps. Test the connection in the current profile and confirm the four values are genuinely usable. Check the troubleshooting document for the specific error classes, naming 524 and 504, 401 and 403, a model-not-found response, multiple reference images or a mask not taking effect, and Android save directory behaviour. Read the real HTTP status code and the upstream error from the history detail or the raw response rather than the toast on the page. Then the step that decides most tickets: if the same base URL, key and model identifiers also fail in curl, in Postman, or on the upstream's own debug page, contact the upstream provider instead of filing an issue here. Only after that, with a minimal reproduction prepared, is an issue filed against this repository. For a maintainer, that is triage moved upstream. For a user, it is the difference between debugging your key for twenty minutes and filing a bug report that gets closed. ## No hosted web version, and the preview is not one There is a sentence in the project description worth reading twice, because it closes off the question most visitors arrive with. There is currently no separately deployed online web version. The browser preview in the repository exists for front-end debugging and for previewing the target platform, and it is explicitly not equivalent to a SaaS web front end you can serve to other people. That is an unusually direct disclaimer. Many projects ship a web build and let people infer it is a service. This one names the gap and explains what the browser bundle actually is. The architecture explains why. The client is a Wails application, meaning a Go backend with a React and TypeScript front end, packaged as a desktop program. A WebView shell for Android sits alongside it. There is no server component that would make a hosted deployment the default path. So the deployment options are desktop installers and, if you build it yourself, something you host. Data is described as staying local throughout, which follows from there being no service for it to travel to. The repository does contain a Cloudflare worker directory, which is the piece that would sit in front of an upstream rather than in front of users. ## AGPL-3.0 covers the hosted case explicitly The licence is the GNU Affero General Public License version 3, and the README explains its scope rather than leaving it to the licence text. The explanation is short: if you modify the project and redistribute it, or provide the modified version to other people as a network service, you have to publish the corresponding source under the same licence. The second clause is the one that matters for a desktop client with a web preview. AGPL was written for exactly that case, where a server is reachable by users without being distributed to them. A permissive licence covers the binary you ship; the Affero clause covers the version you operate. For most users this is invisible, because you run the desktop application yourself and modify nothing. It becomes relevant the moment you fork it, wrap it in your own product, or host a modified version as a service, which includes the white-label case that a tool like this invites. The repository also carries an SPDX-style identifier in the file tree, and the copyright line reads 2026. There is no separate licence for the data or for prompts; the same terms cover everything in the tree. ## Six directories, one Go workspace The repository layout tells you this is not a single application, and the workspace file at the root is the giveaway. There is a Go workspace file and its checksum companion at the top, which means the Go code is split across modules rather than built from one module. Inside the workspace there is the main desktop application directory, a separate command line directory, and a shared directory that the other components import. Then there are three more components with their own purposes. A Cloudflare worker directory, which is the piece that would sit between a client and an upstream. An Android shell directory, described in the documentation as a WebView wrapper maintained separately. And a Gio client directory, documented as a high-performance test client. The documentation table names most of them explicitly. One entry covers the repository structure, the front-end layering, and the relationship between the kernel, the worker and the Android shell. Another covers the cross-platform kernel plan and its verification background, which suggests the boundary between these components is still moving. Two more directories matter for anyone automating this. A scripts directory holds the verification scripts, and a documentation entry describes the source build, those scripts, and the continuous integration artefact chain that produces the binaries. ## Unsigned CI artefacts and a warning about them The installation section offers two ways in, and the second one comes with a warning attached. The stable route is a release download. The route for trying the latest changes on the current branch is to take the most recent successful build artefact from the project's continuous integration workflow, which is pointed at a repository under a different organisation. The warning is about signing. On Windows, an executable produced this way may be unsigned, in which case Windows 11's Smart App Control or SmartScreen can block it, and the recommendation is to use those builds for internal testing only. That is a real constraint for anyone evaluating the project rather than a technicality. An unsigned binary on Windows is a decision the operating system will make for you, and a blocked download teaches a user nothing about the software. Two other documentation entries bear on whether a build is trustworthy. One covers manual verification on real devices against real upstreams, as a matrix. Another covers current issue progress and items awaiting verification, which is an unusual file to publish and a useful one: it tells a user which reported problems are already known and which are still open. There is also a reusable issue-closing comment template, which suggests the maintainer expects to close duplicates often. ## Conclusion Adopt Image-Studio if you sit behind Cloudflare or Nginx and your image generations die at the proxy timeout, since the streaming transports are the whole reason the project exists. Do not adopt it expecting a hosted service or a browser version you can point other people at, because neither exists. Verify two things first. Confirm your upstream supports the Responses API before choosing that form, since the streaming path only helps if the upstream has it. Then read the troubleshooting document before you file anything, because the project explicitly routes most failure reports back to the upstream provider. ## FAQ ### What is Image-Studio? An open source desktop client for image generation and editing against OpenAI-compatible upstreams, built with Wails, meaning a Go backend with a React and TypeScript front end, plus an Android WebView shell. It supports both a Responses API mode over server-sent events or WebSocket, and the standard Images API endpoints. ### Why does Image-Studio use streaming instead of a normal request? Long image inference behind Cloudflare or Nginx gets cut off with a 524 or 504, which are proxy timeouts. The streaming transports keep bytes moving on the connection so the proxy does not time out an upstream that is still working. ### Do I need to configure an upstream in Image-Studio? Yes. The project ships with no default upstream. On first launch you fill in the API form, the base URL, an API key, a text model identifier and an image model identifier, and a test-connection action in that screen confirms all four before you generate anything. ### Is there a web version of Image-Studio? No separately deployed online version exists. The browser build in the repository is for front-end debugging and target platform preview, and the project states it is not equivalent to a SaaS web front end that can be served to other users. ### Can I modify Image-Studio and offer it as a service? Yes, under conditions. The project is licensed under the AGPL-3.0, and the README states that modifying it and redistributing it, or providing a modified version to others as a network service, requires publishing the corresponding source under the same licence. ## Sources - [Issues](https://github.com/RoseKhlifa/Image-Studio/issues) - [License: AGPL-3.0](https://github.com/RoseKhlifa/Image-Studio/blob/main/LICENSE) - [README](https://github.com/RoseKhlifa/Image-Studio/blob/main/README.md) - [Releases](https://github.com/RoseKhlifa/Image-Studio/releases) - [RoseKhlifa/Image-Studio on GitHub](https://github.com/RoseKhlifa/Image-Studio) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rosekhlifa-image-studio