chore: track crush.json in dotfiles repo #33

Open
opened 2026-05-29 08:30:22 +00:00 by mathias · 1 comment
Owner

Problem

~/.config/crush/crush.json on flamingo is the canonical Crush-LiteLLM wiring config (11 models, key sk-local-123, endpoint http://koala:4000/v1/). It is not tracked in any repo.

If flamingo is rebuilt, this config is lost. It must also be manually updated whenever litellm_config.yaml model names change — and there is no reminder or automation to do so.

Logged as tech debt in DECISIONS.md (2026-05-28) but never given an issue.

Action

  1. Add crush.json to a dotfiles repo (create one if it doesn't exist, or use an existing private repo on Gitea).
  2. Parameterise any secrets or host-specific values (endpoint URL, API key) so the file is safe to commit — e.g. replace sk-local-123 with a placeholder and source the real key from ~/.llmkeys.
  3. Add a note to the LiteLLM model-rename checklist: when a model alias changes in litellm_config.yaml, update crush.json too.

Acceptance criteria

  • crush.json committed to a tracked repo
  • Secrets/host-specific values parameterised or excluded
  • Model-rename checklist updated

Related

  • DECISIONS.md 2026-05-28 — three active harnesses
  • brain: homelab/facts/crush-litellm-wiring-2026-05
## Problem `~/.config/crush/crush.json` on flamingo is the canonical Crush-LiteLLM wiring config (11 models, key `sk-local-123`, endpoint `http://koala:4000/v1/`). It is not tracked in any repo. If flamingo is rebuilt, this config is lost. It must also be manually updated whenever `litellm_config.yaml` model names change — and there is no reminder or automation to do so. Logged as tech debt in DECISIONS.md (2026-05-28) but never given an issue. ## Action 1. Add `crush.json` to a dotfiles repo (create one if it doesn't exist, or use an existing private repo on Gitea). 2. Parameterise any secrets or host-specific values (endpoint URL, API key) so the file is safe to commit — e.g. replace `sk-local-123` with a placeholder and source the real key from `~/.llmkeys`. 3. Add a note to the LiteLLM model-rename checklist: when a model alias changes in `litellm_config.yaml`, update `crush.json` too. ## Acceptance criteria - [ ] `crush.json` committed to a tracked repo - [ ] Secrets/host-specific values parameterised or excluded - [ ] Model-rename checklist updated ## Related - DECISIONS.md 2026-05-28 — three active harnesses - brain: `homelab/facts/crush-litellm-wiring-2026-05`
Author
Owner

Update (2026-05-29): After reviewing mathias/dma-cli, this issue may be closeable.

dma code init (internal/wizard/crush.go) is the canonical tool for writing crush.json. It fetches the live model list from llm-api.d-ma.be/v1/models at runtime and merges a "dma" provider block into ~/.config/crush/crush.json, preserving all other fields. The model list is not hardcoded — it's whatever the proxy returns at init time.

This means:

  • crush.json does not need dotfiles tracking for the model list — dma code init always regenerates from live state
  • The API key is stored separately via dma auth login, not as plaintext in a repo
  • The only real risk is if dma-cli itself is missing on a rebuilt machine — covered by scripts/install.sh

Suggested resolution: Close this issue and instead ensure dma-cli install is documented in any flamingo bootstrap runbook. The model-rename checklist note in the original issue description is also irrelevant — dma code init syncs from live models automatically.

Brain updated: wiki/entities/dma-cli.md, wiki/entities/crush.md, wiki/sources/dma-cli-repo-session-review-2026-05-29.md

**Update (2026-05-29):** After reviewing `mathias/dma-cli`, this issue may be closeable. `dma code init` (`internal/wizard/crush.go`) is the canonical tool for writing crush.json. It fetches the live model list from `llm-api.d-ma.be/v1/models` at runtime and merges a `"dma"` provider block into `~/.config/crush/crush.json`, preserving all other fields. The model list is not hardcoded — it's whatever the proxy returns at init time. This means: - crush.json does **not** need dotfiles tracking for the model list — `dma code init` always regenerates from live state - The API key is stored separately via `dma auth login`, not as plaintext in a repo - The only real risk is if `dma-cli` itself is missing on a rebuilt machine — covered by `scripts/install.sh` **Suggested resolution:** Close this issue and instead ensure `dma-cli` install is documented in any flamingo bootstrap runbook. The model-rename checklist note in the original issue description is also irrelevant — `dma code init` syncs from live models automatically. Brain updated: `wiki/entities/dma-cli.md`, `wiki/entities/crush.md`, `wiki/sources/dma-cli-repo-session-review-2026-05-29.md`
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/hyperguild#33