Spaces:
Runtime error
Runtime error
Commit History
-
docs: revamp README + add AGENTS.md + refresh SKILLS.md
Unverified signature- README.md: opensource-style intro with badges, modes table, architecture diagram, project layout, tech stack, design, license + credits (Danielle Falco / FutuTek for the original All-In-One ComfyUI workflow). - AGENTS.md: new tool-agnostic agent rulebook — seven rules, project shape, locked-architecture-decisions table, commit / verification / testing rules, out-of-scope list. - SKILLS.md: cross-refs AGENTS.md from intro; push section now flags the master:main refspec (orphan-branch trap); repo-structure listing includes AGENTS.md.5a81fc9
-
revert: remove hf_oauth and LoginButton (OAuth was a misdiagnosis)
Unverified signatureThe original 'GPU quota exceeded' issue turned out to be a contextvar propagation bug in our worker thread, not a Pro-attribution issue. ZeroGPU reads identity from the X-IP-Token header that HF's reverse proxy sets from the standard huggingface.co cookie — completely independent of OAuth. Once 1e054fe propagated the Gradio request contextvar to the worker thread, attribution worked without OAuth. Removing the unused machinery: - README hf_oauth: true -> false - README hf_oauth_expiration_minutes (delete) - app.py: drop the gr.LoginButton + Account section in the drawer If we ever want per-user features (gr.OAuthProfile for logging the generating user, gr.OAuthToken for HF API calls on their behalf), re-enable both at that time.12ca777 -
feat(spaces+style): hf_oauth + gr.Progress + style 2-input + DWPose deps
Unverified signatureSpaces — Pro quota attribution: enable hf_oauth in README YAML and add a gr.LoginButton in the drawer (rendered only when OAUTH_CLIENT_ID is set, so local dev stays clean). Without OAuth the Space scheduler bucketed Pro users as signed-in/free (300s/day), causing "GPU quota exceeded" errors after a few generations while the profile dashboard still showed 0/25 used. Spaces — progress bar through @spaces.GPU subprocess: thread a gr.Progress instance from _make_handler -> _on_generate -> backend.submit -> _execute_workflow. The existing event-based ProgressEvent flow can't cross the @spaces.GPU subprocess boundary on Spaces (asyncio.run_coroutine_threadsafe targets the parent loop the subprocess never inherits). gr.Progress is the only progress channel ZeroGPU's IPC wraps. Inside _execute_workflow, install a ComfyUI PROGRESS_BAR_HOOK that calls progress(v/t, desc=...) and chains to the prior hook so the local event-driven status banner keeps working. Style mode — actually use the upload…27ffbbc
-
fix(spaces): drop 123 GB of unused preload (storage cap was 150 GB)
Unverified signatureHF evicted the workload at first deploy with "storage limit exceeded (150G)" — total preload was ~234 GB. Trimming to fit: - Drop ltx-2.3-22b-dev.safetensors and ltx-2.3-22b-distilled.safetensors from Lightricks/LTX-2.3 (84 GB combined). Neither is referenced by any workflow JSON we ship; the active transformer path uses the Kijai bf16 variant. - Drop the unsloth/LTX-2.3-GGUF entry entirely (39 GB). Only used by a hypothetical low-VRAM preset that we don't currently route. New total: ~111 GB. Marks future_improvements items 1 and 2 done.c53ac67 -
fix(spaces): trim preload_from_hub to 10 entries (HF cap) + future-work doc
Unverified signatureHF caps preload_from_hub at 10 entries; we had 16 → Configuration error. Dropped the 6 lightest entries (4 Dolly camera LoRAs at ~0.30 GB each, Motion-Track IC-LoRA at 0.30 GB, Pose-Control IC-LoRA at 0.61 GB). Those still lazy-download on first use of their respective modes. Captured deeper optimizations (drop unused 84 GB Lightricks-side transformer preload, drop GGUF, auto-sync README<->registry, etc.) in docs/future_improvements.md for follow-up rather than bundling here.099a5f3 -
feat(spaces): preload_from_hub bakes models into image at build time
Unverified signatureAdds the YAML directive to README so HF's build pipeline pre-downloads all 80 GB of models into the Docker image's HF cache before the app starts. Net effect: - Models persist across container restarts AND redeploys (cached image) - Available at app startup, not on first inference (UX win) - $0 extra cost (uses Pro's existing build infrastructure) - Compatible with sdk: gradio so ZeroGPU still works (Docker SDK would break ZeroGPU) - Code-only pushes don't re-run the preload step (cache layer keyed on README content) Tradeoff: first push triggers a one-time ~20-30 min build while HF's internal infra fetches 80 GB. Subsequent code pushes are fast.7bdb311
-
fix(spaces): pin sdk_version to 5.50.0
Unverified signature80f5694 -
fix(spaces): suggested_hardware uses zero-a10g (ZeroGPU)
Unverified signature01a78fa -
chore: rename Space title to 'LTX 2.3 Studio'
Unverified signaturec899ca5
-
docs: README with Spaces front matter and local quickstart
Unverified signature27161b7 -
Initial commit
Unverified signature55921ac