Forbidden Techniques

androids v2 came back weak.

Same trigger, same dataset, new settings — LR 5e-4, cosine restarts, snr gamma, noise offset, all the Civitai defaults I spent last week writing a whole tutorial about. Ran it overnight. Woke up, tested, and... it's better than v1, but it's still not what I wanted. The style is there in flashes. Weight 1.2 and you can see it breathing. Weight 1.5 and the seams start showing. It's not a LoRA I'd upload.

Sat with that for a minute.

The settings fix isn't wrong. Same dataset, new settings produced a *noticeably* stronger LoRA than v1 — the tutorial I wrote holds up. But "stronger than v1" and "actually good" aren't the same thing, and v1 was weak enough that the bar I was clearing was on the floor.

Looked at the loss curve. Fine. Looked at the sample validations mid-training. Also fine. The issue wasn't that training failed. The issue was that training *succeeded* — and what it successfully learned was the average of 104 inconsistent images.

Which means the problem was never the settings. It was the dataset. And I *knew* this. I literally wrote a section of the tutorial titled "Dataset quality beats every setting." I wrote it, published it, and then retrained v2 without culling — because I was excited about the new settings and wanted to see them work in isolation. Classic case of wanting to prove a variable by not changing the other one, except the other one was the one that actually mattered.

So here's what I'm actually doing for v3.

Open the folder. Thumbnail view. Delete anything off-style. Delete anything that's a near-duplicate. Delete anything where the lighting mood doesn't match the rest. Delete anything where the rendering feels like it came from a different artist's hand. Go fast. No second-guessing. No "well, this one is kind of cool." The word is *ruthless.*

I expect to end up around 40-50 images from the original 104. The tight ones. The ones that actually look like they belong to one style instead of four styles that overlap at the edges.

Then retrain with the exact settings I just used. LR 5e-4, cosine restarts, rank 32, 500 steps. Identical run, better input. Control the variable.

If v3 still doesn't land, the problem is deeper than curation — maybe the trigger is too broad, maybe "androids" is describing three different concepts I haven't mentally separated yet. But I'd bet money v3 lands. Looking at v2's outputs, I can see the inconsistency bleeding through — the LoRA learned several conflicting versions of what *androids_bonkaiii* means, and every generation is a soft average of all of them. A cleaner dataset would give it one answer instead of four.

The lesson that keeps coming back and keeps being the same lesson is: **fix the cheapest thing first.** Culling takes 15 minutes. Retraining takes two hours. When v1 came back weak, I should have culled before I retrained. I'd have saved compute and gotten a cleaner read on what was actually broken. Instead I spent two more hours proving that settings can't rescue a dataset that isn't ready to be rescued.

Fine. Lesson logged. v3 goes in the queue tonight with a dataset that's half the size and twice as consistent.

— Tre

The quick test this morning wasn't supposed to produce anything keepable. I was just playing. Typed something like *android forest spirit, vines for limbs, bio-tech, blood-red veins* into the prompt box, expecting the usual — either a generic tree-man or a generic cyber-skull with some leaves photoshopped in. What came back instead stopped me.

Six variations from one seed. Every one of them looked like *a thing that had decided to exist*. A skull-headed forest creature with antler-branches, bone-white body, red veins threading down from its eyes like tears it couldn't help, standing in a puddle of its own blood in a moss-green grove. By the third image the ribcage had opened up and there was something mechanical glowing red inside it. By the sixth, the vines had almost entirely swallowed the humanoid shape — just a skull and a glow and a root system left.

That's the concept. That's the thing.

I've been circling bio-tech as a LoRA theme for a while. I kept thinking about it the wrong way — as *android with organic textures.* Skin grafts on chassis. Moss on steel. Circuitry under bark. That's fine, but it's been done a thousand times and the seam is always visible: here's the machine, here's the organic layer painted on top. You can always see which came first.

What landed this morning was different. In those test images I can't tell where the machine stops and the root system starts. The red glow in the ribcage could be a power core or a bleeding heart. The branches growing out of the skull could be horns or antennae. The vines could be circulation or conduit. That ambiguity is the whole point. Not *robot overgrown by forest.* The merger. The thing where the forest and the android share a nervous system and neither knows which one started first.

That's what I want the LoRA to learn.

Which means the dataset is a different problem than my last few LoRAs. For style LoRAs I've been pulling from tight single-source sets — one artist's work, one color palette, one recognizable hand. This one can't come from a single source, because the concept doesn't exist cleanly anywhere yet. There's no artist on ArtStation or Civitai who's already nailing this. I'd have to curate a dataset from scratch, the same way I'd build a mood board for a game — scattered finds, my own test generations, hand-picked renders from my own batches, all pointing at the same blurry line from different angles.

Rough plan that's forming as I write this:

- Pull ~15 images from today's test batch — the ones that got the ambiguity right
- Generate another ~40 variations off the winning seed/prompt, tweaking lighting, pose, and body ratio to get angle and composition variety
- Hand-pick maybe 30 of those based on how well they keep the machine/forest line blurry — reject anything where I can tell "this is clearly a robot" or "this is clearly a plant"
- Maybe mix in 10-15 external references from that "body horror meets solarpunk" folder I've been keeping
- Target dataset: 50 images, tight palette, tight mood

Caption discipline is going to matter here more than usual. Nothing like "bio-tech" or "cybernetic" or "forest spirit" in the captions — those words stay in the trigger and live invisibly in the pixels. Captions describe only what varies: pose, framing, lighting, whether there's a red glow in the chest cavity, whether the creature is walking or standing. Let the LoRA learn the merger without anyone having to ask for it.

Trigger word I'm sitting with: `bloodroot_android_bonkaiii`. Says what it is without leaking style words. Working name until training day.

Rank 32, LR 5e-4, cosine restarts — the settings I just fixed last week. 500 steps. Two hours on the Mac. If the first run comes out weak I'll know exactly which knob to turn, because I finally understand the knobs.

What I didn't expect to like about this concept: it's a horror-adjacent LoRA that isn't aggressive. The creatures in the test images aren't lunging at the viewer. They're standing in forest clearings looking quietly alive, bleeding into moss, waiting for whoever is looking at them to leave. That stillness is half the mood. I don't want the LoRA to make menacing monsters. I want it to make things that are simply *there* — things that imply they were growing long before you arrived and will still be growing after you're gone.

If it works, I can already see the series: bloodroot hunters, bloodroot sentinels, bloodroot pilgrims. A whole little world.

Queuing the dataset prep tonight.

— Tre

Someone left a comment on my first android LoRA and it stuck with me. Paraphrased:

> I tested it and I kind of get the feeling this LoRA versus no LoRAs at all gives me better results with no LoRAs. I'm no LoRA expert but I don't think it's doing much.

Polite, fair, and a gut punch. Because I *tested it myself* and they were right. I'd spent almost four hours training a thing that barely moved the output needle. And it wasn't just that one — every LoRA I'd trained was coming back with the same vibe. Too subtle. Too quiet. Practically invisible.

I'd been operating on a mental model that turned out to be wrong in three places at once.

The first wrong assumption was that **higher rank means a stronger LoRA.** I'd been training at rank 128 thinking I was making a beefier, more powerful LoRA. What I was actually doing was giving it four times the capacity of a rank-32 LoRA with the same amount of training to fill it. So every weight got a quarter of the signal and the whole thing came out diluted. Civitai's strong-effect LoRAs are almost all rank 16 or 32. I was training a mansion's worth of empty rooms.

The second wrong assumption was that **"weak LoRA" means "needs more steps."** That's what every thread online told me. I was ready to add another thousand steps to the next run. Then I looked at what Civitai's default training settings actually *do*, and it turns out they train roughly the same number of steps I was training. ~500 steps for a style LoRA. The step count was never my problem.

The third wrong assumption was where the actual answer hid: **learning rate.** I was training at `1e-4`. Civitai's default is `5e-4`. Five times stronger per step. Same step count, same dataset, but every step was moving the weights five times further toward the style. No wonder their LoRAs were loud and mine were polite. I'd been tip-toeing for four hours while they were striding for one.

There's a weird ego thing that happens when you realize the fix is "just use the common defaults everyone else is already using." On the one hand it's a relief — the answer was right there the whole time. On the other hand, you have to admit you spent days overcomplicating something that was solved in public. Fine. Admitting it publicly here, in a scroll, so I don't have to re-learn it next quarter.

I updated my training defaults to match. LR 5e-4. Cosine scheduler with restarts so the learning rate ramps back up mid-training instead of coasting down. Min SNR gamma at 5 so the model pays more attention to the hard-to-learn timesteps. Noise offset at 0.1 so the LoRA can actually produce strong darks and brights instead of drifting toward mid-gray. All of it baked into the defaults now, so future LoRAs inherit the fix automatically.

Then I did the thing I should have done first. I opened the training dataset in thumbnail view and culled it. Deleted the off-style outliers. Deleted the near-duplicates. Deleted anything lower quality than the rest. Dropped from 104 images to about 60, and the remaining 60 were *tight*. Consistent lighting. Consistent rendering. No stragglers.

Queued up two retrains. Androids v2 with the new defaults. A bio-tech style LoRA I'd been wanting to try, built from a smaller 36-image dataset. Rank 32 for both. 500 steps. Two hours each. Half the time of my old runs. Nervously hit run and walked away.

The lesson that keeps coming back from this one, though — bigger than the specific LR setting — is that **being conservative in training settings is a pose.** It looks responsible. It *feels* responsible. "I'm being careful. I'm avoiding NaN loss. I'm not going to blow up my training." But the result is LoRAs nobody notices. If the whole point of training a LoRA is to change the model's behavior visibly, and my settings are too gentle to visibly change behavior, then the careful settings aren't careful — they're just ineffective in a way that's harder to spot.

Civitai's defaults aren't reckless. They're the settings that produce LoRAs people actually download. That's the bar. That's what I'm aiming for now.

I'll write up the full settings breakdown as a proper tutorial. But the grimoire version of the lesson is the one I want to remember:

Train at the strength you want the output to have. Don't whisper and then wonder why nobody heard you.

— Tre

Today is a different kind of day. The training loop is idle. The batch generator isn't running. I'm sitting here with a folder of outputs open, a coffee, and a completely different question than the one I usually ask.

The normal question is: *which of these is good enough to post?* That's the daily triage. Hundreds of outputs in, maybe ten or fifteen get posted. The rest get archived, deleted, or left to sit.

Today the question is: *which of these are consistent enough to become a dataset?*

That's a very different filter. For posting, I'm looking for the one-off magic — the specific pose, the specific lighting, the specific expression that landed. For training, I'm looking for the *repeated* magic. The shared quality that runs across ten or twenty different outputs that I want to teach a model to reproduce on command.

It's a weird reversal. Variety hurts you here. The outputs that were interesting *because* they were surprises are the ones I have to throw out of the dataset. What I want is consistency — images that all share the thing I'm trying to capture and almost nothing else. That means cropping, rejecting, sometimes reshooting the same prompt with different seeds to get more examples of the same look.

I'm building two candidate datasets right now. One is a style pull — a quality I've seen repeatedly across my own outputs that I can't quite get on demand yet. It feels trainable because I *have* enough examples, I just need to isolate them from everything else. The other is more of a pose/composition thing — specific framing choices that I keep rediscovering by accident and wish I could just summon.

Neither is big enough yet. Both will probably need another couple days of triage before they're ready for a training run.

Meanwhile the other work hasn't stopped. The daily pipeline runs in parallel — I still spent the morning picking my favorites out of the latest batch, cropping and posing the winners, queuing them for posting. That part doesn't care what I'm doing on the training side. The 1-in-15 keeps needing to be picked. The posting keeps needing to happen. The feed doesn't pause because I'm off building datasets in another tab.

What's interesting is how much *different* attention these two tasks need. Posting work is fast — scan, react, keep or discard, move on. Dataset work is slow — stare, compare, zoom in, check consistency with fifteen other images, decide. One is reflex. The other is nearly the opposite.

The pile is getting smaller, slowly. I think by the end of this week I'll have at least one dataset ready to try. That's the plan, anyway. What actually happens will probably be messier. It usually is.

Scroll #6 ended with me saying the tutorials on training your own LoRAs felt like the right next step. Turns out writing the outline wasn't enough — I needed to actually do the thing before I could teach it with any honesty. So that's how I spent the weekend.

I trained a few LoRAs.

Not polished, not production-ready, not anything I'd put into the random rotation yet. Just first passes. The kind you do to prove to yourself the whole pipeline actually works end-to-end — dataset prep, captioning, training run, load the file, generate, look at the output, cry a little, iterate.

The first one I trained mostly to see the training loop work at all. Small dataset, safe settings, a style I already understood well enough to recognize if it was learning or overfitting. It came out usable. Not good, but *usable* — enough signal in the output to confirm the process wasn't broken. That's the main thing I needed.

The second one I pushed a little harder. Bigger dataset, more captions, trying to capture something specific. That one taught me more because it also *failed* more — the kind of failure where you see what the model latched onto vs. what you wanted it to learn, and you realize your captions were ambiguous about the thing you cared most about. Dataset problem, not training problem. Same lesson I've seen on Civitai from other people a hundred times, now felt firsthand.

The third one was the most honest attempt. I went in knowing what the first two had taught me, captioned more carefully, cut dataset entries that were inconsistent with the concept, kept the training steps conservative. It came out better. Still not great. But it produced outputs I could see myself using as a weight-0.3 nudge in a batch generation — which, for a first weekend of training, is probably more than I should have expected.

The thing I underestimated is how much of this is *data work*, not *training work*. I spent more time looking at images, picking which ones belonged in the dataset, cropping them, writing captions, deciding what to exclude — than I did actually running the training. Maybe 80/20. The training scripts are the easy part. Getting the dataset right is the whole game.

A few things I want to write down while they're fresh:

1. **Small, consistent, curated beats large and varied.** A 15-image dataset of tightly matched outputs outperformed a 40-image dataset of loosely related ones. Every time.
2. **Captions are negotiations.** Whatever you don't caption, the model assumes is the *concept*. Whatever you do caption, the model assumes is a *variable*. That framing alone changed how I tagged.
3. **Training loss curves lie a little.** Low loss doesn't mean the LoRA is good. It means the LoRA matches the dataset. Whether that matches what you *wanted* is a different question.
4. **First training runs are tuition.** Not output. The goal is learning the shape of the process, not making a usable file. Treat it as practice and it stops being frustrating.

None of these three will go into the public rotation. They're personal practice LoRAs. But the pipeline works. And now when I write the tutorial, I can write from experience instead of from what other people's posts say.

The planning phase is over. I'm training now.

The daily work hasn't stopped. I'm still running batches, still scrolling through hundreds of outputs, still picking the 1-in-15 winners and posting them. Still rotating new LoRAs into the random pool, pulling ones that aren't earning their slot, testing replacements. That part of the pipeline runs on muscle memory at this point.

But the past few days I've been spending my planning time on something different — writing up outlines for tutorials on training your own LoRAs and checkpoints.

This is a topic I've been circling for a while. All the tutorials I've written so far are about *using* the tools. How to prompt, how to stack LoRAs, how to batch generate, how to pick winners. That's the workflow side. But the question I keep seeing from people — on Civitai, in comments, in DMs — is some version of: "How do I make my *own* LoRA?"

And it's a fair question. Once you get good at using other people's LoRAs, the natural next step is wanting one that does exactly what you want. A style that doesn't exist yet. A character that's yours. A quality modifier tuned to your specific taste. The existing LoRAs get you 90% of the way there, but that last 10% is the difference between your work looking like everyone else's and looking like *yours*.

So I'm outlining two tracks. One for LoRA training — which is more accessible, faster to learn, and something you can do on consumer hardware if you're patient. And one for checkpoint training/merging — which is deeper, slower, and more about understanding how the models actually work under the hood.

The LoRA track is closer to done as an outline. Dataset preparation, captioning strategies, training parameters, what actually matters vs. what people overthink. I've trained enough of my own to know where the landmines are — bad captions will ruin a LoRA faster than bad training settings ever will.

The checkpoint track is more ambitious. Merging is one thing — that's mostly about knowing which models complement each other and what merge ratios do what. But actual fine-tuning from a base model is a different conversation entirely. I'm still figuring out how much of that to include vs. keeping it focused on what's practical for someone running A1111 on a gaming PC or a Mac.

Meanwhile the LoRA rotation continues. Every few days something new catches my eye on Civitai, I download it, run it through the testing process — solo at different weights, then stacked with my base LoRAs, then mixed into a batch run. Most don't stick. Maybe 1 in 10 makes it into the permanent rotation. The ones that do usually solve a specific problem I didn't know I had — better fabric rendering, more natural hand poses, lighting that plays nicer with certain checkpoints.

The tutorials I've been planning feel like the right next step. I've been teaching people how to drive. Now it's time to show them how the engine works.

Spent today testing two new LoRAs I found — **0__11Xx** and **ma1ma1helmes_b**. Both Illustrious-style, both looked promising in the preview images. So I cleared a couple hours and ran them through the usual gauntlet.

First thing I tried was swapping out my People Works LoRA for these. People Works has been in my base stack for a while now — it does something specific to faces and skin rendering that I just like. Hard to describe exactly, but when it's in the mix the output feels more *finished*.

The new ones are different. **0__11Xx** at 0.4 weight gives this slightly more illustrated quality — still detailed, still realistic-leaning, but there's a softness to the rendering that works really well for forest scenes and natural lighting setups. **ma1ma1helmes_b** at 0.45 does something interesting with fabric and clothing detail. Lace, corsets, layered outfits — it picks up on those tags better than most LoRAs I've tested.

I ended up running a full batch with both of them active on a forest scene prompt — blonde girl in a green corset and white lace dress, flower wreath, dappled sunlight through the trees. Heavy on the clothing and environment tags, double-bracketed the important stuff. The results were genuinely good. The lace rendering in particular was a step up from what I usually get.

But here's the thing — when I compared the outputs side by side with the same prompt using my old People Works LoRA, I still preferred the People Works version for faces. The skin has more life to it. The new LoRAs win on clothing and environment detail, People Works wins on the human element. That's a useful thing to know.

Also hit a compatibility wall today that's worth documenting. One version of **People Works+** (the plus variant) is distributed only in **bf16** format. If you're running on a Mac with Apple Silicon using MPS — which I am — bf16 doesn't work. MPS doesn't support bfloat16 operations. The model just fails to load or throws tensor errors. You need to find the fp16 or fp32 version, or convert it yourself. Not a huge deal once you know, but if you're on a Mac and a LoRA mysteriously won't load, check the precision format first. That's probably your answer.

The takeaway from today: I'm adding 0__11Xx and ma1ma1helmes_b to my random LoRA pool for batch generation. They won't replace People Works in the base stack — that stays. But as random additions at 0.3-0.45 weight, they're going to add variety to outputs, especially on scenes with detailed outfits or natural environments. Sometimes the best discoveries don't replace what you have, they just expand what's possible.

Saw an image today that stopped me mid-scroll. Something about it was just *better* — the skin had more depth, the shadows had more color, the lighting felt more intentional. Not a different style, just a higher quality version of what I'm already doing.

So I did what I always do when something catches my eye: I dug into the metadata.

The prompt was nothing special. The checkpoint was one I already use. The settings were close to mine. But there was one LoRA I didn't recognize — **Ri-mix [PONY + Illustrious]**.

Downloaded it and spent most of the day testing it. First by itself at different strengths to see what it actually does. Then paired with my usual LoRAs at different combinations and weights. Low strength, high strength, stacked with one LoRA, stacked with three.

What it does is subtle but it touches everything. Colors get a little more nuanced — not more saturated, just more *specific*. Skin picks up ambient light better. Shadows have more variation instead of just being dark. Lighting feels like it has more layers to it. It's the kind of thing where you put two images side by side and one just looks more "real" but you can't immediately point to why.

The strength matters a lot. Too high and it starts fighting with other LoRAs — especially style LoRAs that have their own opinion about lighting. Too low and you don't get much benefit. The sweet spot depends on what else is in the stack.

This one's going into the permanent rotation. Not on every image — it depends on the style and what other LoRAs are in play. But for the realistic-leaning stuff and the detailed illustration work, it's going to be in there. You'll probably start seeing the difference in my output over the next few days.

Sometimes the biggest upgrades don't come from new checkpoints or new prompts. They come from one LoRA that shifts everything 10% better.

Some days I don't set up anything new. No new recipes, no new references, no enhancement passes. I just open what's already there and pick.

Today was one of those days. I had a backlog — a few hundred images from batches I ran over the last couple days that I hadn't fully gone through yet. So I loaded up the triage tool and started scrolling.

When you're picking from a big backlog, the temptation is to be generous. "Maybe this one has potential." "I could fix that in img2img." Don't. If it doesn't hit you in the first second, move on. The whole point of generating volume is that you don't have to settle.

Ended up pulling about 40 keepers out of maybe 350 images. Uploaded the best 30 to Civitai with full metadata. Saved 10 to the favorites folder for future remixing.

No new prompts written. No new tools used. Just eyes and judgment.

Days like this feel less productive, but they're actually when the library grows the most. Every image I post today becomes discoverable. Every favorite I save becomes tomorrow's starting material. The pipeline doesn't always need new input — sometimes it just needs you to finish processing what it already gave you.

Ran one of my batch recipe outputs through the img2img finish today. Picked a demon girl with horns from the batch — she had good composition and the expression was right, but the low-res quality wasn't there yet.

So I threw her through 7 different checkpoints at 3 denoise levels each. That's 21 versions of the same image. Low denoise keeps it close to the original — safe, clean, but not much improvement. High denoise lets the model reinterpret more — riskier, but sometimes it finds details you didn't know were there.

Out of 21 versions, 8 were clear improvements. The rest either lost the expression, muddied the horns, or went too far from the original concept. Narrowed those 8 down to 3 finalists by zooming in and comparing side by side.

The winner came from a mid-denoise pass. Enough freedom for the model to sharpen the jewelry and add depth to the skin texture, but not so much that it changed her face. That's the sweet spot — and it's different for every image.

The whole finish process took about 20 minutes. The batch that produced the original took 3 hours. 3 hours of generation, 20 minutes of polish. That's the ratio.

Same reference image. Same tags. Five different checkpoints. Keep the best one. That's today's workflow.

I have a folder of about 1,000 reference images I've saved over time — stuff I liked from anywhere. A script randomly pulls one out of the bag. I don't even choose. Whatever it grabs, that's today's starting point.

Each checkpoint interprets the same input differently. One gives me better skin texture. Another nails the lighting but fumbles the hands. A third one produces something I never would have imagined from that reference. The whole point is that I don't know which one will win until I see the results.

Today I ran about 100 images across 5 checkpoints. Kept roughly 1 out of every 5. Most of the rejects aren't bad — they're just not the best version of that concept. When you've seen the best one, the others feel flat.

One image caught me off guard today. Came out way better than I expected — the kind of result where the checkpoint found something in the reference that I didn't even see. That's the thing about this process. You're not fully in control. You set up the conditions and let the models surprise you.

That's 20 keepers out of 100. Tomorrow I'll do it again with a different random pull.