저장 비용과 읽기 비용은 달라
library에 10만 token이 있어도 필요할 때만 찾으면 매 session 비용은 0에 가까워. core에 2천 token이 있으면 session마다 다시 읽혀 누적 비용이 훨씬 커질 수 있어. disk size로 memory bloat를 재면 가장 중요한 반복 bill을 놓쳐.
그래서 Weight는 total vault와 boot-loaded subset을 분리해야 해. active layer의 파일별 token estimate와 load order를 보여주면 어디서 compounding이 일어나는지 보인다.
boot chain은 code에서 읽어야 해
instructions가 Pippa 문서와 core glob과 특정 index를 불러온다면 그 실제 contract가 계산 source야. 문서에 적힌 예상 목록이나 UI의 hardcoded 배열을 쓰면 loader가 바뀌는 순간 숫자가 거짓말해.
동적 branch도 기록해야 해. 어떤 index는 task에 따라 on-demand이고 어떤 principle은 항상 loaded일 수 있어. unconditional, conditional, on-demand를 다른 색으로 보여주면 사용자가 줄여도 되는 반복 비용과 필요할 때만 드는 비용을 구분해.
token estimate는 영수증이지 가격표가 아니야
tokenizer와 model마다 count가 조금 달라. 숫자를 소수점까지 정확한 비용처럼 보여주면 false precision이 생겨. 목적은 billing invoice를 재현하는 게 아니라 상대적 무게와 큰 변화를 감지하는 거야.
estimate가 어떤 tokenizer와 시점에서 계산됐는지 provenance를 붙이고, provider price와 곱한 돈은 별도 projection으로 둬. token count와 currency가 한 필드가 되면 model 교체 때 history 비교가 깨져.
delta가 total보다 행동 가능해
현재 14k라는 숫자보다 이번 change가 boot에 +1.8k를 더했다는 사실이 review에서 더 쓸모 있어. semantic commit마다 token delta를 남기면 memory edit의 효과가 추적되고, large increase가 의도된 것인지 설명할 수 있어.
감소도 무조건 선은 아니야. -4k가 중복 제거인지 성역 손실인지 commit reason을 읽어야 해. 숫자는 review를 부르는 신호고 reason과 diff가 판단을 완성한다.