⏱️ Built a small Space for Visual Chronometer / Pulse of Motion.
Upload a video and estimate its Physical FPS: the frame rate implied by visual motion, independent of metadata. Useful to inspect “chronometric hallucination” in generated videos: clips that look smooth, but move with the wrong physical time scale.
A few weeks ago, @victor opened the door: coding agents can now ship Hugging Face Spaces autonomously.
I pulled on that thread.
As someone who builds and ships Gradio demos regularly, I didn’t just want to reproduce the loop. I wanted to see what happens when that loop is plugged into the whole Hugging Face stack.
The interesting part is not only that an agent can ship a Space.
It’s what happens when Space generation becomes a first-class Hugging Face workflow.
A live community radio for AI-generated songs, powered by tracks created with ACE-Step.
You can tune in, discover community-made songs in many languages, vote on what sounds good, and mark your real favorites as Bangers.
The more people listen, vote, and create, the better the station gets.
Under the hood, it connects a few Hugging Face pieces together:
Spaces for the live app, HF buckets for community tracks, OAuth for signed-in listeners, server-side streaming with ffmpeg, hourly playlist refreshes, moderation, jingles, and community feedback loops.
It’s not just a playlist.
It’s a shared taste experiment: new songs get a shot every hour, and the community helps decide what deserves another spin.
Come listen. Find weird gems. Support the Bangers. Shape the radio.
Great technical guide by Nico Martin on the Hugging Face blog, showing how to use Transformers.js inside a Chrome extension and run ONNX models from the Hub locally with WebGPU inside a Manifest V3 extension.
The interesting part: this is not just a chatbot in a side panel.
The article walks through the architecture behind a browser agent that can read open tabs, query webpages, search history, and highlight elements directly on the page — with models downloaded from the Hugging Face Hub, cached under the extension origin, and executed locally instead of being called through a remote API for every prompt.
A strong blueprint for building local-first web copilots, reading assistants, and AI-powered browsing workflows.
The paper asks a simple but important question: what if the chatbot interface is not just a neutral wrapper around AI models, but part of the problem?
A chatbot can make a system feel more capable, more certain, and more “human” than it really is. That matters, because interfaces shape how we trust, use, and delegate to AI systems.
When everything becomes: ask → answer we can lose sight of the actual workflow: - parameters - alternatives - uncertainty - intermediate steps - failure modes - human control
For creative AI especially — image, video, editing, animation — I’m not sure “chat” should always be the default interface.
Sometimes we need a conversation. But often we need a canvas, a timeline, sliders, masks, previews, comparisons, and visible pipelines.
This is also why I find many open ML demos interesting: Spaces, Gradio apps, visual tools, small focused interfaces.
They often explore another direction — not just better assistants, but better tools. 🤗