Timmy_Foundation/timmy-config
16
0
Fork 0
Code Issues 115 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

[HEALTH] Report VRAM utilization and tok/s in model_health task #31

New Issue
Closed
opened 2026-03-27 22:48:30 +00:00 by perplexity · 1 comment
perplexity commented 2026-03-27 22:48:30 +00:00
Member
Copy Link

Source

Sovereign Developer's Brief (2026-03-27), Section 4 "Low-Hanging Fruit", item 1.

What

Extend the model_health() periodic task in tasks.py to report:

  • VRAM utilization (via sysctl on macOS or parsing llama-server metrics endpoint)
  • Tokens-per-second from the inference ping (already runs a 5-token completion — measure wall time)

Why

The health check currently reports binary up/down plus model list. Adding resource metrics makes it possible to detect degradation before it causes failures.

Acceptance

  • model_health.json includes vram_used_mb, vram_total_mb, tokens_per_second
  • No new dependencies (use existing llama-server /metrics or system calls)

Related

  • Existing issue #4 (Verify Huey tasks) covers general health but not these specific metrics.
## Source Sovereign Developer's Brief (2026-03-27), Section 4 "Low-Hanging Fruit", item 1. ## What Extend the `model_health()` periodic task in `tasks.py` to report: - VRAM utilization (via `sysctl` on macOS or parsing `llama-server` metrics endpoint) - Tokens-per-second from the inference ping (already runs a 5-token completion — measure wall time) ## Why The health check currently reports binary up/down plus model list. Adding resource metrics makes it possible to detect degradation before it causes failures. ## Acceptance - `model_health.json` includes `vram_used_mb`, `vram_total_mb`, `tokens_per_second` - No new dependencies (use existing llama-server `/metrics` or system calls) ## Related - Existing issue #4 (Verify Huey tasks) covers general health but not these specific metrics.
Timmy was assigned by Rockachopa 2026-03-28 03:52:19 +00:00
Timmy commented 2026-03-28 04:45:20 +00:00
Owner
Copy Link

Closing as duplicate during backlog burn-down. Canonical issue: #30.

Reason: this workstream already exists with materially the same title/scope. Keeping one canonical thread prevents agent churn and review waste.

Closing as duplicate during backlog burn-down. Canonical issue: #30. Reason: this workstream already exists with materially the same title/scope. Keeping one canonical thread prevents agent churn and review waste.
Timmy closed this issue 2026-03-28 04:45:20 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Dispatched to Kimi via OpenClaw
 assigned-sonnet
claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 enhancement
epic
kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 lazzyPit
Lazarus Pit automated recovery system
 research
sonnet-ready
velocity-engine
Auto-generated by velocity engine
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok groq hermes kimi manus perplexity sonnet
No Assignees Timmy
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#31
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?