Verified support

This page describes the 0.4.6 release and its retained observations. It separates implemented adapters, actual native execution, support-intake controls, managed-cache behavior, and unverified combinations. The complete checkpoint and context remain part of each numerical result; an installed CLI or passing control suite does not qualify every device or architecture.

Platform and runtime coverage

The guided runner admits one sequence. Automatic connections to Codex, Claude Code, OpenCode, or other external harnesses are not implemented in this application. Magnitude's feature list does not transfer to Aperture.

Exact managed-GGUF return use in 0.4.6

When a saved remote GGUF is already complete under the exact Aperture-managed acquisition key, the runner can bind it locally before model-host metadata or weight-transfer approval. The key preserves source, pinned revision, representation, component names, declared sizes, and expected hashes. The admitted entries must be regular files, and complete component hashing plus refreshed native fit still precede loading.

A separate Windows x64 passage used Qwen2.5-0.5B-Instruct Q4_K_M at revision 9217f5db79a29953eb74d5343926648285ec7e67, 491,400,032 bytes, SHA-256 74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db, 2,048-token context, and one sequence. The executable candidate resumed the original saved remote selection without network or download approval, repeated full integrity and native-fit preparation, generated FINAL CACHE PASS through CUDA with 25 observed GPU layers, exited 0, and left no candidate-owned worker. The path-free cache-reuse receipt records the bounded result.

This passage does not authorize a global cache search, import another application's files, trust a sidecar instead of hashing, or bypass runtime-installation and execution approval. Missing, changed, symbolic, differently identified, or incomplete entries return to the ordinary permissioned path. Safetensors are excluded from this shortcut.

Reduced support receipts retained from 0.4.5

aperture support --allow-scan --out aperture-support.json runs the ordinary hardware inventory and emits a separate reduced schema. It retains the CPU, memory, integrated and discrete graphics, NPU, storage-class, link, driver, runtime-presence, provider-status, and explicit unmeasured fields needed to investigate a fit or backend failure.

The receipt excludes host and user names, paths and mount labels, stable device and partition identifiers, GPU UUIDs, drive names and serials, network adapter names and addresses, model locations, prompts, generated text, credentials, and environment variables. Provider failures are collapsed to bounded classes, and labels shaped like PCI addresses, PnP identifiers, MAC addresses, or absolute paths are withheld. The command does not inspect a model, contact a model host, install a runtime, execute inference, stress hardware, or upload the result.

The release matrix runs the installed command on Windows, Ubuntu, and macOS under Node 22 and 24. It parses the output, checks schema and version identity, rejects forbidden identifier fields, and rejects the runner's host name, home directory, and temporary path in all string values. Those controls qualify the reduction mechanism. They do not establish anonymity. Hardware model names, exact capacities, drivers, current headroom, scan timing, and the receipt timestamp can still fingerprint a distinctive machine, so each file must be reviewed before sharing.

A recorded partial-offload case

The Qwen2.5-3B Q4_K_M checkpoint was 2,104,932,768 bytes. A Windows RTX 4060 trial used four GPU layers, retained 2,048-token context, and generated 42 while driver-reported free VRAM was 1,979,711,488 bytes. It exceeded available memory, not the card's nominal physical capacity.

That bounded trial establishes the reported split path. It does not establish an optimal layer count, a speed advantage, quality across tasks, or operation of a checkpoint larger than the card's physical memory.

Release-specific CUDA correction

The earlier NoBinaryFoundError remained reproducible with closed worker stdin. Compatible CUDA libraries existed in an installed Ollama directory but were absent from the worker search path. Release 0.4.1 adds bounded discovery and applies the selected directory only to child processes.

The integrated path produced 42 and retained CEDAR83 across two chat turns on the recorded RTX 3090 configuration. This is a real native check, not a throughput benchmark. It does not demonstrate every CUDA installation layout.

Current limitations that affect a first run

Native GGUF fit assessment precedes the complete weight-download prompt. The lightweight --answer-only result remains provisional. Release 0.4.4 records one checkpoint larger than the selected accelerator's physical memory completing through a CPU/GPU split, and 0.4.6 retains that numerical path unchanged. That result does not generalize to arbitrary architectures or checkpoints. Automatic fitting may select zero GPU layers; that remains CPU execution.

A legacy Qwen3.5 GGUF RoPE-layout mismatch is retained as a compatibility failure. Missing adapters, unknown topology, and incomplete runs remain visible. NPU execution, remote-range numerical streaming, general quantized-safetensors support, parallel guided sessions, and distributed execution are outside the demonstrated release.

Evidence and reproducibility

The historical verification record retains the earlier native observations, artifacts, failures, and the distinction between free and physical VRAM. The 0.4.6 return-use claim is additionally bound by the path-free cache-reuse receipt above and the versioned release notes. Full private machine/run files are not included in the public repository.

The release contains 169 source/control tests. Its Node 22/24 by Ubuntu/Windows/macOS workflow also checks clean package installation and the installed support-receipt command. Those checks are separate from native inference on a particular host. Public documentation has its own link, command-consistency, responsive-layout, browser-interaction, package-identity, and public-install checks.

Read the release notes, check the workflows, or report your model combination.

Windows scan resilience retained from 0.4.4

Windows hardware discovery runs core CPU, memory, graphics, NPU and external-link observations separately from extended storage and network inventory. The two bounded groups run concurrently. If the extended provider stalls, Aperture retains the completed core facts and marks the record partial; it reports the whole operating-system inventory unavailable only when both groups fail. One PnP enumeration supplies both NPU and external-link rows.

The release qualification returned complete inventory on the separate Windows host in 7.946 seconds after those providers had already been exercised. That is an observed warm-provider result, not a clean-machine latency guarantee. The preexisting numerical and permission paths are unchanged.

Additional public-package passage

The published 0.4.3 package was exercised from a new npm cache and an empty Aperture home on a separate Core Ultra 5 Windows x64 host. The fixed 0.5B Q4_K_M artifact completed pre-download native fit, provider-hash verification, CUDA generation with 25 observed GPU layers at 2,048 context, a two-turn context-retention check, and a clean exit. The selected GPU was idle before the run, while an unrelated workload on the host's other GPU remained in place. The public receipt excludes local paths, prompts, GPU UUIDs, and model weights.

The first detailed Windows operating-system inventory timed out even though NVIDIA discovery and the numerical path remained available. A subsequent full refresh succeeded. Release 0.4.4 isolated core hardware discovery from extended storage and network providers so a slow extended query cannot erase CPU, memory, graphics, NPU, and external-link observations.

Admission and regression checks retained from 0.4.3

The ordinary Windows runner returned 42 with the fixed 0.5B Q4_K_M checkpoint on CPU and RTX 4060 CUDA, preserving 2,048 context and reading back zero and 25 GPU layers respectively. A CPU chat retained a public badge code across two turns and exited cleanly. Integrity hashing preceded final native assessment. The pinned 14B target checked 50 placements and refused before acquisition under the observed constrained budgets. This remains a refusal, distinct from the later successful physical-capacity split.

Fresh installation retained from 0.4.3

A Windows x64 empty-home and empty-npm-cache run installed the pinned runtime, downloaded and hash-verified the original 491,400,032-byte 0.5B checkpoint, and generated 42 on CPU with 2,048 context and one sequence. No existing managed runtime or model was reused. Windows and Node were already installed. This is separate from GPU and beyond-physical-memory qualification.