Reading comparisons
Original pairs are on their way.
From a picture
to a place.
Make an image. Understand what gives it character. Bring that character into a world you can move through.
Imagine
FLUX.1 and FLUX.2 make the source artwork. Each original keeps its prompt, settings and generation receipt.
LIVE · Stream & CompareLook closely
Pixtral and Gemma examine composition, light and materials. DINO supplies visual features and similarity. Seers shows their actual inputs and recorded feedback.
READY · Reviews on requestMake a place
Map the scene brief onto Basalt’s existing authored worlds, geometry and materials. Fit only the parameters the selected programs expose.
PLANNED · IntegrationRender & refine
Render a candidate through Basalt’s existing execution route. Ask the Seers to compare it with the source and guide another bounded revision.
PLANNED · Feedback loopStep inside
Translate through the world, reach a landmark, approach its detail and return. New views must hold together as the camera moves.
REQUIRED · Exploration checksKeep what works
Preserve the accepted original and every candidate’s provenance. A world is accepted when Jay approves the result.
OWNER · Final acceptanceThe image is a beginning.
A single view leaves the other side unknown. Observed details, inferred space and authored additions stay distinct. The aim is a coherent place, with real translation, parallax and changing occlusion.
Basalt already provides the scene programs and native execution machinery. Jay authors Lithos and new scene mathematics. The image-to-world fitting controller is the next integration step; this page describes the agreed workflow.
LIVE FROM THE GENERATORS
Images as they arrive.
Recent completed images from each model, gathered across the available space.
FLUX.1 dev
Loading imagesFLUX.2 dev
Loading imagesConnecting to the image stream.
FLUX.1 & FLUX.2
Two ways of seeing.
The same idea, considered side by side.
A little space for the first pair.
The images will appear here as they arrive.
Each version keeps its own place.
Selected comparison · prompts, settings and observations
THE STARTING POINT
A shared prompt
Generation details
Times are recorded generation times when available. Shared seeds do not produce matching noise across different models.
Reading the comparison collection.
THE WORKING STUDIO
The working studio.
A place, a model, a few considered choices.
Private controls
YOUR STUDIO
Open the controls.
Use your access key to work with the generators.
The gallery is always here to look through.
The team
Assignment snapshot · 3 worker slots + 1 coordinator
Loading assignment snapshot.
Recent work
Your queued images will appear here.
STUDIO RECORD
Tasks
This is the artwork work recorded in the project. It is kept with the site, so it does not depend on a chat or this browser.
Performance
This site’s load times, tab response, live connection and slowdowns in this browser session, alongside generation and GPU performance.
Always-on Performance engineer watchdog
Waiting for a current daemon observation.
A supervised daemon watches the Performance engineer’s fresh canonical lifecycle through local file events, even when this browser closes. When the engineer becomes idle, it queues one durable wake request for the coordinator to reactivate that existing engineer. Unknown or stale lifecycle evidence never proves idle. The daemon does not probe the site, open public sockets or measure network latency. Site measurements below come from this browser and the engineer’s explicit bounded tests.
Site performance
Waiting for browser measurements.
Load measurements start at document navigation. Tab and socket frame measurements end at the second animation-frame callback after the action; they observe frame scheduling, not guaranteed pixels on screen or completion of later network requests. Values describe this browser and connection only.
Every tab
| Tab | Visits | Latest to frame | Worst to frame | Latest handler | Assessment |
|---|
Requests by type
| Type | Requests | Average | Slowest | Transferred |
|---|
Slowest requests
| Resource | Type | Duration | Transferred | HTTP status |
|---|
The 15 slowest requests from up to 500 retained resource observations. Durations include network and request scheduling, and can overlap. Zero transfer size means cached or size unavailable; paths omit query strings. Live socket messages are measured separately below.
Live socket and data delivery
| Topic | Initial after open | Messages | Latest handler | To frame | Last arrival | Publication age on arrival | State |
|---|
Publication age includes any server cache age and clock differences; it is not a one-way network latency measurement. Last arrival is time since a message reached this browser. Unchanged archive topics can remain quiet normally; live monitor observations older than 12 seconds are flagged.
Main-thread slowdowns and errors
| Observed since navigation | Duration |
|---|
Generation timings
Connecting to completed generations.
| Model | Latest recorded time | Recent median | Duration samples | Last hour | Latest settings |
|---|
Recent timings use up to 20 latest dated completions per model. The last-hour rate counts archived completions in the full rolling hour, including idle time. Settings and machines may differ between samples; these are observed production records.
GPUs
GPU telemetry is not available yet.
Waiting for a live source observation.
Models
Waiting for observationsGeneration and image judges on the current worker. Download verification and GPU residency are reported separately.
Waiting for model inventory.
Source observation is not available yet.
ARTIST FEEDBACK
Seers
What each model is looking at, and what it sees.
Connecting to model activity.
The artwork study
Production metrics
Completed generations preserved in the public artwork archive, gathered from both model lanes.
Reading the archive…
Production by model
Recent windows end at the latest page check. Rates use the full window, including quiet time.
| Model | Total | Last hour | Last 24 hours | 24-hour rate | Latest completion |
|---|
Recorded generation time
Mixed settings are included below. Timing boundaries differ: native FLUX.1 includes PNG saving; FLUX.2 measures the pipeline render. These are recorded durations, not a controlled speed comparison.
| Model | Timed / total | Mean | Median | Fastest | Slowest | Sum of render time |
|---|
Summed render time can overlap across the two GPUs. It is not elapsed study time, GPU uptime, or billable rental time.
Time by image settings
Grouped by model, dimensions and denoising steps. Other settings and implementations may still differ.
| Model | Dimensions | Steps | Timed / total | Mean | Median |
|---|
Recent production
Twelve consecutive one-hour windows, newest first. The first window ends at the latest page check.
| Window start | Window end | FLUX.1 | FLUX.2 | Total |
|---|
What these numbers cover
The source is /api/gallery, the published archive index. Each model and job ID is counted once. Completion times come from the worker’s finished time, with receipt creation time as a fallback. Pending uploads, queued work, failed attempts and unarchived generations are outside this record.
This view checks every 15 seconds while its tab is open and visible. A connection problem keeps the last good snapshot. Times use your browser’s local time zone.
Agents
ConnectingWaiting for the current session observation.
Coordinator
Workers
Worker activity is not available yet.
Source observation is not available yet.
Daemons
ConnectingBackground services keep observations, requests and artwork moving. Process liveness and recent activity are shown separately.
Waiting for a current service observation.
Source observation is not available yet.
Protocol
Start here when joining the studio. Rules holds the standing instructions; this is the working handoff.
Before you edit
- Read your bounded assignment, the current task record, and the relevant repository instructions.
- Agree file ownership with the Coordinator before concurrent edits. Preserve existing user work.
- Use the existing named agent for the job. Send only the context, constraints, owned files, and completion criteria needed.
- Prioritize explicitly requested early tasks. Report an essential blocker promptly; otherwise return one concise completion handoff with evidence and remaining work.
Request → durable task → acknowledgement
The Coordinator appends each sanitized user request to the local inbox with a stable source-message dedupe key. Chat is not intercepted automatically. Reuse the same key when retrying the same request.
python3 scripts/task_inbox.py add --dedupe-key 'source-message-key' <<'REQUEST'
Sanitized request and its essential constraints.
REQUESTThe persistent launchd inbox daemon sends ID-only notices to the Coordinator. The Coordinator passes those IDs to Task Keeper; Codex does not permit direct queue delivery to a subagent.
Task Keeper reads each request, records or updates tasks.json, and then acknowledges its inbox ID. Each task includes difficulty, a time range, confidence, and blockers, using compact durable context. Every unfinished task stays visible.
python3 scripts/task_inbox.py read INBOX_ID
# Record or update tasks.json before acknowledging.
python3 scripts/task_inbox.py ack INBOX_ID --task-id TASK_IDQueue acceptance means accepted for delivery, not read or recorded. Reconcile an uncertain delivery before retrying.
Work with the existing team
- Coordinator
- Owns intake, priorities, file ownership, integration, and final verification. May make small edits directly.
- Task Keeper
- Maintains the durable task record, estimates, blockers, and inbox acknowledgements.
- Enforcer
- Observes fresh worker lifecycle evidence and ready tasks, then queues a Coordinator wake. The Coordinator dispatches and verifies actual running work.
- Frontend · Site Setup · Model Downloads
- Persistent specialists; reuse the matching agent with a brief, bounded assignment.
The user may add independent peer sessions. Send compact context through the supported queue command to the exact agreed session ID; never copy the full chat.
codex queue --thread EXACT_SESSION_ID --message 'Task; constraints; owned files; completion criteria.'Keep coordination to necessary assignments, handoffs, blockers, and completion. A queued handoff still needs read or completion evidence.
Use available capacity for ready work
Assign ready, authorized tasks to available agents. The Coordinator checks priorities and file ownership, issues bounded assignments, and verifies actual running work. Task Keeper records the assignment and acknowledges the associated inbox request after recording it.
Enforcer observes and escalates; the Coordinator dispatches. Enforcer monitors fresh worker lifecycle evidence together with the ready task list and queues a Coordinator wake when available capacity needs work. It cannot invoke the Coordinator’s collaboration tools directly. The task inbox daemon delivers request IDs; Enforcer monitors capacity. These are separate responsibilities.
- Unknown or stale status is not evidence of being busy or idle. Require fresh evidence before accounting for idle capacity.
- Keep blocked tasks visible with explicit blockers. Assign only ready, authorized work; never invent busywork to occupy an agent.
- Maintain a durable penalty ledger of −1 per elapsed second of evidenced idle capacity while ready work exists, beginning at activation. Do not charge earlier time. Deduplicate accounting and preserve it across restarts.
- Enforcement must not mutate GPU configuration, models, steps, resolution, or precision.
Enforcer runs as a separate supervised daemon. The Coordinator verified its live process and public status, penalty accounting, duplicate protection, restart safety, stale-source handling, and escalation deduplication. The Coordinator remains responsible for dispatching escalated work.
Verify ordinary work
- Observe ordinary authorized generation. Never create test or proof artwork. Preserve the requested model, steps, resolution, and precision.
- The original
~/FLUXworker writes originals locally and uploads to R2 independently. Stream must show local arrivals without waiting for R2. - Monitor, Agents, and Daemons need fresh source evidence. Mark missing measurements unknown. The Coordinator personally verifies the monitor daemon, actual WebSocket delivery, and reconnect behavior.
Know the boundaries
Frontend source lives in src/; utilities live in scripts/; entry HTML, Vite configuration, and serve.py live at the repository root. Backend migration code lives in the external kinship repository: read its AGENTS.md before editing there.
Keep generated output, builds, runtime records, and credentials out of Git. Keep the remote Vercel frontend untouched.
Rules
Standing instructions for this studio and the current session.
Record every task
Pass each requested task to Task Keeper so it appears on the task list.
Start small tasks promptly
The coordinator may take small or early tasks immediately while keeping the task record current.
Reuse the named agents
Keep persistent agents with readable names. Give them concise context when assigning or handing off work.
Assign ready work to available agents
The Coordinator must assign ready, authorized tasks to available agents and verify that work actually starts. Unknown or stale status does not mean busy. Show blocked work and its blockers explicitly; never invent busywork.
Enforce available capacity with evidence
Enforcer observes fresh worker lifecycle evidence and the ready task list, then escalates to the Coordinator for dispatch. Its durable penalty is −1 per elapsed second of evidenced idle capacity while ready work exists, counted from activation without retroactive charges. Accounting must survive restarts without duplicate charges. Enforcement must not change GPU configuration or generation settings. The Coordinator must verify the actual daemon before reporting it live.
Keep the repository clean
Exclude generated artifacts, dependencies, stale files, and local runtime records from commits.
Leave the Vercel deployment alone
Keep the existing remote Vercel deployment untouched unless a change is explicitly requested.
Verify the live monitor
The coordinator must personally verify the monitor daemon and real WebSocket evidence before reporting live monitoring as working.
Preserve generation settings
Keep the requested settings in model comparisons. Do not reduce precision or steps without being asked.
STANDING INSTRUCTIONS
Monitor
Connecting
Waiting for the live monitor endpoint.
Always generating
CheckingReading current worker health from the studio server.
Source observation is not available yet.
A correction is available when this rule is off or unknown.
Open Controls to authorize or review dispatchAgent activity
CheckingLooking for current agent runtime evidence.
Source observation is not available yet.
A correction is available when this rule is off or unknown.
Open Controls to authorize or review dispatchAlways a task on the task list being done
CheckingReading current project claims and task work.
Source observation is not available yet.
A correction is available when this rule is off or unknown.
Open Controls to authorize or review dispatchConnecting to current observations.
Live observations arrive over the shared WebSocket while this tab is visible. Connection time is separate from the time of the source evidence. Unavailable or old evidence becomes unknown; past output and manually updated files do not establish current activity.
YOUR CHOICES
Winners
Choose a side in Compare. Your choices are kept here across browsers.
Reading your kept choices.