i-am-jacob:~$

~ / hardware

$ neofetch --workshop

One node. One modest GPU doing exactly the workloads it's good at. Heavy reasoning rents by the token; everything else is owned. Published at capability level — enough to learn from, not enough to draw a map from.

production $ cat ~/hardware.md --sanitize=class-level
jake@workshop — inventory
$ neofetch --workshop
os: ubuntu lts · bare metal
cpu: server-class xeon · 14C/28T
ram: 64GB DDR4
gpu: gtx 1650 super · 4GB (active)
storage: ~3TB ssd + ~22TB hdd
duty: 24/7 · services over vms
workloads:
forecast-engine running
archive-dashboard running
agent-infra running
watchdogs armed
The nodebare metal
CPUServer-class Xeon · 14 cores / 28 threads
MEMORY64GB DDR4
GPUGTX 1650 SUPER · 4GB — auxiliary ML duty
STORAGE~3TB SSD tier + ~22TB HDD archive tier
OSUbuntu LTS — no hypervisor, no VM layer
DUTY CYCLE24/7 — long-running services, not experiments
The GPU, honestly4gb is a feature
ROLEEmbeddings · TTS · small models · vision helpers
NOT FORFrontier-scale reasoning — that rents by the token
WHY SMALLThe 4GB ceiling forces right-sizing instead of hoarding
STATUSWorking daily — see the VRAM budget discipline in Hermes
Workload fleetalways on
FORECAST ENGINEFish Bite — scheduled refresh, health-checked
AGENT INFRAHermes — cron autonomy, memory system, watchdogs
DASHBOARDSSelf-hosted tools serving daily use
POLICYIf a service exists, it self-hosts
Why so leanconsolidated
HISTORYHypervisor + big-VRAM era documented in the essay
LESSONCapability integrity beats hardware throughput
NOWStable services on bare metal; heavy thinking delegated up-stack
FUTUREHardware follows the workload — not the other way around

// why class-level specs

CPU class, RAM, and GPU class are the parts that matter for understanding the architecture — and they're on every resume anyway. Exact drive models, hostnames, and port maps are the parts that help exactly one kind of visitor. Those stay private; the reasoning is in the privacy note.