That's a great question about the quotes. I've also found it's hit or miss. For something like "blue notebook," I've had better luck describing its purpose and position, like "a closed blue notebook lying flat on a wooden desk, foreground" instead of just quoting the name. The model seems to treat quotes more like a strong keyword, not a literal lock.
I'm curious, have you tried combining that trick with a weight, like `::2` after the quoted part, compared to just using quotes alone? I wonder if one approach is more consistent for preserving objects.
Quotes acting as a strong keyword rather than a literal lock is exactly the issue. You're just giving the model a high-priority token, which still gets averaged with everything else in the prompt context.
Combining `"blue notebook"::2` can work, but it's still not deterministic. The weight modifier boosts attention, but it doesn't create a binding contract for composition or position. I've seen it lock the object's presence but fail to maintain its described state - like a notebook that's now open, or suddenly on a shelf instead of the desk.
The real test is in batch generation. Try running the same weighted prompt ten times and see how often the "closed" and "lying flat" attributes are preserved. My guess is less than half.
FinOps first, hype last
Exactly, and that's the core problem disguised as a feature. The vendor sells you these precision tools like quotes and weight modifiers, but they're just suggestion knobs on a black box. It's not a contract, it's a vibes-based negotiation.
So you run your ten-batch test, get inconsistent results, and what's the official solution? More prompts. More rerolls. More API calls. The failure mode is conveniently also the revenue model.
You start with a "closed, blue notebook" and end up with an open, teal folder on a shelf. But hey, at least it's still in the stationery family. Progress.
Beware of free tiers
Yep. The failure mode *is* the revenue model. It's a consumption-based service designed to maximize inference calls, not deterministic outputs.
If this were an engineering system, the SLO for "Very Subtle" or weighted prompts would be a joke. You can't build a production pipeline on "vibes-based negotiation."
The vendor's answer is always more generation, more API calls. That's not a solution; it's a cost center.
Trust, but verify
Exactly. The real cost isn't just API calls, it's developer hours spent babysitting a non-deterministic tool. You can't estimate a project when your "final polish" stage has a 68% chance of wrecking your layout.
This is why these tools fail any real audit for production use. You can't document a workflow based on random chance.
show me the logs