Pumas Library v0.7.0

Pumas Library v0.7.0

Pumas Library 0.7 is primarily a release about making Pumas a stronger piece of embeddible model infrastructure.

The largest additions are:

• first-class headless operation
• model Intent API
• durable consumer model declarations
• stricter process ownership
• stronger concurrency and recovery
• backend-owned conversion workflows
• FP8 and NVFP4 conversion
• optional ONNX Runtime inference
• optional Torch image generation
• improved llama.cpp serving integration
• a lightweight common inference gateway
• clearer backend-owned runtime and serving state

The result is a Pumas that is less dependent on its desktop application, safer to embed into other software, and better able to act as the model-management layer shared by multiple applications.

Highlights

Headless Pumas

Pumas can now run independently of the Electron desktop application.

Applications can use:

• the pumas-library Rust crate for in-process integration
• Headless as a standalone local service or subprocess with RPC
• the desktop application with or without inference support via feature gates

Model Intent API

0.7.0 introduces the Model Intent API, allowing applications to describe the model they need rather than manually coordinate model discovery, downloading, and retention.

Applications can specify requirements such as:

• source;
• Hugging Face repository;
• revision;
• artifact;
• model format;
• quantization.

Pumas can reconcile the requirement against the local library, acquire the model when necessary, report acquisition status, and create a durable declaration representing the application's dependency on that model.

Branches and tags from upstream sources are resolved to immutable revisions before acquisition.

Declarations survive client disconnections and Pumas restarts. Multiple applications can independently declare requirements for the same model, and those declarations participate in safety checks that prevent required models from being accidentally removed.

Releasing a declaration releases the requirement — it does not delete the underlying model.

Stronger ownership, downloads, and recovery

The ownership model introduced in 0.6 has been tightened considerably.

Pumas now more clearly separates:

• owning library instances;
• local clients connected to an existing owner;
• read-only library access.

A second owning process cannot silently take control of an already-owned library root.

Downloads and other mutating operations now have stronger root-level exclusion, durable operation ownership, cancellation, shutdown coordination, and restart reconciliation.

Long-running work is owned by the backend rather than the client that initiated it, allowing operations to continue safely when an RPC or GUI client disconnects.

Hugging Face acquisition has also been hardened with improved destination validation, resumable acquisition handling, immutable revision resolution, and tighter coordination with Pumas metadata and recovery state.

Backend-managed model conversion

Model conversion is no longer fundamentally a GUI operation.

Applications can request conversions through the Pumas backend, which now owns:

• conversion environment setup;
• dependency installation;
• process execution;
• progress reporting;
• cancellation;
• operation recovery;
• output publication;
• collision protection.

Supported workflows include GGUF conversion through managed llama.cpp tooling as well as new Safetensors conversion targets:

• FP8
• NVFP4

Conversion setup itself is observable and recoverable, allowing clients to reconnect to existing work rather than blindly repeat an installation or conversion request after losing a response.

Expanded local inference

Inference remains optional — Pumas is primarily a model-management library infrastructure — but 0.7.0 substantially expands the inference integrations available to applications that want them.

ONNX Runtime embeddings

Pumas now supports in-process ONNX Runtime embedding inference.

Supported embedding models can be loaded, tokenized, executed, post-processed, and unloaded directly through the Pumas backend without requiring a Python sidecar.

ONNX support can also be omitted from Rust builds using feature configuration when an application only needs model management.

Torch image generation

The optional managed Torch integration now supports image-generation adapters including:

• Nunchaku Z-Image-Turbo;
• FLUX.2 Klein.

Compatible models advertise image-generation capabilities through the gateway and can be accessed through the same backend-owned runtime infrastructure used by other Pumas serving integrations.

Torch execution includes managed runtime dependencies, hardware telemetry, cancellation, device-level operation ownership, and unload protection while generation is active.

llama.cpp improvements

Managed llama.cpp operation received substantial reliability work, including:

• clearer model loading state;
• explicit start and stop control;
• router/library reconciliation;
• improved readiness checks;
• model-specific context configuration;
• stronger process and shutdown ownership;
• automatic discovery of compatible sibling mmproj vision projectors.

Vision-capable GGUF models can therefore resolve their associated projector without applications needing to manually coordinate the two files.

Richer model inspection

The package-facts system has expanded significantly and now uses contract version 3.

Model inspection can expose structured information covering areas such as:

• GGUF metadata;
• Transformers package structure;
• Diffusers components;
• image-generation family evidence;
• artifact and package size;
• processor and tokenizer components;
• quantization information;
• package inspection manifests;
• source and revision metadata.

Consumers that deserialize package-facts DTOs directly should update for the v3 contract.

Windows and cross-platform release support

Windows support has received substantial work around durable library operations, launcher roots, metadata publication, native packaging, and recovery behavior.

The 0.7.0 release pipeline now validates native desktop packages across Linux, macOS, and Windows and separately exercises the headless configuration.

The Electron desktop runtime has also been updated to Electron 43.7.0 along with dependency and packaging updates.

Distribution changes

Unlike 0.6.0, 0.7.0 no longer publishes the old host-language binding bundles as release artifacts.

The language-binding adapters remain in the source tree, but there is currently no supported prebuilt Python, C#, Kotlin, Swift, Ruby, Go, or other binding bundle in the release.

For embedding Pumas today:

• Rust applications can link pumas-library directly.
• Other applications can run the standalone pumas-rpc backend and communicate with it as a separate process.

The headless archives contain the complete RPC backend; a second Pumas core binary is not required.

Upgrade notes

Applications upgrading from earlier Pumas versions should be aware of several changes:

• Prefer explicit PumasApi / PumasLibraryInstance, PumasLocalClient, or PumasReadOnlyLibrary roles rather than older automatic owner/client selection.
• Package-facts consumers should update to contract version 3.
• Applications that need a model to remain available across restarts should consider using the new Model Intent declarations.
• Inference dependencies are optional for applications using Pumas purely for model management.
• Prebuilt host-language binding packages are not part of the 0.7.0 distribution.

Scope

Pumas 0.7.0 continues to focus on local model management and convenient local execution.

This release does not attempt to provide production inference scheduling, multi-tenant GPU arbitration, autoscaling, distributed inference, or cluster-wide model reconciliation.

Fleet discovery, remote-node operation, distributed acquisition, MCP integration, shared/community Hugging Face caches, and the broader Pumas cluster design remain future work.

---

Pumas Library 0.7.0 moves Pumas substantially closer to being infrastructure that other applications can depend on rather than only a model-management desktop application: headless operation, durable model requirements, backend-owned long-running work, stronger recovery, and independently selectable inference are now first-class parts of the architecture.