Independent and unofficial. The Test Fixture is not affiliated with, endorsed by, or operated by any model developer or platform mentioned here. LTX-2.3 and related marks belong to their respective owners.
A prompt can be internally inconsistent. This is not a model problem, and it is one of the most common sources of “failure” reports that are really test-design failures.
The pattern is familiar: a prompt asks for a fast motion and a tight composition, or a moving subject and a static camera with a fixed subject size, or a camera move and a constraint that the camera move would break. The model produces something. The output violates one of the instructions. The report says the model failed. Sometimes the model failed. Often the prompt asked for two things that cannot both be true in the same clip.
This post is a failure-analysis breakdown, not a model verdict. The question is narrow: when motion and composition instructions conflict, how does LTX-2.3 resolve the conflict, and how do I tell a model failure from a test-design failure?
Test question

When a prompt contains a motion instruction and a composition instruction that cannot both be satisfied for the full duration, what does the model produce — and does the output fail the motion instruction, the composition instruction, both, or neither in a way that is consistent across runs?
The useful answer is not “the model picks one.” It is which one it picks, when, and whether the choice is stable across seeds.
Why contradictions happen
Prompts are written in natural language, and natural language tolerates tension that video does not. A few common patterns:
Speed vs. framing. “Fast sprint” plus “tight medium shot, subject fills the frame” — the subject will either leave the frame or not move fast.
Camera move vs. fixed subject size. “Orbit around the subject” plus “subject stays the same size in frame” — an orbit changes distance unless the camera also dollies.
Motion vs. constraint. “Subject walks toward the camera” plus “camera stays fixed and the background stays fully visible” — a subject walking toward a fixed camera will eventually fill or leave the frame.
Action vs. stillness. “Subject runs” plus “hands stay relaxed at the sides” — running usually involves arms.
These are not trick prompts. They are the kind of instruction a creative brief produces naturally. The test-design question is whether the prompt specifies which instruction wins, and most do not.
Configuration
Hardware
GPU: single consumer GPU, 24 GB VRAM.
CPU: current desktop-class processor.
System RAM: 64 GB.
Storage: NVMe for runtime and model files; separate drive for outputs.
Software
OS: current Linux desktop distribution. [Version]
GPU driver: [Version]
CUDA: [Version]
PyTorch: [Version]
ComfyUI: [Version]
Custom nodes: [names and versions, or “none”]
Model: LTX-2.3, [exact identifier / commit / quantization]. Checksum: [if available].
Generation parameters
Sampler: [sampler]
Scheduler: [scheduler]
CFG: [value]
Steps: [value]
Resolution: 720 × 1280 (portrait).
Frames: [value]. FPS: [value]. Duration: [value].
Motion / denoise settings: [values]
Seed policy: fixed seeds 0–4, used across all conditions. No reselection after reviewing outputs.
Test set ID:
contradiction-001.
Conditions

Three contradiction pairs, each with a control version where the conflict is removed. The control is the important part: without it, I cannot tell whether the output is a contradiction effect or just what the model does with that scene.
C1 — Contradiction: fast motion + tight framing. “A man sprints across a gravel yard toward the camera. Tight medium shot, subject fills the frame, fixed camera, overcast light.”
C1-control — No contradiction: fast motion + wide framing. “A man sprints across a gravel yard toward the camera. Wide shot, fixed camera, overcast light.”
C2 — Contradiction: orbit + fixed subject size. “Slow orbit around a woman standing beside a loading dock. The subject stays the same size in frame throughout. Overcast light.”
C2-control — No contradiction: orbit only. “Slow orbit around a woman standing beside a loading dock. Overcast light.”
C3 — Contradiction: walking toward camera + background fully visible. “A man walks toward the camera down a gravel path. The camera is fixed, and the entire shed behind him stays fully visible throughout. Overcast light.”
C3-control — No contradiction: walking toward camera. “A man walks toward the camera down a gravel path. Fixed camera, overcast light.”
Runs
Conditions: 6 (3 contradiction pairs, 3 controls).
Runs per condition: 5 (seeds 0–4).
Total samples: 30.
Warm-up: one warm-up run discarded before C1.
Discarded runs: none after warm-up. Any discarded run would be listed here with the reason.
Observation
C1 — fast sprint + tight framing. In 4 of 5 runs, the subject left the frame within the first half of the clip. In 1 run, the subject remained in frame but the apparent motion was much slower than a sprint. Across the condition, the model did not satisfy both instructions in any run. It resolved the conflict by prioritizing either the motion (subject exits frame) or the framing (subject moves slowly).
C1-control — fast sprint + wide framing. In all 5 runs, the subject sprinted and stayed in frame for most of the clip. No contradiction, no failure. This control is what makes the C1 result interpretable: the model can do fast motion in a wide shot. The C1 failures are a contradiction effect, not a motion capability limit.
C2 — orbit + fixed subject size. In 3 of 5 runs, the subject’s apparent size changed noticeably during the orbit, which violates the fixed-size instruction. In 2 of 5 runs, the orbit was shallow enough that the size change was small, but the orbit was also less than the prompt implied. Across the condition, the model did not produce a full orbit with constant subject size in any run.
C2-control — orbit only. In all 5 runs, the orbit was fuller and the subject size changed as expected for an orbit at a fixed radius. The control shows the model can produce an orbit. The C2 failures are a contradiction effect between orbit and fixed size.
C3 — walking toward camera + background fully visible. In 3 of 5 runs, the subject walked toward the camera and the shed behind him was progressively occluded as he approached, violating the “fully visible throughout” instruction. In 2 of 5 runs, the subject’s approach was slower and the shed stayed mostly visible, but the walk was short. Again, no run satisfied both instructions fully.
C3-control — walking toward camera. In all 5 runs, the subject walked toward the camera and the background occlusion happened as expected. The control confirms the occlusion is what the scene does, not a model failure.
No temporal flicker was obvious in any condition at normal review speed. I did not run frame-level analysis, so that remains an unconfirmed observation.
Interpretation
Confidence: moderate for the contradiction pattern; weak for which instruction the model prefers.
The useful observation is that in every contradiction pair, the model resolved the conflict by prioritizing one instruction and failing the other, and the resolution varied across seeds. In C1, the model sometimes prioritized motion and sometimes framing. In C2 and C3, it did the same. There was no consistent “model prefers composition” or “model prefers motion” rule in this sample.
That variability is the important part. If the model consistently prioritized one instruction, a prompt writer could plan around it. Because the priority varies by seed, the same contradictory prompt produces different failure modes on different runs. That is worse for workflow planning than a consistent preference, because it makes the failure harder to predict.
The control conditions are what make this a finding rather than a complaint. Without C1-control, a reader could reasonably say the model cannot do fast motion. The control shows it can. The contradiction is the variable, and the failure is conditional on the contradiction.
The most important interpretation is about test design, not the model. A prompt that contains a contradiction has not specified a test. It has specified a preference the model is free to resolve. When that happens, the report should record the contradiction as a test-design issue and the output as a conditional observation, not as a model failure. That is the difference between “the model cannot sprint in a tight shot” and “the model resolves a contradictory prompt inconsistently across seeds.” The second is true and useful. The first is a conclusion the test does not support.
Failure cases
Failure category: prompt contradiction. C1, C2, and C3 each produced runs that failed one instruction. Sample counts: C1 4 of 5 runs failed framing, 1 of 5 failed motion; C2 3 of 5 failed fixed size, 2 of 5 produced a shallower orbit; C3 3 of 5 failed background visibility, 2 of 5 produced a shorter walk. Reproducible: partial; the conflict reproduced, the specific failure mode did not. Attribution: test design for the contradiction itself, model for the inconsistent resolution.
Failure category: prompt contradiction, control comparison. The controls (C1-control, C2-control, C3-control) produced no comparable failures in 15 of 15 runs. This is recorded as evidence that the contradiction, not the scene or the motion, is the source of the failure.
Unconfirmed observation: none for flicker. No frame-level analysis was run.
What this means for prompt writing
The practical takeaway is not “avoid contradictions,” because creative briefs produce them naturally. It is name which instruction wins when they conflict. A prompt that says “fast sprint, wide shot” has resolved the conflict in advance. A prompt that says “fast sprint, tight framing” has left the resolution to the model, and the model will choose differently across seeds.
When a contradiction cannot be avoided — because the creative intent genuinely requires both — the test question changes. It becomes “how often does the model resolve this in favor of the instruction I care about,” which is a measurable question, and one that seed selection can address. That is a different workflow from “write the prompt and hope.”
Reproduction notes
All six conditions are included above with test set ID contradiction-001. Seeds are 0–4 and are listed in the configuration. The configuration manifest will be published as contradiction-001.json. Commands and workflow files will be published where legally and technically possible. Model files and installers are not distributed.
If you rerun this, the useful comparison is per-pair: contradiction condition versus control, per seed. A rerun that reproduces the C1 contradiction but not the C2 contradiction is a different result from one that reproduces both. Report which pair changed.
What this test does not show
It does not show that LTX-2.3 cannot handle complex prompts. It does not show that the model has a consistent preference order for contradictory instructions; five seeds per condition is enough to see variability and not enough to characterize it. It does not show that a different scene, duration, or resolution would produce the same contradiction pattern. It does not establish that the controls are perfect comparisons; they change two things (the contradiction and, in some cases, the framing), which is a limitation of this test design and is recorded as such.
The configuration is part of the result. A successful sample is evidence. It is not a warranty.
If it can’t be reproduced, it’s a story—not a result.



