File size: 4,473 Bytes
35e9bf4 0900234 35e9bf4 0900234 35e9bf4 0900234 35e9bf4 0900234 35e9bf4 0900234 35e9bf4 0900234 90bbcf7 3fc81c8 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 | # Public Preview
Agentic Space Factory turns Hugging Face model cards into private, testable Gradio Spaces using Hugging Face Jobs, Pi, Inference Providers, and per-user Storage Buckets.
## What it does
- Creates private Spaces from model cards.
- Runs the build inside an ephemeral Hugging Face Job.
- Uses Pi with an Inference Providers coding model.
- Injects the shared GitHub gist as Pi's operational instruction source.
- Stores state, events, raw/redacted traces, reports, generated files, validation results, and output artifacts in a private user Bucket.
- Attempts ZeroGPU first when requested, then optional fixed-GPU fallback.
- Supports manual hardware selection when automatic hardware assignment is unavailable.
- Runs a separate Space validation job with endpoint discovery, output-type checks, latency measurement, and generated artifact capture.
## Current UI
The dashboard is split into three working areas:
1. **Left column** — Run storage setup, model pre-scan, New Build form, Billing & compute readiness.
2. **Center tabs** — `Active Run` for build details and `Space Test` for validation details.
3. **Right column** — Run Explorer for navigation and Run Stats for aggregate history.
The Run Explorer is navigation-only. Build run details live in `Active Run`; validation run details live in `Space Test`.
## Recommended demo path
1. Sign in with Hugging Face OAuth.
2. Check or create the private run Bucket.
3. Review the default `Tongyi-MAI/Z-Image-Turbo` example or enter another model card, then run the model pre-scan.
4. Launch only after the scan returns `safe`/`caution` or after explicitly acknowledging a `risky` verdict.
5. Watch `Active Run`: progress timeline, latest events, latency when available, Space/Settings/Artifacts links, and trace documents.
6. If hardware is manual, open Space Settings and select the recommended hardware.
7. Open `Space Test`, prefill from the build, inspect available Gradio endpoints, click an endpoint to use it, and launch validation.
8. Confirm `full_inference_success`, measured latency, and saved output artifact.
## What it does not promise
The app does not guarantee that every model card can become a working Space. Some models require large or unusual hardware, Docker, multi-GPU execution, custom kernels, external services, accepted gated licenses, or manual fixes.
## Production-readiness note
The app is suitable for a controlled public-preview or internal production deployment when deployed with OAuth enabled, per-user Buckets, private generated Spaces, and clear billing expectations.
Before broad public launch, keep monitoring:
- Job cost and user quota expectations;
- token redaction in traces;
- failed build/validation rates;
- hardware assignment failure modes;
- latency and ZeroGPU duration recommendations.
## Additional preview checklist
- Pre-scan a few representative model cards before launching Jobs.
- Confirm that `risky` models require acknowledgement and `unsupported` models stay blocked.
## UI reliability checks
For preview deployments, verify that repeated refreshes do not duplicate click handlers: endpoint chips should update one API field once, run pagination should move one page per click, and run explorer selection/delete should remain independent.
- Repair is one bounded automated retry with visible artifacts and no unbounded loop.
## Recovery behavior
If a generated Space fails with HF build/runtime errors, especially empty logs or no-reason runtime errors, the Factory asks Pi to diagnose the blockage before any code patch is allowed. The system may wait for logs, re-upload the same workspace to force a rebuild, patch code once, request manual hardware, or stop with an auditable technical blocker.
### v120 note: Agent recovery visibility
The UI now exposes Pi diagnosis/recovery state through the Active Run **Agent recovery** card and links to recovery decision/blockage artifacts. This helps users understand when the Factory is waiting for HF logs, rebuilding the same code, patching, requesting hardware, or declaring a technical blocker.
## v122 stability note
The v122 line intentionally rolls back the experimental v121 client-side caching/polling optimizations after real UI testing exposed flicker and broken build/run behavior. The app keeps the v120 Agent recovery UI and the v118/v119 core blockage protocol, but returns to the proven polling and run-selection model for production stability.
|