How we made 6,263 preset previews in Effect.app
Building and stress-testing automation for 88 preset pages with Effect.app MCP and GPT-6 Astra.
We needed thousands of images for Effect.app’s preset pages. Visitors should be able to see a filter on portraits, landscapes, and everyday objects before trying it on their own files.
The job was to run 86 source images through 88 presets, review the results, and prepare the useful ones for the website.
That is 7,568 source-and-preset combinations. It is also a lot of repetitive work to manage by hand.
We used Codex to coordinate the job, with MCP connecting the agent to Effect.app’s desktop application. The app applied the effects and rendered the images. The agents organized the work around it.
We finished with 6,263 approved previews across 88 preset pages. Along the way, the workload exposed problems in our app and in how we coordinated the agents. We fixed issues, recovered interrupted batches, and learned which checks mattered.
We had also made the job deliberately harder than a normal preview run.
We kept the large inputs on purpose
The smallest source by pixel count was 735 × 908 pixels; the largest was 4,491 × 6,737 pixels. That is about 0.67 to 30.26 megapixels—a 45-fold difference in pixel count. The set also included 4,160 × 6,240 and 6,240 × 4,160 images.
Our final previews only needed a maximum edge of 1,920 pixels. Resizing before export would have reduced the rendering load. We kept the large files because we wanted to find problems that a tidy set of small inputs might miss.
We were making images for the site while testing the app under load. The retries belong in that context.
The varied subjects mattered too. A preset that looks excellent on one portrait can lose important detail on another. A useful preset gallery needs enough variety to make those differences visible.
MCP gave the agent a way to operate the app
MCP, the Model Context Protocol, gives an agent tools it can call inside an application. Here, it let the agent select a preset and start an export with a list of source images.
Effect.app applied the selected preset’s effects to each image and saved the results in a folder. Once a preset was ready, the agent could send the full set of 86 inputs.
The agent managed one preset batch at a time. Effect.app’s renderer applied the effects to the source pixels.
That gave us a way to connect exports to the rest of the job. The agent could check a completed folder and pass it on for review while the next batch rendered.
One exporter, several jobs around it
The desktop app had one shared canvas. We gave a single export worker ownership of it so two agents wouldn’t change presets underneath each other.
Supporting agents resized and compressed JPEGs, then built contact sheets for review. They also maintained file lists and updated the preset pages’ image references. The coordinating agent inspected the sheets and recorded which images to keep. We stepped in when the agents needed an application fix or a change to the export settings.
Saved progress was essential. A batch needed a clear state: exported, checked, awaiting review, or finalized. Files appearing in a directory were only one part of completion.
Some workers ended their turns while more presets remained in the queue. Their saved progress told us where to resume.
We added an automation that woke the coordinating task every ten minutes. It checked worker status against saved progress and resumed unfinished batches that weren’t blocked. The coordinator held failed batches for investigation.
The coordinator checked how many presets were finished, even when a worker reported that its turn was complete.
The stress test found a GPU texture leak
Some interruptions came from the application itself. GPU overload could stop the run and require restarting Effect.app.
We found that the app kept a full-resolution GPU texture for each loaded image. It cached those textures under unique temporary addresses, called blob URLs, that would never be reused. In one recorded failure, the cache held 1,018 textures when the app lost its WebGL rendering context.
We stopped caching textures under those temporary addresses. In the recorded check after the fix, switching media six times added zero cache entries. Selecting the same image slot repeatedly reused a texture.
Loading image after image exposed a bug we could trace and fix while making the previews we needed.
The run also helped distinguish app failures from coordination pauses. Restarting an agent wouldn’t repair a lost GPU context. Restarting the application wasn’t the answer to an idle worker with a healthy queue.
How the agents checked 7,568 outputs
The agents first checked the files: did the batch contain all 86 expected images, could each one be fully decoded, and did its dimensions match the source? They also measured pixel brightness and variation to flag nearly uniform images and runs of blank output.
Then supporting agents resized the previews and assembled contact sheets. Each preset had two sheets: images 1–48 on the first, 49–86 on the second. The thumbnails kept their source indices so the coordinating agent could record exactly which images to exclude.
The coordinating agent inspected both sheets and saved the rejected image indices. Supporting agents then copied only the approved JPEGs to the final folders and updated the page references. A final check compared those references with the files on disk.
For Angelic, that meant 72 approved images and 14 excluded. The contact sheets let the agent compare the preset across different subjects while keeping every decision tied to a file.
The validator also flagged Mixed Media as all black. The export was capturing the start of its animation; moving to a later frame fixed the preview. The flag pointed us to the capture frame we needed to change.
For other troublesome batches, we tried sources resized to a maximum edge of 1,920 pixels. Old Painting, Slow Shutter, and Receipt Scans recovered with those inputs.
The finished preview library
The final review covered 7,568 current outputs. We approved 6,263 images and excluded 1,305. Those exclusions include unsuitable previews as well as failed images; they are not all crashes or rendering bugs.
The approved previews were JPEGs at quality 75, with a maximum edge of 1,920 pixels and no upscaling. Each of the 88 preset pages had its image references checked against the corresponding approved files.
We also found five complete batches from earlier work and reused them after validation. That avoided repeating 430 source renders. Next time, that inventory check belongs at the beginning.
The retained evidence establishes at least 95 render attempts, including the original runs behind the reused sets. That is a reconstructed minimum, rather than an exact count of everything this automation launched.
How we’d run the next large image job
We would first check for completed batches and set the output requirements. That tells us which inputs need resizing and which batches we can reuse.
We’d keep one worker in control of the renderer, with supporting agents preparing and checking the files. A saved record of each batch’s inputs and results would show where to resume after a stop.
We’d keep the visual review. An image can be a valid file and still be a bad example of a preset.
MCP let us put an agent in charge of exports inside Effect.app. We could inspect the same presets in the app, check the files it produced, and pick up from saved progress when a batch stopped. We finished with a preview library for 88 pages and a fix for the texture leak the run exposed.
Next time: inventory completed batches first, then one exporter + visual review.