Everything on one machine

My materials outline how to compare local AI generation against any alternative by weighing per-attempt marginal cost, iteration speed, quality ceiling, engineering overhead, provenance and reproducibility rather than presenting a vendor-price table [1][2][3][4][5]. They state that at library scale the marginal cost of an extra generation attempt approaches electricity alone on a single laptop-class GPU (8 GB) and that many attempts are typical in practice [1][2]. They also state the engineering burden of running locally is substantial and permanent — tooling for memory management, retries, quality gates and scheduling is required [3]. The materials warn that small‑memory local models have a quality ceiling (hands, faces, text) and hosted services or illustrators are better for a few hero assets [4][6]. Throughput and wall‑clock timings on the referenced 8 GB machine (measured September 2026) give concrete pacing: stills in seconds, animations in minutes, and a library maintenance pass taking a working day [7][4]. Supplier risk and control are documented: running locally makes upgrades a deliberate internal decision and preserves asset provenance and reproducibility because models and inputs are stored as files we keep [8][5].

Homeforge says the operational burden is substantial and effectively permanent and grows with the work you ask the machine to do: tooling to schedule multiple model families into an 8 GB envelope, handle memory pressure, crashed jobs, corrupt outputs and automated quality gates was required in production [1]. Economically, the fixed-engineering and model-storage costs are offset only when you operate at library scale and iterate many attempts—the marginal cost per attempt falls toward electricity, so high iteration rates make local operation sensible [2][3]. Supplier‑risk and deliberate upgrade decisions matter more as the library grows, because keeping old and new model files side‑by‑side and regenerating samples is operational work you must own [4]. If your volume is low or spiky, or you need burst capacity or someone unwilling to own infrastructure, a hosted API is the better choice [5].

Our materials say consistency is ensured by treating every model as a file you keep and storing each generated asset with its inputs and starting number so the same asset can be regenerated later with the same model files [1][2]. They also say upgrades are deliberate: before adopting a newer model we regenerate samples and compare them so a change in house style is a dated decision rather than silent drift [1][3]. Operational tooling schedules models so only one large model is resident at a time on an 8 GB GPU, which is how we avoid cross‑job interference on our single‑machine baseline [4][5].

We run automated quality gates as the first line of defense and keep a human as the final gate: tooling filters corrupt files and obvious failures, but humans remain the safety net for errors automation misses [1][2]. Every generated asset is stored with the original inputs and the exact model files so a reviewer (or engineer) can reconstruct or re‑generate the item on the same hardware and in the original style if it needs fixing [3][4]. When a human discovers a missed problem—for example the misspelled logos we caught—those assets are reworked or regenerated with the saved inputs and model, and checks or tooling are adjusted to catch the pattern in future runs [1][2]. The pipeline tooling also handles crashed jobs, memory pressure and corrupt files so reviewers only see outputs that passed automated checks, reducing false positives and making human review tractable [1].

The session materials describe what a maintenance pass looked like for the September 2026 run—regenerating 107 logos and repairing backgrounds across 119 games took about a day on one machine, with logo regeneration occupying the GPU for about an hour and forty minutes and the slower editing model taking roughly the same again [1][2]. ~11s for a 1024×384 still, ~89s for a 1280×720 edit, 6–7 minutes for a 6s looping clip) [3].

The materials state that small-memory local models have a clear quality ceiling that shows most strongly on hands, faces and—above all—text, with models frequently misspelling words inside images [1]. The same source explains that those weaknesses led to shipped logos with incorrect names and that automated checks can miss such errors when the vision checker also misreads them [1]. The notes also say hosted services provide higher-quality results for a small number of hero assets and access to larger models that exceed an 8 GB envelope, so hosted models are a better choice when absolute per-asset quality matters [2][1]. Finally, the case for local generation emphasizes that at library scale the marginal cost of iteration is lower, so many artifacts (like logos) can be re-run cheaply to repair misspellings—an operational trade-off versus paying per attempt on a hosted API [3].

Our materials say the operational burden is substantial and ongoing: the team had to build tooling to handle memory pressure, crashed jobs, corrupt outputs and truncated files, and those behaviors were discovered in production [1]. They say local operation requires somebody on the team to own the infrastructure and to cheerfully debug memory exhaustion and other failures, or else the pipeline will rot [2][1]. The work producing no art — scheduling multiple model families into an 8 GB envelope, retries and automated quality gates — is described as the real investment rather than hardware costs [3][4]. Power and per-batch energy are small compared with engineering time, which the documents identify as the dominant ongoing cost [5][4].

The materials say the scheduling problem is solved with operational tooling that makes large models "take turns" so only one large model is resident at a time on the 8 GB GPU [1]. They state that this tooling handles memory pressure, crashed jobs, corrupt outputs and models that refuse to load, and that building that tooling is substantial ongoing work [2]. The documents note a 24 GB GPU would remove most of this scheduling work, implying the 8 GB ceiling is the driving constraint [1]. They also describe job-level effects (animation dominates wall-clock time and jobs are run serially) that shape scheduling needs [3].

The materials define reproducibility as producing the same picture when you rerun the same starting number, the same model files, and the same description, and they say Homeforge keeps those three so a later regeneration repeats the original process [1][2]. The documents emphasize that this lets a past asset be reconstructed in its original style and that upgrades are deliberate rather than silent drift [1][3][2]. The sources describe operational failures we encountered (models that refuse to load, truncated images, corrupt outputs) and the engineering work needed to handle them, but they do not enumerate low‑level causes such as driver differences or nondeterministic GPU kernels [4].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

The pipeline preserves reproducibility by storing every generated asset together with the exact inputs and the model files so the same request can be rerun later and produce the same image [1][2]. Early-phase iteration is made affordable because the marginal cost per attempt on our baseline machine is essentially electricity (a two‑hour GPU batch draws ~0.25 kWh), so teams can try many variants without per‑API charges [3]. The tradeoffs are explicit: local setups have no burst elasticity and require substantial engineering to fit multiple model families into an 8 GB GPU envelope, handle memory failures and run automated quality gates before human review [4][5]. In short: reproducibility is preserved by keeping inputs+models, iteration is enabled by low marginal cost, and the balance is operational — you accept slower wall‑clock parallelism and more engineering work in exchange for repeatability and low per‑attempt cost [1][2][3][4][5].

We run automation as the first line of defense and keep humans as the final gate: automated quality gates reject corrupt or truncated outputs, verify title text and symbol coverage, and filter obvious failures before a person ever opens a file [1][2]. Every generated asset is stored with the inputs and the exact model files so a reviewer can reconstruct or re‑generate a questioned item on the same hardware, making human audits tractable and repeatable months later [3]. The pipeline tooling also handles memory pressure, crashed jobs and corrupt files so auditors see only outputs that passed those checks; that tooling is substantial and a permanent engineering responsibility for the team [1][2]. Because small‑memory models have a quality ceiling on hard cases (hands, faces, text), human review remains necessary as the ultimate safety net for errors automated checks miss [2].

We treat every generated asset as a recorded artifact: the finished image is stored together with the input that produced it, the starting number, and the exact model files used so an item can be regenerated later in its original style [1][2]. When we consider adopting a newer model, we regenerate a sample of existing work with the candidate model and compare results before upgrading, so the change becomes a deliberate, dated decision rather than silent drift [2][3]. Practically, that means we can keep the old model beside the new one and rework a single asset in its original version when a project needs it, while other projects move to the newer model on our schedule [2][4]. This approach requires substantial operational tooling and staffing to manage multiple model families, memory scheduling and quality gates across the shared 8 GB GPU envelope [5][3].

When we see a new model produce a different style, we regenerate a sample of existing work with the new model and compare those outputs against the originals before adopting the new model [1][2]. We keep the old model file beside the new one so the old behavior remains available if we decide not to switch immediately, and the upgrade becomes a deliberate decision with a date rather than a silent drift [2]. If an individual asset must stay in the original style, we rework or regenerate that asset with the original model so it remains consistent with the library [1][3]. These steps let us treat an upstream change as a policy decision rather than an unexpected break in style [1][2].

Our materials say we mitigate hardware-failure risk in two complementary ways: (1) tooling that detects and recovers from crashed jobs, memory pressure and corrupt or truncated outputs so a failed long run does not silently produce bad assets [1], and (2) storing every generated asset together with the inputs that produced it and the exact model files on disks we control so assets can be regenerated later if a result is lost [2]. The documents also emphasize that this approach requires ongoing engineering and someone to own the infrastructure—handling crashes and recovery is part of a permanent operational burden you must staff for [1][3]. Finally, because we run locally we do not have burst capacity to buy speed or instant redundancy from a provider, so recovery is operational rather than elastic [1][3].

Local generation preserves reproducibility because every asset is stored with the inputs and the exact model files so an asset can be regenerated later in the same style [1]. Local setups have no burst capacity: you cannot spend money to go faster, so deadline spikes create single‑point failure risk [2][3]. Managing that trade‑off is operational: you must schedule multiple model families into a constrained GPU envelope (an 8 GB class GPU), handle memory pressure, crashed jobs and corrupt outputs, and run automated quality gates so the system rejects bad outputs before human review [2][4]. The honest summary is that running locally trades a supplier relationship for an ongoing engineering burden you must staff for; if nobody will own that infrastructure, a service is the recommended option [5][3].

We preserve consistency by treating every generated asset as a reproducible artifact: the exact input, the starting number and the model files are stored so the same request can be repeated later, which lets us recreate an asset in its original style even after artistic direction moves on [1][2]. Before adopting a newer model or style, we regenerate a sample of existing work with the candidate model and compare it to originals so a house‑style change is a deliberate, dated decision rather than silent drift [1][3]. Automated quality gates and tooling reject bad outputs (misspellings, truncated images, off‑brand symbols) before human review, and we run maintenance passes across the library to keep assets consistent over time [4][5]. When volume and iteration are required, this workflow makes iterative correction affordable because marginal cost is mostly electricity [5].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

Homeforge’s materials say real‑time collaboration across teams is handled by operational practices rather than by a hosted service: all generation runs on machines you control and model files are kept locally so every asset is stored with its inputs and can be reconstructed later [1][2]. That approach requires substantial, ongoing engineering to schedule multiple model families into an 8 GB GPU envelope, handle memory pressure, crashed jobs, corrupt outputs and automated quality gates that reject bad results before human review [3][4]. Because one GPU is one job at a time and there is no burst capacity, concurrent teams compete for fixed local compute and wall‑clock time rather than buying parallelism on demand, so deadlines and spikes remain a practical constraint [5][3]. If nobody on the team will own that infrastructure, the documents recommend using a hosted service instead [6].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

We treat every generated asset as a recorded artifact: the finished image is stored together with the description (the input), the starting number, and the exact model files used so the exact output can be recreated later [1][2]. When projects share model families, we keep the model files as local files and keep old and new model files side‑by‑side so upgrades are deliberate — we regenerate samples and compare before switching anything that other projects rely on [3][2]. Operationally, that requires tooling to schedule multiple model families into constrained memory (an 8 GB GPU envelope), handle memory pressure, crashed jobs and corrupt outputs, and run automated quality gates that reject bad outputs before human review [4][5]. Those practices let overlapping projects reuse the same archived model files and inputs while preserving the ability to reproduce any asset on demand [1][2].

We keep every model file as a local file and store it alongside the inputs and the starting number used to generate an asset so the exact generation can be repeated later [1][2]. Before adopting a newer model we explicitly keep the old model beside the new one and regenerate samples to compare outputs, making upgrades deliberate and versioned by choice rather than happening silently [3][2]. Every generated asset is archived with the description and the model that produced it so a specific asset can be reconstructed months later from those stored files [1][2].

We build automated quality gates as the first line of defense and keep humans as the final gate: tooling rejects corrupt or truncated outputs, verifies title text and symbol coverage, and filters obvious failures before a person ever opens a file [1]. Every generated asset is stored with the inputs and the exact model files so a reviewer can reconstruct or re‑generate a questioned item on the same hardware, making human audits tractable and repeatable months later [2]. The pipeline tooling also handles crashed jobs, memory pressure and corrupt files so auditors see only outputs that passed those checks; running locally means that infrastructure and audit tooling are permanent engineering responsibilities rather than an external service feature [1][3].

Our materials say we built tooling that handles crashed jobs, memory pressure, corrupt or truncated output files, and models that refuse to load, and that we discovered those behaviors in production and handled them in tooling [1]. The same documents describe automated quality gates that read outputs and reject bad results before human review, reducing the impact of a failed run producing corrupted assets [1]. They also explain that running locally trades supplier elasticity for an operational burden you must staff for, so dealing with hardware failures is treated as part of that ongoing engineering work rather than a service you can outsource [1][2].

Our finished library is small — 232 games (2,547 stills, 1,506 clips, 1,149 audio tracks) total about 2.2 gigabytes as of September 2026 [1][2]. Model files are the heavyweight part — our collection of model files runs to several hundred gigabytes, roughly a hundred times the finished library [2]. Every generated asset is stored with the inputs that produced it and the models are kept on disk so assets can be regenerated in the original style later [3]. In practice, library-wide maintenance (e.g., repairing or replacing logos across 119 games) ran as a single-machine job that occupied the GPU for about a day and was mostly unattended, showing that full-library retrieval and batch updates are feasible on one workstation [4]. a few cents — though the materials stress engineering and wall-clock time are the larger costs [5][6].

The finished library for 232 games is about 2.2 gigabytes as of September 2026 [1][2]. The library contains 2,547 still images, 1,506 animated clips and 1,149 audio tracks, which are the working totals rather than projections [2]. Every generated asset is stored together with the inputs that produced it and the model files used, and those model files are kept on disk rather than called as a service, which lets the team regenerate or rework individual assets in the original style months later [3][4][5]. The materials describe a practice of regenerating samples when adopting a newer model to decide whether to upgrade, which supports deliberate reuse or replacement of assets across the library [4][5].

Scaling across simultaneous projects requires the operational practices we describe: you must run all generation on the machines you control, keep the model files locally, and store every asset with its inputs and model files so work can be reconstructed later [1][2]. That approach imposes a substantial, ongoing engineering burden: tooling to schedule multiple model families into an 8 GB GPU envelope, handle memory pressure, crashed jobs and corrupt outputs, and run automated quality gates before human review [3]. You also have no burst capacity to buy extra parallelism on demand, so concurrent teams compete for fixed local compute and wall‑clock time rather than paying to scale instantly [3][4]. If nobody on the team will own that infrastructure, the documents recommend using a hosted service instead [4].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

Homeforge’s materials say we treat every generated asset as a recorded artifact: the finished image is stored together with the description (the input), the starting number, and the exact model files used, all kept on our disks so a piece can be regenerated later if needed [1][2][3]. Before we adopt a newer model we regenerate samples of existing work and compare them to decide whether to upgrade, so version changes become deliberate, dated decisions rather than silent drift [2][4]. Operationally, the pipeline includes substantial tooling — scheduling models into an 8 GB envelope, handling memory pressure, crashed jobs and corrupt outputs — and automated quality gates that reject bad outputs before human review, which supports consistent lineage across the library [5][4]. These practices make reconstruction of an item on the same hardware possible and keep the library coherent over time [1][6].

Homeforge’s materials say this trade is explicit: running locally requires someone on the team to own the infrastructure and debug it, and if nobody will do that, you should use a service instead [1]. The documents call the engineering burden substantial and permanent — scheduling models into an 8 GB envelope, memory management, crash recovery and automated quality gates are real, ongoing tasks discovered in production [2]. They frame this as a deliberate choice: local operation trades a supplier relationship for an operational burden that must be staffed, and that burden is part of the cost of ownership at our volume and workflow (measured September 2026) [3][4].

Local operation eliminates supplier drift and keeps model files and inputs on disks you control [1][2]; it also makes assets regenerable months later, which matters for regulated titles [3]. The trade is real: the engineering burden to manage models in an 8 GB envelope, handle crashes, memory pressure and automated quality gates is substantial and permanent [4]. Economically, local wins when iteration-at-volume makes the marginal attempt cost approach electricity on modest hardware; if your needs are low, spiky, or require burst capacity or the highest per-asset quality, a hosted API is the better choice [5][6]. Concretely, decide by estimating your iteration rate, regulatory need for reproducibility, and whether you can staff the ongoing operational work [6][4].

An 8 GB GPU imposes a clear quality ceiling for hard cases, and complex environments are among those hard cases because they contain many interacting elements that small models handle less well [1]. The 8 GB limit shapes every downstream choice: models are chosen or compressed to fit, and generators must be scheduled so only one large model is resident at a time, which constrains fidelity and workflow for environment-heavy assets [2]. Practically, that means more engineering work (memory management, retries, quality gates) and more iteration to reach acceptable results rather than a single high‑quality pass, because you trade model size for fit and repeat attempts for final quality [3][4]. A machine with 24 GB or more would remove most of that work and raise the attainable fidelity for complex scenes [2].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

An 8 GB GPU baseline imposes a clear quality ceiling that most affects hard cases such as faces, so high‑fidelity facial expressions are limited on that hardware [1][2]. Models small enough to fit in 8 GB are not the largest available, and that gap shows most clearly on faces and complex interactions [1]. The 8 GB ceiling drives model selection, compression and scheduling choices that trade fidelity for fit, and larger‑memory machines (24 GB or more) would remove most of that work [2]. Because animation and iterative fixes are common, teams on 8 GB hardware rely on many regeneration attempts and engineering checks to reach acceptable results rather than a single high‑quality pass [3][4]. If you need hero‑level facial fidelity for only a few assets, the materials say a hosted service or different approach is the better choice [5].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

Local generation on small‑memory models has a clear quality ceiling on hard cases such as hands, faces and text, and those models misspell words inside images regularly [1]. Hosted services produce higher‑quality results for a small number of hero assets and provide access to larger models that exceed the 8 GB envelope we run on, so they are the better choice when absolute per‑asset quality matters [2][1]. At library scale, local generation makes iterative fixes cheap (marginal cost approaches electricity), so you can re‑run and repair many artifacts across hundreds of assets rather than accept the third‑best try for budget reasons [3]. Running locally also lets you keep old models alongside new ones so a large library stays visually consistent over time, which is important when regenerating or repairing items later [4][5].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

We treat automation as the first line of defense and humans as the final gate: engineering builds automated quality gates that check for memory‑truncated or corrupt outputs, verify title text and symbol coverage, and reject bad artefacts before a person ever opens them [1]. Reproducibility practices — storing every asset with its inputs and the exact model files — make human audits tractable because a reviewer can reconstruct or re‑generate a questioned item on the same hardware [2][3]. That tooling is substantial and permanent work (scheduling models into an 8 GB envelope, handling crashes and retries) and does not produce art, so you must staff and budget it like any other ongoing engineering cost [1][4]. If nobody on the team will own that work, a hosted service is the better choice, because local pipelines require someone to debug outages and audit failures [5].

Reproducibility improves long‑term pipeline reliability because keeping the original starting number, model files and inputs lets you repeat an exact generation later rather than approximating it [1]. That capability is operationally important for regulated titles that may require reconstructing assets months after release [2]. The trade‑off is reduced burst capacity: a local machine cannot buy on‑demand speed, so deadline pressure can create single‑point failure risk when load spikes [3][4]. Mitigating that risk requires substantial, ongoing engineering—scheduling models into an 8 GB envelope, handling memory pressure, crashed jobs, corrupt outputs and automated quality gates—work that does not produce art but is necessary for a reliable local pipeline [3]. In short, reproducibility raises long‑term correctness and auditability; lack of burst capacity raises short‑term deadline risk, and you pay for reliability in engineering effort, not per‑attempt fees [5][3].

Homeforge states that the engineering burden of local generation is substantial and permanent, because tooling to schedule multiple model families into an 8 GB envelope, handle memory pressure, crashed jobs and build automated quality gates was required in production [1]. The hosted-API path avoids that engineering work but incurs per-attempt pricing that makes iteration expensive at scale, so the economics only make sense for a large library where marginal cost per attempt falls toward electricity on a single laptop-class GPU with 8 GB VRAM [2][3]. Homeforge also says hosted services provide burst capacity and elasticity that local setups lack, so scaling with a provider buys on-demand speed that local machines cannot purchase [1][4]. The honest summary in Homeforge's evaluation is that local generation trades a supplier relationship for an operational burden and is right for a small studio producing many assets for regulated products, but not for everyone [5][6][4].