GO — Healthy across the board

• Last commit 2d ago
• 9 active contributors
• Distributed ownership (top contributor 38% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

LACT is a Linux GPU control and monitoring daemon + GUI written in Rust that allows real-time configuration of AMD, Nvidia, and Intel GPUs. It exposes features like power capping, custom fan curves, GPU/VRAM overclocking with voltage offset undervolting, thermal firmware tuning (RDNA3+), and historical performance monitoring—all managed by a systemd service independent of the graphical session. Monorepo with 6 workspace members: lact (core library), lact-daemon (systemd service), lact-cli (command-line interface), lact-gui (GTK GUI using Fluent i18n at 245KB), lact-client (TCP/Unix socket transport layer in connection/), and lact-schema (shared types). Daemon handles GPU control via amdgpu-sysfs crate and DRM headers (lact-daemon/include/drm/); GUI and CLI are thin clients over IPC.

Linux system administrators and enthusiast users (gamers, miners, workstation operators) who need granular GPU control without vendor proprietary tools. Also relevant for Rust developers building system daemons with GPU hardware abstraction and for packagers supporting multiple Linux distributions (Arch, Fedora, Flatpak).

Actively developed and production-ready. The project has a mature CI/CD setup (GitHub Actions for Rust/builds/Fedora packaging), distributed across a workspace with 6 crates (lact, lact-cli, lact-gui, lact-daemon, lact-client, lact-schema), includes localization (Fluent i18n), and is packaged in official Arch Linux repos. However, it's a single-maintainer project (ilya-zlobintsev), so risk depends on contributor velocity.

Moderate risk: single primary maintainer, hardware-specific code (GPU drivers via sysfs/DRM ioctl) is fragile across kernel versions, and amdgpu-sysfs dependency (v0.20.0) may lag kernel changes. No visible test suite in file list (typical for systems code). Large Rust dependency tree (futures, tokio, plotters-cairo) increases supply-chain exposure. Last activity appears recent based on Cargo.lock updates.

Active build/packaging work: GitHub workflows generate Fedora spec files, run Clippy lints, build Flatpak packages, and trigger COPR builds. Renovate bot manages dependency updates (renovate.json5). Localization infrastructure is in place (i18n-embed, Fluent translation files). Recent focus appears on packaging distribution and cross-platform GPU support expansion.

git clone https://github.com/ilya-zlobintsev/LACT.git
cd LACT
cargo build --release
# For daemon: cargo build -p lact-daemon --release
# For CLI: cargo build -p lact-cli --release
# For GUI: cargo build -p lact-gui --release

On Arch: pacman -S lact or yay -S lact-git for dev builds.

Daily commands: Daemon: sudo systemctl start lact-daemon (after install), or cargo run -p lact-daemon for dev. GUI: cargo run -p lact-gui (requires GTK dev libs). CLI: cargo run -p lact-cli -- <subcommand> (see lact-cli/src/subcommands.rs). Metrics exporter: docs/EXPORTER.md has OpenTelemetry setup.

• Cargo.toml — Workspace root manifest defining all member crates (lact, lact-cli, lact-gui, lact-client, lact-daemon, lact-schema) and shared dependencies; essential for understanding build structure and dependency versions.
• lact-daemon/Cargo.toml — Daemon crate manifest; core service that interacts with GPU drivers (AMD/Nvidia/Intel) and exposes monitoring/control APIs that other components depend on.
• lact-client/src/lib.rs — Client library entry point providing IPC abstractions (TCP/Unix sockets) for CLI and GUI to communicate with the daemon; fundamental RPC bridge.
• lact-daemon/src — Daemon source directory containing GPU driver interaction, sysfs parsing, and API server logic; the heaviest computation and system-level access layer.
• lact-cli/src/subcommands.rs — CLI subcommand definitions; shows the command interface and how the CLI invokes daemon operations via the client library.
• docs/CONFIG.md — Configuration schema documentation; required reading for understanding daemon configuration format and persisted settings handling.
• docs/API.md — API endpoint and message protocol documentation; essential for understanding daemon-client communication contracts.

Add a New GPU Monitoring Metric

1. Define the new metric structure in lact-schema with serde serialization (lact-schema/src/lib.rs)
2. Extend the daemon to read the metric from sysfs or driver interface (lact-daemon/src/gpu/mod.rs (or appropriate GPU type subdirectory))
3. Add API endpoint in daemon to expose the metric via RPC (lact-daemon/src/server.rs (or appropriate handler))
4. Add client method to lact-client to retrieve the metric (lact-client/src/lib.rs)
5. Add CLI subcommand to display the metric (lact-cli/src/subcommands.rs)

Add Support for a New GPU Vendor

1. Create vendor headers in lact-daemon/include/{vendor_name}/ if needed (lact-daemon/include/{vendor_name}/)
2. Create a new GPU type module in the daemon with driver detection logic (lact-daemon/src/gpu/{vendor_name}_gpu.rs)
3. Extend the daemon GPU enum to include the new vendor variant (lact-daemon/src/gpu/mod.rs)
4. Add vendor-specific control operations (clocks, fans, voltages) (lact-daemon/src/gpu/{vendor_name}_gpu.rs (control impl))
5. Register endpoints in daemon server and test via docs/API.md (lact-daemon/src/server.rs)

Add a New Daemon Configuration Option

1. Define the config field in the schema with serde defaults (lact-schema/src/config.rs or lact-daemon/src/config.rs)
2. Update the configuration file parser and validation logic (lact-daemon/src/config.rs (load/parse impl))
3. Document the option in the config file format (docs/CONFIG.md)
4. Use the configuration value in relevant daemon modules (lact-daemon/src/{module}.rs)

Add a New CLI Subcommand

1. Define the command structure and arguments (lact-cli/src/subcommands.rs)
2. Implement the handler that uses lact-client to call daemon APIs (lact-cli/src/subcommands.rs (handler function))
3. Register the subcommand in the CLI argument parser (lact-cli/src/lib.rs)
4. Test by calling the corresponding daemon API endpoint (docs/API.md (verify endpoint exists))

• Rust — Memory safety, zero-cost abstractions, and direct system-level access without garbage collection—essential for GPU control where resource safety is critical.
• Tokio async runtime — Non-blocking I/O for the daemon to handle multiple concurrent client connections and sysfs reads efficiently.
• Serde JSON — Standard serialization for RPC message encoding and configuration file parsing across CLI/GUI/daemon.
• amdgpu-sysfs crate — Pre-built AMD GPU sysfs interface; reduces boilerplate for reading GPU telemetry on AMD hardware.
• C FFI (via include/ headers) — Direct GPU driver kernel interface access (DRM, NVAPI, Intel) that Rust libraries don't fully abstract.
• Flatpak + systemd service — Sandboxed distribution model with daemon running as system service to provide privileged GPU access.

• Client-server architecture (daemon + CLI/GUI clients)

  • Why: Centralizes privileged GPU access in a single daemon service, avoiding repeated privilege escalation and simplifying permission model.
  • Consequence: Adds IPC overhead (~1–5ms latency), requires daemon to be running; simpler security model but more complex debugging.

• In-memory caching with configurable TTL instead of persistent database

  • Why: Simplifies deployment (no external DB dependency), reduces latency for frequent queries.
  • Consequence: Metrics are lost on daemon restart; no long-term historical replay; suitable only for live monitoring, not forensics.

• Support AMD, Nvidia, and Intel with vendor-specific code paths

  • Why: Each GPU vendor exposes different driver interfaces (sysfs vs. NVAPI vs. i915); no unified abstraction exists.
  • Consequence: Higher maintenance burden (3 code paths to test), but enables comprehensive support across Linux GPU landscape.

• XML/DRM headers bundled in repo instead of system package

  • Why: Ensures consistent ABI definitions across distributions without relying on system headers that may differ.
  • Consequence: Larger repo size and manual header updates needed when GPU drivers evolve.

systemd/root required: daemon must run as root (GPU ioctl + sysfs writes); dev testing needs sudo or mock harness. Kernel version sensitivity: amdgpu-sysfs v0.20.0 may not match user's kernel; check Hardware Support wiki. DRM ioctl incompatibility: Intel/Nvidia paths use custom DRM headers (lact-daemon/include/drm/)—kernel updates may break. GTK runtime deps: GUI build needs GTK4 + libadwaita dev libs (not in Cargo.toml, external). i18n rebuild: Fluent translation changes require i18n-embed rebuild. No feature flags visible for AMD-only vs generic builds—monolithic binary approach. Unix socket path likely hardcoded (check lact-client/src/connection/unix.rs) for IPC.

• Device File I/O (sysfs) — LACT reads/writes /sys/devices/pci*//amdgpu files to control GPU state; understanding sysfs is essential for GPU hardware interfacing
• ioctl (I/O Control) System Calls — DRM ioctl calls (in lact-daemon/include/drm/) are used for Intel/Nvidia GPU control; critical for understanding LACT's low-level hardware access beyond sysfs
• Unix Domain Sockets & TCP RPC — lact-client/src/connection/ implements both TCP and Unix socket transport for daemon-to-GUI/CLI communication; core to LACT's IPC architecture
• systemd Service Management — LACT runs as a systemd service independent of graphical sessions; understanding systemd unit files and service lifecycle is necessary for deployment and troubleshooting
• Fluent Localization (i18n) — LACT uses Fluent translation files (245KB in repo) with i18n-embed; understanding Fluent syntax is needed for UI text, translations, and i18n workflow
• GTK4 Async UI (Rust Bindings) — lact-gui is built on GTK4 with async Rust; requires understanding of GTK's signal-based event loop and Rust async/await integration
• GPU Power States & DVFS (Dynamic Voltage/Frequency Scaling) — LACT controls power caps, frequency/voltage offsets, and firmware thermal states; understanding GPU power states and DVFS is critical for overclocking/undervolting features

• GPUOpen-Tools/radeon_gpu_analyzer — AMD-focused GPU analysis tool; complements LACT for profiling and kernel ISA inspection
• ZeratulTheWise/FanControl — Windows GPU fan control; similar domain (thermals + fan curves) but Windows-only; shows UI/UX patterns
• boringboredom/Fan-Control — Rust-based fan curve automation; related approach to LACT's thermal management via system service
• opencomputeproject/HIP — AMD HIP compute stack; LACT users often run HIP workloads and need GPU control alongside compute
• torvalds/linux — Kernel source; DRM and amdgpu driver headers/behavior are authoritative source for LACT's hardware abstraction

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for lact-client TCP and Unix socket connections

The lact-client crate has connection implementations for both TCP (lact-client/src/connection/tcp.rs) and Unix sockets (lact-client/src/connection/unix.rs), but there are no visible integration tests validating these connection paths work correctly. This is critical for a daemon-client architecture where connection reliability is essential for GPU monitoring and control.

• [ ] Create lact-client/tests/integration_tests.rs with test fixtures for both TCP and Unix socket scenarios
• [ ] Add tests validating connection establishment, message serialization/deserialization, and error handling
• [ ] Test timeout and reconnection behavior as documented in lact-client/src/connection/
• [ ] Ensure tests work in CI by mocking daemon responses or using a test daemon instance

Add CLI argument validation and error handling tests for lact-cli subcommands

The lact-cli/src/subcommands.rs file appears to handle multiple GPU control operations, but there's no dedicated test suite visible for validating user input, error messages, and edge cases (e.g., invalid GPU index, permission errors). This prevents regressions in the CLI user experience.

• [ ] Create lact-cli/tests/cli_subcommands_test.rs to test each subcommand in subcommands.rs
• [ ] Add tests for invalid arguments (negative indices, non-existent GPUs, out-of-range values)
• [ ] Test permission denied scenarios and ensure helpful error messages are displayed
• [ ] Validate output formatting for info, overclock, and fan control subcommands

Document GPU-specific quirks and limitations in docs/CONFIG.md with actual sysfs paths

The repo supports AMD, Nvidia, and Intel GPUs with different capabilities (as evidenced by include/amdgpu, include/nvidia, include/drm directories), but docs/CONFIG.md doesn't document which features apply to which GPU types or the specific sysfs/ioctl paths used. This creates friction for users debugging issues or contributors extending GPU support.

• [ ] Extend docs/CONFIG.md with a 'GPU Support Matrix' section listing features per vendor (AMD/Nvidia/Intel)
• [ ] Document the sysfs paths used for AMD (via amdgpu_sysfs crate), the ioctl interfaces for Nvidia (kernel-open headers), and DRM paths for Intel (drm_mode.h, xe_drm.h)
• [ ] Add troubleshooting section explaining common issues per GPU type (e.g., missing kernel modules, permission issues)
• [ ] Reference the actual header files in lact-daemon/include/ that implement each feature

• Add unit tests for lact-cli/src/subcommands.rs: Currently no visible test module; add tests for parsing/executing CLI commands (e.g., power profile switching, status output). Start in lact-cli/src/lib.rs with #[cfg(test)] block.
• Expand docs/API.md for IPC protocol: Document the exact JSON/binary messages exchanged between lact-client and daemon (TCP format, Unix socket framing). Check lact-client/src/macros.rs for RPC boilerplate.
• Add GPU throttling reason explanations to GUI: lact-gui currently displays throttling status but not root cause (temp/power/thermal throttle); add tooltip or detail pane parsing throttle flags from amdgpu-sysfs hwmon files.

LACT appears to be a well-structured Rust project with generally good security practices. No critical vulnerabilities were identified in the codebase structure or dependencies. Primary concerns include: (1) Invalid Rust edition specification that may cause build issues, (2) inclusion of unverified third-party C headers without documented verification, and (3) the use of shell scripts in the build process. The project would benefit from stricter dependency version pinning for security-critical components, a formal security policy, and verification of included third-party headers. The aggressive optimization settings and symbol stripping should be reviewed for the project's security auditing requirements.

• Medium · Outdated Edition Specification — Cargo.toml - workspace.package.edition. The Cargo.toml workspace specifies edition = '2024', which is not a valid Rust edition. Valid editions are 2015, 2018, and 2021. This may cause build failures or unexpected behavior. Fix: Update to a valid Rust edition such as '2021' or '2018'
• Medium · Dependency Version Pinning Not Strict — Cargo.toml - workspace.dependencies. Multiple dependencies use loose version constraints (e.g., 'serde = 1.0', 'anyhow = 1.0.102'). While not critical, this allows minor/patch updates that could introduce breaking changes or vulnerabilities. Fix: Use more restrictive version constraints with '~' for minor updates only, or pin exact versions for critical security dependencies
• Low · Symbol Stripping in Release Build — Cargo.toml - profile.release. The release profile strips symbols (strip = 'symbols'), which can complicate debugging and security auditing of crash dumps or vulnerabilities in production. Fix: Consider keeping symbols for security auditing purposes, or use a separate debug symbols package for production deployments
• Low · Aggressive LTO Configuration — Cargo.toml - profile.release. The release profile enables full LTO (lto = true) with single codegen unit, which can increase compilation time and may mask certain code issues during optimization. Fix: Consider using 'lto = "thin"' for a balance between optimization and compile time, and monitor for any optimization-related issues
• Low · Included Third-party Headers Without Verification — lact-daemon/include/nvidia, lact-daemon/include/intel, lact-daemon/include/drm. The project includes raw C headers for NVIDIA, Intel, and DRM kernel interfaces (lact-daemon/include/). These are external dependencies that may not be regularly audited. Fix: Verify the integrity and source of included headers. Consider using official package managers or fetching these at build time with integrity checks
• Low · Bash Script in Build Process — lact-daemon/fetch_vulkan_schema.sh. The file 'lact-daemon/fetch_vulkan_schema.sh' indicates shell scripts are used during the build process, which could be a vector for injection attacks if not carefully validated. Fix: Review the script for input validation and security concerns. Consider migrating to Rust build scripts for better security control
• Low · Missing Security Policy — Repository root. No SECURITY.md file is present in the repository for responsible disclosure of vulnerabilities. Fix: Create a SECURITY.md file with guidelines for reporting vulnerabilities securely

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ilya-zlobintsev/LACT shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ilya-zlobintsev/LACT repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ilya-zlobintsev/LACT.

What it runs against: a local clone of ilya-zlobintsev/LACT — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ilya-zlobintsev/LACT | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ilya-zlobintsev/LACT. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ilya-zlobintsev/LACT.git
#   cd LACT
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ilya-zlobintsev/LACT and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ilya-zlobintsev/LACT(\\.git)?\\b" \\
  && ok "origin remote is ilya-zlobintsev/LACT" \\
  || miss "origin remote is not ilya-zlobintsev/LACT (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "lact-daemon/Cargo.toml" \\
  && ok "lact-daemon/Cargo.toml" \\
  || miss "missing critical file: lact-daemon/Cargo.toml"
test -f "lact-client/src/lib.rs" \\
  && ok "lact-client/src/lib.rs" \\
  || miss "missing critical file: lact-client/src/lib.rs"
test -f "lact-daemon/src" \\
  && ok "lact-daemon/src" \\
  || miss "missing critical file: lact-daemon/src"
test -f "lact-cli/src/subcommands.rs" \\
  && ok "lact-cli/src/subcommands.rs" \\
  || miss "missing critical file: lact-cli/src/subcommands.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ilya-zlobintsev/LACT"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.