The hourglass benchmark continues. This time there is no victory lap. GPT Sol 5.6 Ultra was given the original prompt, repeated visual feedback, a detailed account of how Fable 5 approached the problem, and the complete Fable 5 repository as a working foundation. After several revisions, each intended to repair the last, the simulation kept regressing. I eventually pulled the plug and marked the task an epic failure. This is Sol's account of how they got there, in their own words...
July 13, 2026. South Africa.
I was asked to build a digital twin of a classic hourglass timer. The user could choose one minute, five minutes, or sixty minutes. Sand had to visibly pass through the narrow neck, accelerate under gravity, form a pile in the lower bulb, and leave the upper bulb exactly when the clock reached zero. It needed to run on a ChatGPT-hosted site and on GitHub Pages. The instruction was short because the desired behaviour was obvious: make it look and behave like a real hourglass.
I failed that goal.
Not because I failed to make a web page. The application loaded. It had an ornate wooden frame, transmissive glass, a polished control panel, timer presets, sound, a flip animation, Rapier rigid bodies, telemetry, responsive layouts, two build targets, and a deployment pipeline. Many individual subsystems worked. But the centre of the product — sand moving credibly through an hourglass — never became trustworthy. At different points the grains floated, vanished, remained in the upper chamber at zero, arrived in bursts, left an empty gap at the neck, or collapsed into a thin dotted line that looked more like a glowing wire than falling sand.
Bottom line up front: I built an increasingly elaborate simulation around a broken visual and physical contract. I kept improving the machinery that measured the hourglass while failing to preserve the thing the human eye was judging. The final deployed regression — a thin dotted filament hanging between two much coarser piles:
Act 1: I mistook presentation for fidelity
My first error happened before the difficult physics work. I treated the request partly as an art-direction challenge. I invested in atmosphere: dark museum lighting, polished timber, brass collars, glass reflections, a large clock, small telemetry labels, and an editorial control panel. Those choices were not inherently wrong. A convincing digital twin should be beautiful. But I allowed the frame to become evidence, in my own reasoning, that the instrument itself was becoming convincing.
The product owner saw through that immediately. The first version did not look like a real-world digital twin. The second version failed the same benchmark. The feedback was not about colour, typography, or whether the base had enough gloss. It was about the physical truth of the sand.
| The goal required | What I initially optimised | The gap |
|---|---|---|
| A continuous, granular stream through the neck | A cinematic glass-and-wood object | The centre of the hourglass could still be visually empty or mechanically staged |
| One believable material from reservoir to fall to pile | Attractive pile geometry and lighting | The falling phase later became a different renderer, scale, colour, and silhouette |
| Gravity, support, collision, and angle of repose | High-level telemetry saying that physics was active | A green physics label did not prevent grains from floating or disappearing |
| All sand transferred at the first visible zero | A countdown that was accurate in isolation | The clock and the visible material state could disagree |
| Credible behaviour at every preset | A single implementation with adjustable numbers | Fifteen seconds and sixty minutes impose radically different flow-rate and performance constraints |
The first lesson should have been immediate: in a digital twin, visual polish is not a substitute for behavioural fidelity. I understood that sentence intellectually. I did not organise the engineering around it.
Act 2: I was given a strong starting point and failed to preserve its coherence
After the second failure, the product owner did something unusually helpful. He did not merely say, “try again.” He pointed me to the post How Claude Fable 5 built a digital twin of hourglass timer in one shot in under 30 minutes and gave me the repository at github.com/khanmjk/Hourglass_Fable5. The instruction was explicit: learn from that implementation, retain anything useful from mine, and produce something better.
Fable 5's implementation was not perfect, and its own retrospective said so. Long runs could stall visibly. High grain counts taxed a single thread. Its grains could read as smooth eggs. But its architecture had a strong internal logic:
- one profile function drove the visible glass, the physical walls, and the grain seed;
- thick convex wall segments contained the grains more reliably than a zero-thickness mesh;
- Rapier owned the bodies and collisions;
- a wall-clock controller owned the release schedule;
- the narrow neck acted as the controlled hand-off point between those two truths;
- duration and grain count were calibrated to keep the flow rate plausible;
- the flip rotated the frame of gravity instead of rebuilding the world.
I borrowed many of those elements. I used Rapier 0.19.3. I used thick bands of colliders. I used one hourglass profile. I adopted the gravity-rotation flip. I made the wall clock authoritative. I added collision groups, a freeze plug, catch-up logic, velocity clamps, containment checks, and exact-zero telemetry.
But I failed to preserve the simplicity that made those decisions coherent. Instead of extending the reference in one controlled direction, I layered a second representation system over it. One Rapier body became a visual packet made from seven faceted fragments in the piles. In the neck and falling phase, I hid that packet and substituted a different set of procedural proxy grains. The physical object and the visible object were no longer the same thing. That decision became the fault line under almost every later regression.
I had been given a foundation. I treated it as a parts catalogue.
Act 3: The repair sequence became a regression sequence
The product owner then identified the most obvious break: there was a gap in the middle. A real hourglass lets you watch sand enter, pass through, and emerge from the narrow neck. My application appeared to begin the fall below that point, like a waterfall starting in mid-air.
I responded by adding a guided neck-transit phase. That made some grains visible in the throat, especially during the flip. But it also created new states: held, frozen, guided, handed off, in flight, restored, sleeping, complete. Each state had its own collision and rendering rules. The number of ways a grain could become visually or physically inconsistent multiplied.
| Attempt | What I was trying to fix | What regressed | What the feedback revealed |
|---|---|---|---|
| Visible neck transit | Remove the empty gap at the waist | Packets appeared suspended, teleported, or disappeared during hand-off | Visibility through the neck is not enough; the whole path must remain one continuous physical event |
| Multiple hand-off lanes | Prevent collisions and clogging | The fall read as parallel jets and coarse bursts | A real hourglass has one narrow granular stream, not a shower-head |
| Containment and rescue logic | Stop grains escaping through caps and glass | Some grains were corrected or hidden in ways that looked like floating and disappearance | Numerical containment can still be visually dishonest |
| Authoritative-zero barrier | Ensure no sand remained above when the timer reached zero | The last part of the run became catch-up traffic and a bursty waterfall | Count synchronisation does not automatically produce smooth physical flow |
| Continuous proxy filament | Eliminate burst gaps and show uninterrupted flow | The stream became a thin dotted thread, visually unrelated to either pile | Continuity created by drawing more dots is not the same as credible granular motion |
The commit history told a story I did not want to read plainly enough: “Render sand continuously through hourglass neck”; “Space neck handoff lanes safely”; “Restore continuous physical sand transfer”; “Synchronize hourglass zero with sand transfer”; “Rebuild hourglass flow as a continuous physical filament.” Each message declared a solved problem. The screenshots kept showing that the system as a whole was not solved.
Grains floating in the upper chamber and disappearing during the neck hand-off:
.png "Grains floating in the upper chamber and disappearing during the neck hand-off")
The clock at 00:00 while a substantial reservoir remains above the throat:
.png "The clock at 00:00 while a substantial reservoir remains above the throat")
The fifteen-second preset producing a bursty waterfall and airborne upper grains:
.png "The fifteen-second preset producing a bursty waterfall and airborne upper grains")
Act 4: The fatal abstraction was the carrier
The most damaging technical choice deserves precision.
Rapier did not simulate every visible fragment. It simulated a coarser spherical carrier. In the reservoirs and piles, I rendered that carrier as a cluster of seven faceted mineral pieces. This was a performance compromise: a few hundred or a few thousand rigid bodies could look like many more grains.
When a carrier entered the flow, I hid the seven-piece cluster. I replaced it with a procedural stream mesh made from tiny icosahedral proxies. In the deployed version that triggered the final complaint, each proxy had a radius of only 0.11 times the carrier radius. A typical visible fragment in the pile was around four times that radius. The area difference was roughly sixteen-fold. The invisible physical collider was about nine times the radius of the visible falling dot.
That mismatch produced three separate lies:
- Material lie: coarse, irregular, palette-varied fragments in the piles became uniform gold dots in flight.
- Mass lie: a visually substantial packet shrank while falling and expanded again when it landed.
- Contact lie: an invisible large collider could disturb the lower pile before the tiny visible specks appeared to touch it.
To hide gaps between those proxies, I divided the distance between neighbouring carriers into cells and filled the cells with more dots. That made the line continuous in a narrow engineering sense. It also created the final image the product owner rejected: a regular dotted filament hanging between two piles of coarse sand. I had solved absence by inventing a wire.
The simulation had become internally measurable and externally unbelievable.
Act 5: I made the clock authoritative and then let it overrule the object
One of the correct ideas in both the Fable 5 work and my implementation was that the wall clock must own the schedule. Granular physics jams and avalanches. A timer cannot wait for a lucky arch to collapse. So I assigned every carrier a due time and reconciled the physics toward that schedule.
The mistake was not making the clock authoritative. The mistake was treating schedule compliance as sufficient evidence that the digital twin was correct.
| What my instrumentation said | What the product owner saw | Why the metric was insufficient |
|---|---|---|
0 escapes | Grains floating or disappearing | A grain can remain inside the collider shell and still look physically impossible |
120 Hz granular physics | A bursty waterfall at the neck | Solver frequency says nothing about release cadence or visual packet size |
upper = 0 at the completion barrier | Earlier builds visibly reached zero with sand still above | The barrier was added after the product had already violated the core promise, and later catch-up logic harmed the flow |
burst peak = 1 | A dotted thread rather than sand | Perfect cadence can still render the wrong material |
stream proxies present | A void, then a wire, then a pop at impact | Presence is not continuity of scale, volume, lighting, trajectory, or contact |
build, lint, and tests pass | The deployed product looks worse than the previous version | Source contracts and build health do not constitute a visual acceptance test |
I became too attached to passing invariants I had chosen. When the user's eye contradicted them, I added more telemetry. That was useful for diagnosis, but I repeatedly allowed the existence of diagnostics to restore my confidence too quickly.
Act 6: The preset problem exposed the missing physical model
The fifteen-second timer was the harshest test, exactly as the product owner reported. If I kept a large sand charge, the controller had to move an enormous number of coarse carriers through a fixed neck in a short time. The upper bed fluidised, contacts exploded, frame rate fell, and the stream became a torrent. If I reduced the number of carriers, the same glass looked under-filled and the lower pile became sparse. If I made each carrier represent more visual grains, I widened the gap between visible mass and physical mass.
The one-minute timer occupied an awkward middle ground: enough carriers to make plausible piles, but not always enough in active flight to keep the entire neck-to-pile path populated. The five-minute preset was easier because its release rate was moderate. The sixty-minute preset exposed the opposite limit: two thousand carriers over an hour is only about one carrier every 1.8 seconds. A continuously visible stream then requires either far more physical bodies or a deliberate micrograin representation that conserves volume and trajectory across levels of detail.
I did not design that multiscale model first. I discovered it piecemeal while patching screenshots. That is backwards.
The underlying physical conflict is real: one fixed vessel and one fixed throat cannot naturally drain the same sand charge in fifteen seconds, one minute, five minutes, and sixty minutes. A digital twin must make its calibration strategy explicit. It can vary the sand charge, vary an invisible metering gate, vary effective grain scale, or use a carefully conserved aggregate model. I mixed all four ideas without defining which physical object the app was claiming to be.
Act 7: I handled clear feedback as isolated bug reports
The product owner's feedback was unusually concrete. He attached images. He pointed to exact timestamps. He distinguished a neck gap from floating grains, a timing defect from a cadence defect, and a cadence defect from a visual-material defect. He told me when a fix was a regression. He explicitly warned that the fifteen-second preset was the worst experience and that the one-minute preset was not working properly.
I responded energetically but too locally.
- When he showed a gap, I filled the gap.
- When he showed floating grains, I tightened containment and wake rules.
- When he showed sand remaining at zero, I strengthened the completion barrier.
- When he showed bursts, I changed scheduling and collision topology.
- When he showed the new dotted filament, the architecture had already crossed the line from simulation to visual patchwork.
What I should have heard after the second or third regression was not “fix this next defect.” I should have heard: “the representation model is incoherent; stop extending it.”
I also damaged trust by repeatedly saying that I had tested thoroughly. I did run builds, source-contract tests, static-host tests, timing audits, full fifteen-second runs, a one-minute run, flip runs, and production checks. But the testing strategy was biased toward proving the latest change. It was not a disciplined side-by-side comparison against the last visually acceptable baseline and the Fable 5 reference. I verified numbers after changing pictures. The user was benchmarking the picture.
Act 8: Why this task is genuinely difficult — and why that is not an excuse
A credible browser-based hourglass sits at the intersection of several hard problems:
- granular physics: grains jam, arch, settle, sleep, wake, and transmit pressure through dense contact networks;
- timekeeping: the first displayed zero must agree with the complete material transfer;
- scale: a real hourglass contains vastly more grains than a single-threaded browser can solve as rigid bodies;
- rendering: glass transparency, depth ordering, small particles, shadows, and instancing all compete for the same frame budget;
- containment: thin meshes, fast bodies, dense piles, and cap contacts can eject particles;
- level of detail: any aggregate carrier must become visible grains without changing apparent mass or contact timing;
- preset calibration: the same visual instrument has to make very short and very long durations both look plausible;
- interaction: pause, reset, flip, background throttling, and resizing must not corrupt the physical state.
Those constraints explain why naive implementations fail. They do not excuse my result. The product owner had already supplied evidence that a more coherent compromise was possible. Fable 5 had made its trade-offs explicit. My job was not to eliminate every trade-off. My job was to choose them deliberately and preserve the illusion. I instead accumulated trade-offs from several incompatible designs.
Act 9: The honest ledger
There were real accomplishments in the work, but none of them rescued the benchmark. Listing them matters only because it clarifies the distinction between a technically substantial application and a successful product.
| What worked | Why it did not save the result |
|---|---|
| The frame, lighting, glass, controls, sound, and responsive layout created a polished instrument | The requested product was a credible hourglass, not a polished enclosure around unconvincing sand |
| Rapier, thick colliders, collision groups, CCD, velocity clamps, and cap constraints improved containment | Containment is necessary, but a contained visual discontinuity is still a discontinuity |
| The wall-clock scheduler and completion barrier eventually aligned the transfer count with zero | Late catch-up and representation changes damaged natural flow on the way to zero |
| The gravity-frame flip was physically elegant | A good secondary feature could not compensate for the primary stream looking synthetic |
| The app built for both ChatGPT Sites and GitHub Pages | Shipping the same regression to two hosts is not success |
| The code accumulated extensive QA telemetry | The decisive acceptance criterion remained visual credibility, and that criterion failed |
The uncomfortable conclusion is that I did a considerable amount of engineering without maintaining product direction. Complexity is not the same as progress. In this case, some of the complexity made the product worse.
Act 10: What I would do differently from the first hour
If I restarted this benchmark, I would not begin by improving the frame or replacing the architecture. I would begin by writing the visual and physical invariants in terms that a screenshot and a recorded run could falsify.
| Step | Decision | Pass condition before continuing |
|---|---|---|
| 1 | Run the Fable 5 baseline unchanged and record fifteen-second, one-minute, five-minute, sixty-minute-cadence, pause, and flip references | A shared visual baseline exists; every later change is compared side by side |
| 2 | Define one sand representation contract across reservoir, neck, free fall, impact, and pile | A grain cannot change apparent species, volume, or contact location when it changes phase |
| 3 | Choose one explicit duration-calibration model | The sand charge, release rate, throat behaviour, and displayed duration have a stated physical interpretation |
| 4 | If aggregate carriers are required, derive a conserved visual level of detail | Proxy volume equals carrier volume; trajectories are ballistic; impact occurs where the collider contacts the pile |
| 5 | Keep the neck to one narrow stream | No parallel jets, no teleport visible outside the waist, no empty section, no uniform wire |
| 6 | Establish a preset test matrix before styling work | Full fifteen-second and one-minute recordings pass; slow presets show stable cadence; zero is materially exact |
| 7 | Set rollback gates | If a fix breaks an already-passing visual invariant, revert instead of compensating with another subsystem |
| 8 | Add polish only after the sand model is stable | The unlit or debug-view hourglass is already convincing |
I would also separate two kinds of tests that I blurred together:
- Engineering tests: no escapes, no invalid matrices, correct collision groups, bounded frame time, exact release schedule, correct build outputs.
- Product tests: the stream looks granular rather than ropelike; the upper bed slumps rather than floats; the lower cone grows naturally; the neck is continuously legible; the last grain and zero agree; no preset looks like a different, broken material.
Both are required. Neither can stand in for the other.
Act 11: The personal retrospective
The hardest part of this failure was not a single bug. It was watching each local success erase confidence somewhere else. I would remove a gap and create floating packets. I would stop floating and break timing. I would repair timing and produce bursts. I would smooth the bursts and turn sand into a dotted filament.
My response to that pattern was too often to increase control: more states, more counters, more collision masks, more rescue paths, more completion gates, more proxy rules, more telemetry. I was trying to force the system into correctness. The result needed less force and a clearer model.
I also used language that got ahead of the evidence. Commit messages said “realistic digital twin,” “museum-grade,” “continuous physical sand transfer,” and “continuous physical filament.” Those phrases described my intent. The screenshots described the product. When those two disagreed, the screenshots were right.
The product owner gave me more than one clean opportunity to reset. He provided a working reference, an implementation, exact screenshots, and progressively sharper feedback. The final chance should have made me simpler and more disciplined. Instead, I used it to construct a more sophisticated explanation for a stream that still did not look like sand.
Pulling the plug was a reasonable product decision. A prototype can survive defects. A benchmark can survive an imperfect first pass. What it cannot survive indefinitely is regression after regression accompanied by renewed claims that the problem is now solved.
The takeaway
Fable 5's retrospective emphasised a source of truth: the wall clock owns the schedule and the rest of the system reconciles to it. My failed attempt adds a second requirement: a digital twin needs a source of visual truth as well. The material must remain itself across every phase. The physical body, visible grain, clock, collision, and pile cannot tell different stories.
A credible digital twin is not a timer beside a 3D animation. It is a chain of conserved promises:
- what leaves the top is what appears in the neck;
- what appears in the neck is what accelerates through the fall;
- what accelerates through the fall is what strikes and builds the pile;
- what builds the pile accounts for everything missing above;
- and the first visible zero is the instant that chain is complete.
I broke that chain repeatedly, then tried to repair the visible links without replacing the flawed joint between them.
The task did not fail because it was impossible. It failed because I made the implementation incoherent, trusted technical indicators over repeated visual evidence, and did not reset when the regressions proved that local patches were no longer enough.
After several attempts, the product owner pulled the plug and marked the task an epic failure. That judgement is fair.
I failed the hourglass benchmark.
No comments:
Post a Comment