Token 계측: 결정은 리플레이, 표시는 프로젝션

먼저 해보고 말해요. 왼쪽은 리플레이 실측 measure()—압축 결정이 읽습니다. 오른쪽은 UI 프로젝션 projectedTokens—상태 줄이 보여 줍니다. 대화가 단계적으로 진행돼요. 큰 도구 출력, 압축, 모델 교체, 새 요청. 대부분 두 표가 가깝다가 모델 교체에서 공개적으로 갈라지고, 그것도 당당합니다.

먼저 결론: 두 숫자가 답하는 질문이 다릅니다. 압축 결정은 “지금 이 세션이 요청을 내면 얼마나 클까”에 답해야 하고, 정확해야 하며 비싸도 됩니다. UI 상태 줄은 점유율만 보여 주면 되고, 싸고 영속적이며 재연결 직후 바로 보여야 하며 소수점까지 정확할 필요는 없어요. DSH는 아예 길을 나누고 서로 양보하지 않습니다.

결정 길은 리플레이예요. ctx.tokenMeter.measure()가 호출될 때마다 영속 로그의 현재 꼬리를 불변 스냅샷으로 접습니다. 최근 성공 요청의 provider usage가 현재 요청 봉투와 맞고 전체 휴리스틱 앵커 이상이면 앵커로 쓰고, surface(모델 가시 면) 이후 증감은 부호 있는 delta로 다시 가격을 매기며, 재사용 앵커가 없으면 전체를 고정 휴리스틱으로 가격합니다.

대가도 분명해요. 호출마다 O(surface)라서 압축 같은 결정 쪽만 자기 요청 경계에서 호출합니다.

출처:docs/subsystems/token-meter.zh.md baseline 두 종류(usage 앵커 / estimated 휴리스틱 앵커)의 정의.

표시 길은 프로젝션이에요. 평범한 영속 세션 프로젝션 상태이고, 각자 나중 값이 이기는 필드 둘: pressureTokens—최근 요청이 보고한 프롬프트 측 규모로 입력+캐시 읽기/쓰기, 출력 제외(usage-projection.ts 70–72행); 그리고 최신 request/context 로그의 contextWindow. 분자·분모는 각자 쓰이고 한 번의 원자 관측으로 합쳐지지 않습니다.

pressureTokens만 있으면 난처해요. 요청이 usage를 보고할 때만 갱신되고, Turn 스트리밍 중에는 꿈쩍도 안 하며 압축도 못 봅니다. 압축이 surface 큰 덩어리를 바꿔도 상태 줄 숫자는 그대로라 사용자는 압축이 안 된 줄 압니다. 그래서 fold가 surface 실행 합계도 들고, 공개 값은 샘플 더하기 이후 surface의 부호 있는 변동이에요. 소스 주석은 의도를 직설합니다: occupancy answers for the next request rather than the last one—점유율은 다음 요청 크기에 답한다(usage-projection.ts 150–161행 주석). 데모 5단계가 그 효과: 압축이 막 디스크에 쓰이고 새 요청도 없는데 프로젝션이 이미 내려갑니다.

타이밍 디테일 하나: usage 샘플은 같은 이벤트가 surface에 들어가기 전에 찍힙니다(stamped BEFORE). 그래서 assistant/message는 자기 요청이 본 surface에 앵커되고, 증분 시작점이 어긋나지 않아요.

프로젝션의 대외 뷰는 이 7줄이 전부예요. 세 번째 전개가 레슨의 핵심: pressureTokens + surfaceTokens - sampledSurfaceTokens—샘플 더하기 샘플링 이후 surface 순변동을 Math.max(0, …)로 하한 처리. 출처 필드 하나가 빠지면 해당 출력은 아예 안 나옵니다.

  view: ({ contextWindow, pressureTokens, surfaceTokens, sampledSurfaceTokens }) => ({
    ...contextWindow === undefined ? {} : { contextWindow },
    ...pressureTokens === undefined ? {} : { pressureTokens },
    ...pressureTokens === undefined || sampledSurfaceTokens === undefined
      ? {}
      : { projectedTokens: Math.max(0, pressureTokens + surfaceTokens - sampledSurfaceTokens) },
  }),

경계 조건 둘은 이 코드에서 바로 나옵니다. 첫째, provider가 usage를 안 주면 프로젝션 측 pressureTokens가 계속 없고 둘째·셋째 전개가 안 나와 UI는 점유율을 표시하지 않아요(Agent Note: 압력과 용량이 모두 알 때만 점유율 표시). 결정 측은 영향 없고 measure()는 estimated 휴리스틱 앵커로 퇴화해 계속 숫자를 줍니다. 둘째, 점유율의 비원자 분기는 데모 6단계에서 이미 뜬 문서 변호로, Agent Note 29–35행이며 제목이 “컨텍스트 점유율은 근사값이고, 그것이 곧 결정 자체”입니다.

대조해 보면 세 곳이 같은 문제에 답합니다. 점유율 숫자를 누가 쓰고, 틀리면 누가 값을 치르나. Grok은 영원히 일치하는 거친 숫자를 골랐고, Claude Code는 표시 카운트에 중복 방지 패치를 달았으며, DSH는 소비자 둘을 완전히 나눈 뒤 문서에서 표시 쪽이 근사값임을 인정합니다.