If an image model is a horse, text prompting is like trying to guide it with verbal commands alone: useful, but too imprecise for fine control. Inpainting, LoRAs, and ControlNets add the bridle and reins—Nexfocus began with a question: *What would it take to build the whole harness around the model?*

Answering that question meant following the entire generation process first. We had to understand how each part loads, works, moves, waits, hands its result to the next part, and makes room when its job is done. We started from Fooocus and grew into a deep expedition which became Nexfocus.

---

Two development anchors shaped the journey: a GTX 1050 with 3 GB of VRAM and Colab Free's T4 with only 12.7 GB of system RAM. Their limitations are almost opposites. The local machine has very little GPU memory, while Colab Free has a larger GPU but a tight system-memory ceiling and an ephemeral session.

We proved that full SDXL checkpoints and Flux Fill workflows could run in both environments, not by reducing everything until it fit, but by rethinking how the pipeline uses the hardware available to it.

Nexfocus grew into a connected creative workspace where generation, guidance, masking, inpainting, outpainting, removal, upscaling, staging, metadata, model management, and GIMP layer exchange can work as parts of one process rather than as isolated tools.

---

Two important lessons emerged from the road:

- Keeping the GPU working without interruption became paramount. To do that, we had to find a way to keep feeding it the weights it needed, when it needed them.

- Every part of the pipeline must independently account for what it owns, where it belongs, when it can be reused, and when it should make room for something else. These decisions cannot be left to a central manager applying the same set of memory policies to every part.

Throughout this journey, my conversations with PyTorch often felt like this:

> PyTorch: "Don't you have a bunch of H100s lying around in your backyard?"

>

> Me: "No. What if every component has to justify exactly where it lives?"

>

> PyTorch: "Get a bigger machine."

Those conversations eventually became the architecture: each part of the pipeline owns its resources, does its job, and steps aside instead of leaving those decisions to hidden framework behavior.

---

Nexfocus is more than the UI produced by this expedition. It is the working application and the field notebook: a record of the constraints, wrong turns, and discoveries that shaped the path forward. We set out to find answers and had to build the road needed to reach them.

This expedition is now complete, but it is only one part of a continuing journey. The lessons from Nexfocus define the starting point for the next scout mission.

The path is open now. I hope you'll take a walk along the path we built and check out the scenery.

Project: https://github.com/magekinnarus/Nexfocus

Video Walkthrough: https://www.youtube.com/watch?v=5fvIaZWMZE4

If an image model is a horse, text prompting is like trying to guide it with verbal commands alone: useful, but too imprecise for fine control. Inpainting, LoRAs, and ControlNets add the bridle, reins, and pieces of the harness, but they still did not feel like a complete system. Nexfocus began with a question: what would it take to build the whole harness around the model?

Answering that question meant following the entire generation process first. We had to understand how each part loads, works, moves, waits, hands its result to the next part, and makes room when its job is done. That expedition became Nexfocus.

AI image models already know how to render- they understand photorealism, lighting, and texture better than any software framework. The real struggle has always been context control: feeding the model the exact spatial and structural context it needs to understand what to render.

This is where human input shines. By adding rough blocks of color and basic shapes to define the composition and color palette, the burden of text prompting is significantly reduced. Instead of struggling to describe a complex 3D scene in words, the artist controls spatial intent and lets the AI do what it already knows best—handling lighting, global occlusion, perspective consistency, and fine rendering.

Through the built-in GIMP plugin and Staging Palette, you can seamlessly composite background plates, sketch structural boundary guides for outpainting, or block out color guidance in GIMP with one click, then pass them back into Nexfocus to drive the diffusion pipeline.

Two development anchors shaped the journey: a GTX 1050 with 3 GB of VRAM and Colab Free's T4 with 12.7 GB of system RAM. We proved that full FP16 SDXL checkpoints and Flux Fill workflows could run in both environments by rethinking how the pipeline uses the hardware available to it.

Two important lessons emerged from the road:

- Keeping the GPU working without interruption became paramount. To do that, we had to find a way to keep feeding it the weights it needed when it needed them.

- Every part of the pipeline must independently account for what it owns, where it belongs, when it can be reused, and when it should make room for something else.

Throughout this journey, my conversations with PyTorch often felt like this:

> PyTorch: "Don't you have a bunch of H100s lying around in your backyard?"

>

> Me: "No. What if every component has to justify exactly where it lives?"

>

> PyTorch: "Get a bigger machine."

Those conversations eventually became the architecture. Nexfocus is both the working application and the field notebook: a record of the constraints, wrong turns, and discoveries that shaped the path forward.

The path is open now. I hope you'll take a walk along the path we built and enjoy the scenery.

GitHub: https://github.com/magekinnarus/Nexfocus

I can understand why you want to move away from heavy compute use cases such as coding. However, you still have products that need to work properly. When working with Gemini 3.5, I need to check every implementation plan and output line by line to catch something going badly, and it is way too exhausting.

In this case, there was an issue with pinned host memory. Gemini came up with a plan that went against everything the repo was built for. When questioned, it insisted that there was no other solution. I had to bring up Opus to intervene, and it found the solution. However, I ran out of my use of Opus by the time the implementation plan was updated.

So, I used Gemini 3.5 to implement the solution. Afterward, I asked it to update the project documents. Then I read through the changes and found that it deleted chunks of the report that weren't related to the work done. From reading through the deletions and changes, I realized that it was deleting the fix history. When Gemini 3.5 implements something, I always audit the work through Codex, and it was deleting the fix history that Codex made on its work. I immediately rejected the edit on the documents and had to instruct it again to preserve the fix history.

Can you do something about Gemini 3.5 so that I don't have to focus on every word it spits out to catch something going catastrophically wrong?