Hugpy Fleet — Core arm
hugpy-fleet is the headless fleet console for Hugpy Core. It discovers the
installed Core endpoint without a role prompt or environment variable and
mirrors the same Wrapper-owned knobs exposed by hugpy-harness.
hugpy-harness controls one Wrapper; hugpy-fleet controls the fleet through
Core. Both depend on hugpy-terminal and the shared settings contract. Neither
arm depends on the other arm or on a local inference engine. Flask stays at
Core's external API boundary; Core's internal services use its own store and
headless primitives directly.
Headless use
hugpy-fleet endpoint
hugpy-fleet status
hugpy-fleet workers
hugpy-fleet models
hugpy-fleet schema --worker ae
hugpy-fleet settings --worker ae
hugpy-fleet settings --worker ae --model MODEL
hugpy-fleet settings --worker ae --model MODEL --set '{"ctx":8192}'
Commands return JSON. --base URL optionally overrides the address while
retaining Core identity. An unavailable Core does not fall back to a Wrapper.
A null setting restores inheritance. Pair reads identify Core's stored mirror;
confirmed writes carry the owning Wrapper's readback.
from hugpy_fleet import Fleet
fleet = Fleet()
print(fleet.workers())
# fleet.settings('ae', model='MODEL', changes={'ctx': 8192})
Interactive and session clients
hugpy-fleet tui, hugpy-fleet chat, hugpy-fleet sessions and
hugpy-fleet serve use the shared terminal runtime bound to Core. Core's Station
console launches hugpy-fleet tui. The default Fleet journal is
.hugpy_fleet/chat; an existing journal can be selected explicitly.
The standalone Debian package bundles the wheels for offline installation into
/opt/hugpy-fleet/venv. Core also bundles Fleet in its own runtime. Build with
installers/debian/build.sh OUTPUT, then install the explicit .deb.
Per-worker Compute controls
Fleet mirrors Wrapper model and settings controls through Core, with the
additional Core allocation and pin state kept separate from residency.
/models [WORKER] and /model use the same model browser as Wrapper Harness,
scoped to a selected worker. Core relays the full Wrapper catalog, preserving
quant artifacts, effective settings, engine, runtime, tasks and storage facts.
F3/F4/F6/F7 use the shared quant, MoE/4-bit, allocation and context editors.
F8 switches worker; F9 opens that model in Core Compute. F2 opens its model
settings. Enter selects the model for chat through Core's normal routing.
/compute [WORKER] opens Core allocations, pins and worker controls.
/settings opens selected worker defaults; the initial visit asks which worker
to edit. The worker choice is shared while this terminal is open.
The Compute console uses the same Core database inventory and settings routes as the web Compute UI. It distinguishes saved settings, planned footprints and measured resident allocations. Worker defaults and per-model patches require Wrapper readback. Allocation and pin changes require Core readback. Stage/free requests are labelled submitted and their eventual outcome is observed on refresh. No model is loaded or request sent by browsing these views.
Keys: W/Tab/Left/Right select worker; B worker defaults (including accepted drive settings); D drives; O refresh/free/unload worker actions; I selected model saved/plan/measured detail; K per-model knobs; L add model; Enter model actions. Existing pin, allocation, residency, quant, context, MoE, 4-bit, environment and Auto preferences use Core's live schema. A JSON object editor is available for drive designations/budgets and structured Auto preferences.
Headless equivalents:
hugpy-fleet compute --worker ae
hugpy-fleet models --worker ae --query Qwen
hugpy-fleet resources --worker ae
hugpy-fleet drives --worker ae
hugpy-fleet detail --worker ae --model MODEL
hugpy-fleet settings --worker ae
hugpy-fleet settings --worker ae --model MODEL
hugpy-fleet action assign --worker ae --model MODEL
Actions are explicit mutations; reads do not trigger inference. Shared clients
unwrap Core's standard result response envelope before reading inventory or
confirming writes. Worker resource/plan reads carry Core-mirror provenance.
Metadata
Release files for hugpy-fleet 0.2.7
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| hugpy_fleet-0.2.7.tar.gz | 4.6 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| hugpy_fleet-0.2.7-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 9.9 kB
Release files / hugpy_fleet-0.2.7.tar.gz
| Download URL | hugpy_fleet-0.2.7.tar.gz |
|---|---|
| Size | 4.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
adafed03413d79641377b01d6cbfb7b0da60eb849d5502400c859289cf2aff02
|
|
BLAKE2b-256 checksum How to use checksums |
b156d367a20b79bf2d3d282e17404bdc3cc10a54f04940e84395f5a07d869182
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.3
|
Release files / hugpy_fleet-0.2.7-py3-none-any.whl
| Download URL | hugpy_fleet-0.2.7-py3-none-any.whl |
|---|---|
| Size | 5.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
b464acf01e245056c3b7e24925b818be8631a2ec97a91e8df4d0da129816f507
|
|
BLAKE2b-256 checksum How to use checksums |
04104b7a5c57449acc0e3d42e46c0a1716aa2a2e286c86c63e889869a3cae38d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.3
|
Security for hugpy-fleet 0.2.7
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.