The form model needs values you've already supplied
FluidUse reads controls in a running Mac app, asks an on-device model which supplied value belongs in a field, and types the result into the application. The README's example builds options from a profile before scoring each actionable field. That makes the tool interesting for repetitive form entry: the model chooses among available actions and values rather than inventing a personal history for the form.
The library also contains decision-model runtimes, but the form workflow has a narrower contract. Its scope statement says the model doesn't read résumés, reason about dropdown options, or write free text. Uploads and essays stay with the person, and submission is disabled unless enabled. I'd consider it for assisted entry of known information, with someone inspecting the destination fields before anything consequential is submitted.
What happened when we ran it
We did not run FluidUse commit 8c5b746: our October 8, 2026 lab record marks Swift as an unsupported ecosystem, and the repository had no Dockerfile. The sandbox therefore produced no install, build, test, or dependency-audit result. That is a limit of our lab coverage, not evidence that FluidUse fails to compile or that its dependencies are safe.
The planned sandbox was an unprivileged environment with 3 CPUs, 8 GB of RAM, and no secrets. Those resources don't substitute for the Mac application session and Apple hardware this workflow targets. No model decision or typed field was observed in that sandbox. The recommendation here rests on the documented behavior, package manifest, and development activity, with the runtime claims still requiring verification on an appropriate Mac.
The package targets macOS and needs Accessibility permission
The current package manifest declares macOS 14 and uses the Swift 6 tools format. The README targets Apple silicon and shows a Swift package dependency rather than a Linux service deployment. Its demo requires Accessibility permission for the terminal that launches it. If your automation must run in an ordinary Debian worker, this form driver is the wrong platform choice.
Accessibility is also the interface contract with the target application. AccessibilityFormDriver snapshots fields, labels, and values from a running app, while WebFormDriver addresses an embedded WKWebView. In the driver source, browsers use key events and native apps first attempt an Accessibility value write. The driver checks whether typing applied the expected value and can report a failure. Those mechanisms deserve attention before adopting it across applications with different control behavior.
Local decisions still require downloaded model assets
The README shows model managers loading converted Core ML assets, often from pinned Hugging Face snapshots with checksum verification. That is a useful distribution practice because the package code and model files are separate artifacts. Local inference can keep the decision input on the machine, but an initial model download still needs a retrieval path. Prepare and retain the actual model snapshot alongside the application you intend to ship.
The decision-model support matrix distinguishes native Swift managers from a Python-assisted bridge. The bridge uses the released Core ML packages plus their tokenizer and decoding code, and prepares a locked environment through uv. Its documented path uses Python 3.12 and can fetch PyTorch during environment preparation. Choosing FluidUse doesn't mean every supported model has the same dependency or process requirements as the native form path.
Question fields can use an answer sheet without model judgment
The form workflow accepts a PredeterminedAnswer sheet for question-style fields the specialist model doesn't decide. In FormSchema.swift, a saved question fragment maps to an answer, and matching uses the field label. That supplies a concrete escape hatch for fields outside the trained short-caption task. You remain responsible for whether the saved answer applies to the actual question.
This boundary is useful when comparing FluidUse with a general desktop agent. A profile-to-field match is a bounded job. Reading a résumé, deciding what an application asks, attaching documents, and composing an essay require other logic or a person. Keeping submission disabled makes sense for that contract. Enabling it doesn't expand the model's understanding, so inspect the completed form before granting the workflow a final action.
Decision-model support varies by runtime and asset
The README now covers Laya typed questions, GLiNER classification, image decisions, short replies, and other model families. These are separate capabilities with distinct input limits and loading paths. Some documented managers require macOS 15, while the package's base platform is macOS 14. Confirm the chosen manager's requirements instead of assuming that importing the package makes every listed runtime available on your machine.
The support matrix is unusually candid about bridge behavior. Concurrent calls queue, and a timeout or cancellation closes the worker session, requiring a restart for later requests. It also says NanoJev's converted weights remain local pending clarification from the checkpoint owner. That is an availability boundary, not a promised download. A team considering that model needs its own permitted local conversion rather than an assumption that every matrix entry ships equivalent assets.
October changes show active development beyond v0.3.0
GitHub records a last push of October 10, 2026, with 306 stars and 8 open issues and PRs. The latest release is v0.3.0 from September 25, while subsequent activity includes merged Core ML runtimes and code-search work. Open proposals cover further model capabilities. The release date alone would understate the development activity, and an open proposal should not be treated as a released feature.
Choose Hammerspoon when explicit Lua scripts fit the Mac task, or Playwright when you control a browser-only form workflow. Cua is the broader computer-use alternative. FluidUse is worth a Mac trial when matching known profile values to live app controls is the requirement. Start with the exact destination app and keep submission disabled while you verify the field mapping.