Interlock · Experiment E7실험 E7
How long Interlock's checks takeInterlock 검사에 걸리는 시간
Interlock runs inside the agent as hooks: when it reads a file, before each edit is written, and after it. The agent waits on every one of them, so E7 measures how long each hook takes to answer. Interlock은 에이전트 안에서 훅으로 동작합니다. 파일을 읽을 때, 편집을 쓰기 전, 쓴 뒤에 실행됩니다. 에이전트는 매번 이 훅을 기다리므로, E7은 각 훅이 답하는 데 걸리는 시간을 쟀습니다.
Run on 2026-10-18 with Interlock V3.0.0 (after the review fixes) on a 2 vCPU VM with the local store. E7 uses no agent sessions.2026-10-18, 리뷰 결함을 고친 Interlock V3.0.0, 2 vCPU VM, 로컬 저장소로 실행. E7에는 에이전트 세션을 쓰지 않았습니다. Raw results (JSON)원자료 (JSON)
Method방법
- Setup: a git repository with one Python file of 500 to 10,000 lines, and a signature change that another agent has declared on one of its functions.구성: 500~10,000줄짜리 파이썬 파일 하나가 있는 git 저장소, 그리고 다른 에이전트가 그 파일의 함수 하나에 선언한 시그니처 변경.
- Calls: each hook is sent to Interlock's local daemon over HTTP the way Claude Code's hooks call it: a new connection per hook and the same request body. Every call makes a different edit, so no answer comes from a cache. 200 calls per hook and file size.호출: Claude Code의 훅이 부르는 방식 그대로(훅마다 새 연결, 같은 요청 본문) Interlock의 로컬 데몬에 HTTP로 보냅니다. 호출마다 다른 편집이라 캐시에서 나오는 답은 없습니다. 훅·파일 크기마다 200회.
- Measured from sending the request to receiving the whole answer. Our target is a median (p50) of at most 10 ms and a 99th percentile (p99) of at most 25 ms on a 2,000-line file.측정은 요청을 보낸 때부터 답을 다 받을 때까지입니다. 목표는 2,000줄 파일에서 중앙값(p50) 10 ms 이하, 99번째 백분위(p99) 25 ms 이하입니다.
Results결과
p50 / p99 in milliseconds; the last column is a single first read after the file changed elsewhere.단위 ms, p50 / p99. 마지막 열은 파일이 다른 곳에서 바뀐 뒤 첫 읽기 1회입니다.
| File lines파일 줄 수 | Read (with declared signatures)읽기 (선언된 시그니처 포함) | Edit check편집 검사 | Edit adding a call to a declared signature선언된 함수 호출을 추가하는 편집 | After an edit편집 후 응답 | First read after a change변경 후 첫 읽기 |
|---|---|---|---|---|---|
| 500 | 1.9 / 5.5 | 5.6 / 18.2 | 6.8 / 20.9 | 3.4 / 17.9 | 16 |
| 2,000 | 3.4 / 6.1 | 5.9 / 19.2 | 5.7 / 39.8 | 4.0 / 19.2 | 12 |
| 5,000 | 4.0 / 8.5 | 7.4 / 19.8 | 9.1 / 26.2 | 3.8 / 16.9 | 13 |
| 10,000 | 10.2 / 20.3 | 8.7 / 23.4 | 16.8 / 40.8 | 4.3 / 14.5 | 36 |
- On a 2,000-line file, every hook answered in about 3 to 6 ms at the median.2,000줄 파일에서 모든 훅의 중앙값은 약 3~6 ms였습니다.
- p99 moves from run to run, because it is the slowest 1% of 200 to 300 samples. We measured the 2,000-line file five more times with 300 calls each: p50 was 2.6 to 6.3 ms and p99 about 5 to 24 ms, inside the target every time. The 39.8 ms in the table above is the one run of six that missed it.p99는 200~300개 표본 중 가장 느린 1%라서 실행마다 흔들립니다. 2,000줄 파일을 300회씩 5번 더 재 보니 p50은 2.6~6.3 ms, p99는 약 5~24 ms로 5번 모두 목표 안이었습니다. 위 표의 39.8 ms는 6번 중 목표를 넘은 1번입니다.
What to watch주의할 점
- Large files miss the target. At 5,000 lines the p99 for an edit that adds a call is 26.2 ms; at 10,000 lines the median read and call check are over 10 ms.큰 파일은 목표를 넘습니다. 5,000줄에서 호출을 추가하는 편집의 p99는 26.2 ms이고, 10,000줄에서는 읽기와 호출 검사의 중앙값도 10 ms를 넘습니다.
- This is the local store. With a team server, an edit that needs a new claim adds one network round trip.로컬 저장소 기준입니다. 팀 서버를 쓰면 새 점유가 필요한 편집마다 네트워크 왕복이 1회 더해집니다.
Limits한계
- One machine and one synthetic file shape. Real repositories have many files and other processes competing for the CPU.한 기계, 한 가지 형태의 합성 파일입니다. 실제 저장소에는 파일이 많고 CPU를 나눠 쓰는 다른 프로세스가 있습니다.
- These values come after we fixed a fault in the benchmark: it could send the next hook while the previous one's follow-up work was still queued. An earlier run on a different VM, with that overlap, is included in the raw data.벤치 도구 결함을 고친 뒤의 값입니다. 앞 훅의 후속 작업이 대기열에 남아 있는 동안 다음 훅을 보낼 수 있었습니다. 그 겹침이 있던 다른 VM에서의 첫 측정도 원자료에 넣었습니다.
- The Interlock source and the benchmark are not public.Interlock 소스와 벤치 도구는 공개하지 않습니다.