toranalytics.github.io RSS Feed

AI가 만든 광고 소재를 바로 쓰지 못했던 이유

Tue, 03 Nov 2026 00:00:00 GMT

광고 소재를 준비하면서 AI 이미지 생성도 시험했다. 화면에 이미지가 나오는 것과 실제로 사용할 수 있는 소재가 만들어지는 것은 달랐다. 검토 과정에서 수정하거나 제외해야 하는 결과가 있었다.

처음에는 이미지가 생성됐는지부터 보게 된다. 그런데 실제로는 글씨를 읽을 수 있는지, 표현이 사실과 맞는지, 사용하는 이미지가 적절한지까지 살펴봐야 했다.

시안이 완성된 것과 검수가 끝난 것은 다르다

검토할 기준을 정리하고 결과물을 다시 봤다. 일부 시안에는 그대로 쓰기 어려운 표현이나 이미지가 있었다. 생성 결과가 자연스러워 보이더라도 내용까지 사실이라는 보장은 없었다.

만든 시안이 전부 사용된 것도 아니다. 수정을 거치거나 사용하지 않기로 한 것들이 있었다. 이때 기록하고 싶은 건 몇 개를 만들었느냐보다 왜 그대로 쓰지 못했느냐였다.

무엇을 보여 주려는지부터

도구가 여러 시안을 빠르게 제안해도 어느 표현이 적절한지는 사람이 확인해야 한다. 내가 전달하려는 내용과 실제 결과가 맞는지 살피는 과정도 필요하다.

이후 소재를 볼 때는 생성 여부만 확인하지 않으려고 했다. 광고를 보는 사람이 무엇을 이해하게 될지, 그 내용이 사실에 맞는지를 함께 보게 됐다.

자동화에 집중하다가 먼저 해야 할 일을 놓쳤다

Tue, 03 Nov 2026 00:00:00 GMT

반복되는 마케팅 업무를 줄이려고 자동화를 만들고 있었다. 데이터를 모으고 보고를 정리하는 작업도 있었고, 다른 운영을 돕는 방법도 살폈다.

문제는 자동화에 집중하는 동안 직접 먼저 챙겼어야 할 업무를 놓친 적이 있다는 것이다. 필요한 도구를 만드는 일도 중요하지만, 지금 필요한 결과물이 늦어지면 순서가 바뀐다.

도구를 만드는 일은 계속 늘어난다

연결할 데이터나 손볼 화면은 언제나 더 찾을 수 있다. 하나를 만들면 그다음에 개선할 부분도 보인다. 그런데 지금 필요한 것이 도구의 새 기능이 아니라 실제로 사용할 결과물일 때도 있다.

나는 이 둘을 충분히 나누지 못했다. 자동화를 만들면 나중에 편해질 수 있지만, 그 사이에 처리해야 하는 운영까지 저절로 끝나는 건 아니었다.

필요한 결과물부터 구분했다

그 뒤로는 지금 끝내야 할 일이 무엇인지 먼저 보려고 했다. 정보를 모으는 일인지, 누군가 검토할 초안을 만드는 일인지, 실제로 운영에 반영하는 일인지 나눠 보는 식이다.

이렇게 구분해도 우선순위를 정하는 일이 항상 쉬운 것은 아니다. 다만 무언가 만들고 있을 때도 그것이 당장의 문제를 해결하는지, 다른 중요한 일을 미루고 있지는 않은지 확인하게 됐다.

AI 에이전트 대회를 준비하면서 문제를 가리고 연습했다

Tue, 03 Nov 2026 00:00:00 GMT

카카오톡 기반 AI 에이전트 대회를 준비했다. 처음 보는 업무를 짧은 시간 안에 파악하고, 대화로 쓸 수 있는 에이전트를 만드는 연습이 필요했다.

그래서 가상의 업무를 정하고, 인터뷰부터 구현과 채점까지 해 봤다. 구현에는 AI 코딩 에이전트를 활용했다. 내가 맡은 일은 문제를 풀 구조를 정하고, 작업을 나누고, 결과를 검증할 기준을 만드는 것이었다.

출제하는 쪽과 푸는 쪽을 나눴다

연습 문제를 만들 때는 상황과 채점 기준을 먼저 정해 뒀다. 풀이 쪽은 정답을 보지 않은 채 인터뷰 내용을 바탕으로 요구사항을 정리하고 구현했다. 결과를 본 뒤에 정답 기준을 바꾸지 않으려는 방식이다.

가상의 수리점과 세탁소, 보조기기 대여 업무를 각각 연습했다. 회차마다 문제도 채점 방식도 달랐다. 따라서 점수를 나란히 놓고 그 차이만큼 성능이 올랐다고 말할 수는 없다.

보조기기 대여를 주제로 한 네 번째 리허설에서는 자동 채점 30점 중 27점을 받았다. 직접 준비한 모의 문제의 결과다. 실제 대회 성적이나 실제 사용자 환경에서의 성능은 아니다.

말하는 것과 실행하는 것을 나눴다

에이전트가 안내만 하는 게 아니라 예약이나 저장을 처리한다면 잘못 실행했을 때 사용자가 겪는 문제가 생긴다. 그래서 대화를 해석하는 부분과 실제 변경을 승인하는 부분을 나눴다.

사용자가 최신 확인 카드의 내용을 보고 승인하도록 했다. 저장 직전에도 내용을 다시 확인한다. 요청을 보낸 뒤 결과를 알 수 없을 때는 같은 요청을 무작정 다시 보내지 않도록 했다. 이미 처리된 요청을 다시 보내면 중복 실행될 수 있어서다.

실제 연결도 해 봤다

준비한 봇을 카카오톡에 연결하고 휴대폰에서 응답을 확인했다. 서버 프로세스를 강제로 종료한 뒤 자동으로 복구되는지도 시험했다.

실제 연결을 해 보니 모의 채점과 따로 확인할 것들이 있었다. 메시지가 도착하는지, 승인할 내용이 사용자에게 제대로 보이는지, 서버가 멈췄을 때 다시 응답할 수 있는지 같은 것들이다. 준비한 환경에서 동작을 확인한 것이며 모든 장애에 안전하다는 뜻은 아니다.

리허설을 반복하면서 정답을 맞힌 항목뿐 아니라 빠뜨린 요구사항과 실행 경계도 살펴봤다. 회차마다 드러난 문제를 다음 연습을 준비할 때 반영했다.

자동으로 모은 숫자도 다시 확인했다

Tue, 03 Nov 2026 00:00:00 GMT

여러 곳의 데이터를 모아 보고할 때 자동화 도구를 활용했다. 한 번은 정리된 값이 다른 자료에서 확인한 내용과 맞지 않았다. 다시 확인하면서 단위와 출처를 살펴봐야 했다.

보고서에 숫자가 잘 표시돼 있어도 그 값이 어떤 조건으로 계산됐는지는 따로 봐야 한다. 숫자가 있다는 사실만으로 원자료와 연결되는 과정까지 검증된 건 아니었다.

어디서 가져온 숫자인지

같은 이름의 지표라도 조회한 기간이나 기준에 따라 뜻이 달라질 수 있다. 여러 결과를 한 화면에 모을 때는 각각 어떤 자료에서 왔는지 알 수 있어야 한다.

출처가 다른 값을 바로 비교하면 이유를 잘못 해석할 수 있다. 나는 차이가 보이는 항목을 다시 조회하고, 값의 출처와 표시 기준을 확인하는 과정을 거쳤다.

보고서에도 확인 범위를 남기기

자동으로 숫자를 모으면 확인할 자료를 정리하는 데 도움이 된다. 그렇다고 숫자의 의미까지 자동으로 보장되지는 않는다. 원자료가 바뀌었거나 기준이 맞지 않을 가능성도 살펴봐야 한다.

그 뒤로 보고할 때는 숫자와 함께 어떤 자료를 봤는지 적으려고 한다. 아직 대조하지 못한 항목이 있다면 그 부분도 따로 남긴다. 결과를 읽는 사람이 무엇을 확인한 상태인지 알 수 있도록 하기 위해서다.

자동화를 만들 때 사람의 확인이 필요한 지점

Tue, 03 Nov 2026 00:00:00 GMT

반복 작업을 자동화하면서 어디까지 맡길 수 있는지 고민했다. 정보를 모아 변경을 제안하는 것과 실제 상태를 바꾸는 것은 다르게 다뤄야 했다.

도구가 만든 후보를 사람이 살펴보는 단계가 있고, 미리 정한 조건 안에서 처리하는 단계도 있다. 중요한 건 어떤 범위까지 허용됐는지와 실제로 무엇이 처리됐는지를 확인할 수 있어야 한다는 점이었다.

제안과 실행을 나눠 봤다

변경할 내용을 미리 보여 주면 사람이 근거를 살펴볼 수 있다. 실제 실행 전에 범위를 확인하고, 실행 후에는 결과를 다시 읽어 보는 과정도 필요하다.

자동화가 완료라고 보고한 것만으로 실제 상태까지 확인됐다고 볼 수는 없다. 보고와 결과가 맞는지 살펴야 한다. 특히 변경이 외부 서비스에 영향을 준다면 어떤 항목을 처리했는지 남겨 두는 편이 좋다.

규칙을 정하는 것만으로 끝나지 않았다

사전에 정한 조건도 적용 대상과 예외가 분명해야 한다. 사람이 검토할 항목과 정해진 규칙 안에서 처리할 항목을 섞으면 나중에 무엇이 승인됐는지 알아보기 어려워진다.

나는 자동화가 할 수 있는 일을 늘리는 것만큼 멈춰야 할 지점을 정하는 것도 중요하다고 생각하게 됐다. 어디까지 동작을 확인했는지는 따로 기록하고, 확인하지 못한 부분은 완료라고 말하지 않으려고 한다.

스프레드시트에서 시작한 마케팅 리포트 대시보드

Tue, 03 Nov 2026 00:00:00 GMT

와이낫에서 마케팅 업무를 하면서 광고 결과를 정리해 전달했다. 숫자를 모으는 것도 일이었지만, 그 숫자를 보는 사람이 현재 상황을 이해할 수 있도록 설명을 붙이는 데도 시간이 들었다.

나는 반복되는 리포트 작업을 줄이고 싶었다. 처음부터 큰 대시보드를 생각한 건 아니었다. 매번 비슷하게 정리하던 스프레드시트 작업에서 출발했다.

처음에는 시트 안에서 해결했다

시트에서 반복하는 작업을 자동화했다. 매번 직접 처리하던 내용을 일정한 방식으로 정리하려는 시도였다.

그런데 시트 구조가 바뀌면 기존 방식도 영향을 받았다. 데이터가 늘어나고 보여 줘야 할 내용이 달라질수록 시트 안에서 모든 걸 해결하기 어려워졌다.

화면을 따로 만들었다

이후 데이터를 불러와 지표와 흐름을 볼 수 있는 대시보드로 넓혔다. 결과를 정리하는 화면과 리포트를 전달하는 방식도 함께 고민했다. AI가 만든 분석 문구는 사람이 다시 살펴보고 수정할 수 있도록 했다.

내 역할은 어떤 데이터를 어떤 흐름으로 보여 줄지 정하고 결과를 확인하는 것이었다. 구현에는 AI 코딩 도구를 활용했다. 화면과 기능을 만들었다는 것과 실제로 누군가의 판단이 좋아졌다는 것은 다르다. 후자는 이 글에서 단정하지 않겠다.

남은 한계도 있었다

외부 데이터를 연결할 때는 인증이나 접근 조건을 확인해야 했고, 원하는 모든 내용을 항상 자동으로 가져올 수 있었던 것도 아니다. 대시보드를 만들었다고 리포트 업무의 모든 문제가 사라지지는 않았다.

이때부터 계속 생각한 질문이 있다. 숫자를 잘 아는 내가 화면을 이해하는 것과, 처음 보는 사람이 같은 화면에서 다음 행동을 정하는 것은 다르지 않을까. 이후 다른 환경에서 도구를 만들 때도 이 질문을 다시 꺼내게 됐다.

대시보드를 직접 써 보니 할 일이 화면 아래에 있었다

Tue, 03 Nov 2026 00:00:00 GMT

현황을 모아 보는 도구를 만들면서 광고를 잘 모르는 사람의 입장이라고 생각하고 직접 써 봤다. 정작 무엇을 해야 하는지는 화면 아래쪽에 있었다. 확인할 숫자는 보이는데, 할 일을 찾으려면 더 내려가야 했다.

만든 사람이 아는 화면

나는 메뉴에 어떤 정보가 있는지 이미 알고 있었다. 화면을 만들 때는 그 전제를 잊기 쉽다. 내가 자주 확인하는 지표를 위에 놓는 것이 처음 쓰는 사람에게도 같은 순서로 이해된다는 보장은 없다.

직접 써 본 뒤 할 일을 보여 주는 부분을 화면 위쪽으로 옮겼다. 문구도 내부에서 쓰는 표현보다 지금 어떤 상태를 확인해야 하는지 드러나도록 고쳤다.

화면을 바꾼 것과 사용성을 증명한 것

위치를 바꾸고 문장을 고친 것까지는 내가 확인한 작업이다. 그렇다고 다른 사람이 이 화면만 보고 혼자 판단할 수 있다는 사실을 검증한 것은 아니다. 실제로 다른 사람이 써 보고 막히는 부분을 확인해야 한다.

와이낫에서 리포트를 만들 때도 결과를 받는 사람이 숫자를 이해할 수 있을지를 고민했다. 이번에는 화면을 연 직후 무엇을 할 수 있는지 보려고 했다. 이전 대시보드와 지금의 도구는 서로 다른 시기에 만든 별개 작업이다.

AI한테 같은 말을 또 하게 돼서, 이름과 캐릭터를 다시 고민했다

Tue, 03 Nov 2026 00:00:00 GMT

Claude Code나 Codex를 쓰다 보면 같은 말을 여러 번 하게 된다. 그래서 내가 했던 지적을 저장했다가 비슷한 요청이 나올 때 다시 보여 주는 플러그인을 만들었다. 지금 이름은 Off the Wall이다.

그런데 이름만 보면 이 도구가 뭘 하는지 바로 떠오르지 않는다. README의 앵무새도 그냥 말을 따라 하는 도구처럼 보일 수 있다. 실제로 만들고 싶었던 건 내가 앞서 한 말을 AI에게 다시 떠올려 주는 쪽이었다.

화나는 기분을 이름에 넣어 봤다

같은 실수를 보고 있으면 “내가 아까 말했잖아”라는 말이 나온다. 이 기분을 좀 더 짧고 장난스럽게 표현하고 싶었다. FFS Again 같은 이름도 생각해 봤다. 답답함은 전해지지만, 이름만으로는 AI 코딩 도구에서 어떤 문제를 다루는지 알기 어려웠다.

그래서 dude-toldya라는 이름을 후보로 올렸다. “야, 내가 말했잖아”에 가까운 구어체다. 도구를 켜 놓고 계속 AI를 혼내는 이미지보다는, 전에 했던 말을 다시 보여 주는 친구 같은 느낌을 원했다.

비슷한 이름이 이미 있었다

찾아보니 toldya라는 도구가 이미 있었다. Claude Code 기록에서 반복된 지적을 찾고, 사용자가 고른 내용을 규칙 파일에 반영하는 도구다. 비슷한 문제를 다루는 만큼 dude-toldya가 이름만 살짝 바꾼 것처럼 보일 수 있다.

내 플러그인은 지적을 규칙으로 바꾸는 대신 내가 쓴 표현을 그대로 보관하고 다시 보여 주는 쪽을 택했다. 그래도 이름이 주는 혼동은 별개의 문제다. 정확한 이름, 패키지명, 상표를 모두 검토한 것은 아니라서 아직 이름을 바꾸지는 않았다.

앵무새 대신 AI를 그려 봤다

캐릭터도 바꿔 보고 싶었다. 처음에는 구겨진 메모지에 표정을 넣었다. 과거의 지적을 보관하는 역할은 보여 주지만, Claude Code나 Codex를 쓰다가 답답해진 상황이 바로 떠오르지는 않았다.

그다음에는 Gajae Code의 GitHub에 있는 도트 캐릭터와 어두운 배경 구성을 참고했다. 가재나 로고를 가져오지는 않고, 픽셀 표현과 작은 캐릭터가 주는 인상을 참고했다.

여기에 ‘조용히 하세요!’ 짤의 허탈한 타이밍을 섞어 봤다. 멍한 터미널 로봇이 가벼운 꿀밤을 맞는 장면이다. AI 이미지 생성 도구로 만든 시안이고, 아직 확정된 마스코트는 아니다.

이름보다 먼저 설명해야 할 것

이 도구는 Claude Code와 Codex에서 같은 작업 폴더에 저장된 과거 지적을 골라 답변 전에 원문으로 보여 준다. 다만 골라진 문장이 항상 관련 있다는 보장은 없다. 무관한 지적이 함께 붙는 문제도 확인했고, 실제 사용자가 덜 반복해서 지적하는지는 아직 측정하지 못했다.

이름과 그림이 재미있어도 그 한계는 그대로 적어야 한다. 우선은 후보 이름과 시안을 살펴보고, 기존 도구와 혼동되지 않으면서도 무엇을 하는지 더 잘 전할 수 있는지 고민해 보려고 한다.

개인 LLM 서비스를 서버로 옮기면서 복구 경로도 같이 정리했다

Tue, 03 Nov 2026 00:00:00 GMT

개인적으로 쓰는 LLM 기반 서비스를 클라우드 서버로 옮겼다. 옮길 파일이 많았고, 전송이 중간에 멈출 수도 있었다. 파일을 전부 다시 보내야 하는 상황을 피하려고 이어서 전송할 수 있는 구조를 준비했다.

작업은 내가 구조를 정하고 AI 코딩 에이전트에 나눠 맡기는 방식으로 진행했다. 구현한 뒤에는 이전과 호출이 실제로 되는지 확인했다.

파일을 옮기고 복구본을 남겼다

전송이 끊겼을 때 이어 가는 것과 데이터가 잘못됐을 때 되돌리는 것은 다른 일이다. 그래서 중단 후 이어서 전송하는 구조와 별도로 데이터베이스 복구본도 보관했다.

이전을 시작한 것만으로 끝난 건 아니다. 전송이 중단됐다가 다시 진행되는지, 필요한 데이터가 대상 서버에 있는지도 살펴봐야 했다. 파일 수가 많을수록 어디까지 진행됐는지 확인하는 일이 중요했다.

모델 호출 경로를 바꿨다

LLM 호출은 서버 중계와 역방향 SSH 터널을 이용하는 구조로 바꿨다. 역방향 SSH 터널은 떨어진 장비 사이에 통신 경로를 열어 원격 서버에서 다른 쪽의 서비스를 이용하도록 하는 방식이다.

터널 연결이 끊기면 자동으로 다시 연결되도록 구성했다. 확인 기록에서는 재연결까지 약 6초가 걸렸다. 내가 구성한 환경에서 확인한 시간이고, 모든 장애가 그 안에 복구된다는 뜻은 아니다.

한 번 연결된 뒤에도 볼 것

이전한 서버에서 모델 호출이 되는 것까지 확인했다. 그렇지만 한 번 연결되는 것과 계속 안정적으로 운영되는 것은 다르다. 전송을 이어 가는 장치, 복구본, 자동 재연결은 각각 다른 상황에 대비한 것이다.

개인 프로젝트라 해도 서버가 멈추거나 연결이 끊기면 다시 살펴봐야 한다. 이번에는 어디서 이어서 시작할지, 연결이 돌아왔는지를 확인할 수 있도록 경로를 정리해 뒀다.

영상은 완성하기 전에 초안부터 공유하기로 했다

Tue, 03 Nov 2026 00:00:00 GMT

광고 영상을 기획하고 시안을 만드는 일을 했다. 도구를 이용해 초안을 만들었지만, 만들어진 영상이 그대로 사용 가능한 결과물이 되는 것은 아니었다. 내용과 표현을 고쳐야 했고 다시 살펴볼 부분도 있었다.

완성도를 혼자 오래 붙잡기보다 방향을 확인할 수 있는 초안을 먼저 공유하라는 피드백을 받았다. 이후에는 기획과 초안, 완성 작업을 나눠 진행했다.

방향을 먼저 맞췄다

내가 기획과 초안을 준비하고 영상 작업을 맡은 동료와 결과물을 다듬는 식으로 역할을 나눴다. 초안을 보고 어떤 방향이 필요한지 이야기를 나눈 다음 수정할 내용을 정했다.

작업량과 일정이 맞지 않을 때는 우선 결과물 하나로 방향을 확인하기도 했다. 처음부터 여러 개를 만드는 것보다 실제로 사용할 수 있는 방향인지 살펴보는 일이 먼저였다.

시안과 성과는 따로 봤다

영상을 만들고 의견을 반영한 것은 작업 과정이다. 그 자체로 광고 성과가 좋아졌다는 뜻은 아니다. 효과를 말하려면 실제 집행 결과를 따로 확인해야 한다.

이후에는 혼자 완성했다고 생각할 때까지 기다리기보다, 다른 사람이 방향을 볼 수 있는 단계에서 먼저 공유하려고 했다. 초안이 완벽하지 않아도 다음 작업을 함께 정할 수 있기 때문이다.

안 된다고 말하기 전에 공식 자료부터 봤어야 했다

Tue, 03 Nov 2026 00:00:00 GMT

새로운 환경에서 광고 업무를 시작하고 반복 작업을 줄일 방법을 찾았다. 당시 나는 어떤 설정은 수동으로 해야 한다는 취지로 설명했다.

나중에 공식적으로 지원하는 방법을 다시 살펴보니 처음 판단을 정정해야 했다. 필요한 자료를 충분히 확인하기 전에 결론부터 말한 것이다.

모르는 것과 불가능한 것은 다르다

어떤 기능이 안 보인다고 해서 기능이 아예 없는 것은 아니다. 사용 조건이 맞지 않을 수도 있고, 내가 아직 적절한 경로를 찾지 못했을 수도 있다. 당시에는 이 구분을 충분히 하지 못했다.

내가 전달한 내용을 바탕으로 다른 사람도 다음 작업을 정할 수 있다. 그래서 확인하지 않은 부분이 있다면 그 사실까지 같이 말했어야 했다.

다시 확인하고 작은 범위에서 시험했다

공식 자료를 찾아보고 지원하는 경로를 확인했다. 이후에는 제한된 조건에서 실제 동작을 시험하고 결과를 다시 조회했다. 확인한 범위는 그 시험에서 동작했다는 사실까지였다.

이 경험 이후에는 가능 여부를 말할 때 공식 지원 여부, 현재 조건, 실제로 확인한 범위를 나눠 보려고 한다. 답을 바로 아는 것보다 내가 어디까지 알고 있는지 정확하게 전달하는 편이 다음 일을 정하는 데 도움이 되기 때문이다.

서로 다른 기록을 맞춰 보면서 배운 것

Tue, 03 Nov 2026 00:00:00 GMT

성과를 확인할 때 서로 다른 도구의 숫자가 어긋나 보이는 일이 있었다. 그래서 각 도구가 어떤 행동을 어떤 기준으로 기록하는지부터 살펴봤다.

합계만 나란히 놓으면 차이가 나는 지점을 찾기 어렵다. 비교할 수 있는 단위로 나눠서 어느 쪽에 기록이 있고 없는지 살펴보는 과정이 필요했다.

기록되는 시점이 다를 수 있다

한쪽에서 어떤 일이 끝났다는 사실과 다른 도구에 관련 기록이 들어오는 시점이 같다고 가정할 수는 없다. 기록되는 경로와 기준이 다르면 차이가 생길 수 있다.

나는 이런 경로를 살펴보고 일부 정보를 보완하는 방법과 앞으로의 개선 방향을 검토했다. 일부 전달 결과를 확인한 것과 전체 기록이 정확해졌다고 입증한 것은 다르다. 비교에 사용한 원자료 자체에 빠진 내용이 없는지도 확인해야 한다.

확인한 범위를 나눠 적기

문제가 보였다고 해서 원인이 전부 밝혀지는 건 아니다. 어떤 경로는 확인했고, 어떤 경로는 추가 점검이나 다른 사람의 작업이 필요할 수 있다.

이 일을 하면서 구현한 것, 실제로 적용한 것, 효과까지 확인한 것을 따로 적으려고 했다. 세 가지를 나누면 다음에 무엇을 확인해야 하는지도 조금 더 분명해진다.

개발자에게 AI 답변을 그대로 보내지 않기로 했다

Tue, 03 Nov 2026 00:00:00 GMT

업무 문제를 확인하면서 개발자에게 내용을 전달할 일이 있었다. 나는 AI 도구를 이용해 자료를 살펴보고 요청을 정리했다. 그런데 생성된 설명을 그대로 전달하면 상대가 읽어야 할 내용이 길어졌다.

요청 내용을 더 짧게 정리하라는 피드백을 받았다. 그 뒤로는 AI가 정리한 내용을 그대로 전달하기보다 내가 확인한 사실과 필요한 도움을 먼저 적으려고 했다.

확인한 것부터 정리했다

요청을 보내기 전에는 살펴볼 수 있는 자료를 다시 대조했다. 확인한 사실과 아직 확인하지 못한 부분을 나누고, 지나치게 단정한 표현이 있으면 고쳤다.

개발자에게는 문제를 발견한 상황과 검토를 부탁할 범위를 중심으로 설명했다. 긴 분석을 전부 전달하기보다 지금 무엇을 확인해야 하는지가 먼저 보여야 했다.

범위도 함께 조율했다

한 번에 넓은 작업을 요청하기보다 우선 필요한 범위를 정하고 조율한 적도 있었다. 내가 생각한 해법을 그대로 넘기는 것보다 현재 상황에서 무엇을 먼저 할 수 있는지 함께 정하는 쪽이었다.

AI가 초안을 빠르게 만들어 줘도 그 내용을 읽고 다음 일을 하는 건 사람이다. 그래서 보내기 전에 한 번 더 줄이고, 확인하지 않은 부분은 확인하지 않았다고 적으려고 한다.

I tried to rename my coding-agent plugin. Then I found another tool with almost the same name

Tue, 03 Nov 2026 00:00:00 GMT

“Did you actually run the tests?”

I’ve asked Claude Code and Codex versions of that question more than once. I built a plugin to save my corrections and show them again with later requests. I called it Off the Wall.

The problem: the name doesn’t tell you what it does. The README had a parrot, too. I didn’t really want the tool to just repeat me like a parrot. I wanted it to bring my earlier correction back when the agent needed the context.

So I started looking for a new name and a different character. The name part didn’t go quite as planned.

FFS Again?

One idea was FFS Again. It captures the feeling of watching your coding agent make the same mistake again. But if you saw it in a plugin list, would you know it had anything to do with Claude Code or Codex? Probably not without a description.

Then I considered dude-toldya. It sounded closer to what I was trying to say: dude, I already told you.

Then I searched for it.

There was already a toldya

toldya is an existing tool that looks for repeated corrections in Claude Code history and writes selected ones into a rules file with the user’s approval.

My plugin takes a different approach: it keeps the original wording and shows selected quotes again rather than turning them into rules. But if I called it dude-toldya, I could see someone assuming it was another version of that tool.

I haven’t settled on the name. The GitHub README calls it a working title, and the install commands still use off-the-wall. I haven’t completed a package-name or trademark check either.

I made a sticky note, but it didn’t look like AI

I also tried changing the character. The first AI-generated idea was a crumpled sticky note. That made sense for storing old corrections, but it didn’t really show the situation I had in mind: a coding agent doing something odd and me having to correct it again.

I looked at Gajae Code’s GitHub page. Its pixel character stands out in the README. I used the pixel-art and dark-background feel as a reference, not its character or logo.

Then I thought of the Korean “Please be quiet!” meme. The next AI-generated draft was a confused little terminal robot getting a gentle bonk on the head.

That one felt closer to the frustration behind the project. Neither the name nor the mascot is final.

A new name won’t fix this part

The plugin still has a problem: the selected quote isn’t always relevant. I ran otw explain on a haiku request, and its preview selected unrelated coding corrections to attach. This is the tool’s output from a fake repository with corrections made up for the demo.

Showing a correction again also doesn’t mean the agent will follow it. I haven’t measured whether real users need fewer repeated corrections.

For now, the GitHub README has the new mascot. The name can wait a bit longer. I’d like one that doesn’t get confused with another tool and still makes the problem recognizable.

Claude Code 플러그인 개선하려고 5가지 해 봤는데 하나도 기준을 못 넘었다

Thu, 29 Oct 2026 00:00:00 GMT

AI한테 같은 말을 또 하게 돼서, 이름과 캐릭터를 다시 고민했다

Off the Wall은 Claude Code와 Codex용 플러그인이다. 에이전트에게 했던 지적을 저장해 뒀다가 비슷한 일을 시킬 때 내가 했던 말 그대로 다시 보여 준다. 이 글은 잘된 것보다 안 된 걸 쓴다. 배운 게 거기에 더 많았다.

일단 되는 것부터

모델은 내가 커밋 메시지나 날짜를 쓰는 습관을 알 수 없다. 그런 습관 11개를 내가 만들어서 작업으로 바꾸고, 칸당 3번씩 33번 돌렸다. 화면 없이 자동으로 실행했다.

Claude Sonnet은 플러그인이 없으면 33번 중 2번, 있으면 20번 습관을 따랐다.
haiku는 첫 시험에서 1번에서 17번, 다시 재니 2번에서 25번이었다.

전부 내가 만든 습관이고 실제 사용자 기록이 아니다. 결과를 본 뒤에 채점기 오류를 고쳤기 때문에 재측정은 독립된 재현도 아니다. Opus와 Codex 모델은 못 재 봤다. 시험 설계는 쉬운 설명 글에 있다.

고치고 싶었던 문제

이 플러그인은 관련 없는 요청에도 인용을 붙인다. 저장된 지적과 상관없는 요청 8개에서 평균 1.8개가 붙었다. 나는 처음에 “비슷한 게 없으면 아무것도 붙이지 않는다”고 썼는데 사실이 아니었고, 그래서 공개로 정정했다. 지금 어떻게 붙는지는 otw explain으로 볼 수 있다. 가짜 저장소에서 하이쿠 요청을 넣어 본 실제 출력이다.

쓸모 있는 인용은 그대로 두고 이런 잡음만 줄이고 싶었다. 시험 전에 계획과 통과 기준부터 파일로 정해 놓고, 아이디어를 하나씩 돌렸다. 결과부터 말하면 다섯 개 다 못 넘었다.

시도 1. 단어 조건을 걸었다

공통 단어가 2개 이상이거나 드문 단어 1개가 겹칠 때만 붙이게 해 봤다. 지적 150개가 있는 저장소에서는 관련 없는 인용이 6.0개에서 2.0개로 확 줄었다. 좋아 보였는데, 같은 습관이 반복되는 240개짜리 저장소에서는 6.0개에서 5.5개로 거의 그대로였다. 저장소 하나에서만 되는 조건이라 버렸다.

시도 2. 짧은 입력용 변형 6개

짧은 입력에 붙는 인용을 줄이려고 변형을 6개 만들어 봤다. 기준을 넘은 게 없었다. 원래 있던 보호 장치(짧은 입력은 예전 기준을 쓴다)를 그대로 뒀다.

시도 3. 임베딩 모델을 붙였다

글자가 아니라 뜻으로 고르는 쪽을 보려고 작은 로컬 임베딩 모델(all-MiniLM-L6-v2)을 써 봤다. 한 설정은 잡음을 크게 줄였다. 그런데 따로 떼어 둔 사례에서 쓸모 있는 인용까지 너무 많이 놓쳤다. 설정을 3개 더 바꿔서 돌렸는데 같은 기준에서 전부 떨어졌다.

시도 4. 지적 옆에 원래 요청도 같이 보여 줬다

지적만 보여 주는 것보다 “그때 내가 뭘 시켰는지”까지 같이 보여 주면 모델이 더 잘 따르는지 봤다. 인용만 보여 줬을 때 33번 중 20번, 인용과 요청을 같이 보여 줬을 때 19번이었다. 이득이 없어서 안 넣었다.

시도 5. 같은 지적의 반복을 하나로 묶었다

위키처럼 같은 내용은 하나로 합치는 방식의 기억을 보고 가져온 아이디어다. 18/40 대 20/40으로 11% 올랐는데 내가 정한 기준은 25%였다. 기각했다.

그 뒤로 세 가지를 더 해 봤다 (10월 30일 추가)

큰 메모리 도구들이 쓰는 방식을 OTW에 옮기면 효과가 더 커지지 않을까 해서 세 가지를 더 시험했다. 이번에도 시험 전에 기준을 정해 놨고, 결과는 전부 기준 미달이었다.

시도 6. 반복된 지적은 하나 더 보여 주기. 같은 지적이 여러 번 저장돼 있으면 맨 아래 엉뚱한 인용 대신 같은 지적의 다른 표현을 하나 더 보여 주는 방식이다. 글자 유사도로는 반복 지적 90개 중 40개만 알아봤고, 목표 지적이 보이던 작업 하나를 오히려 잃었다.

시도 7. 판정 모델에게 반복인지 물어보기. 저장할 때 판정 모델에게 “전에 한 지적과 같은 습관이냐”를 물었다. 반복 지적 90개 중 73개를 맞게 찾았는데(후보 5개 안에 답이 있던 상한이 73개), 반복이 아닌 90개 중 73개도 연결해 버렸다. “같은 습관을 또 말한 것”과 “같은 종류의 다른 지적”을 구분하지 못했다.

시도 8. 주입하는 문구 바꾸기. 인용 앞뒤 문구를 “내가 정한 습관, 맞는 건 적용”이나 “답하기 전에 대조해서 고쳐라”로 바꿨다. haiku로 33번 중 현재 문구 21번, 바꾼 문구 22번과 20번 통과했다. 차이가 없었다.

안 따르는 작업을 따로 보니 이유가 문구가 아니었다. 한 작업은 지적이 모델에게 아예 전달되지 않았고(검색 실패), 두 작업은 지적이 보였는데도 모델이 요청이 명시적으로 요구하는 것을 옛 습관보다 우선한 것으로 보인다(출력 원문까지 읽어 확인한 건 아니다). 뒤의 경우는 블록이 “현재 요청이 우선”이라고 말하는 그대로의 동작이라 손대지 않는다. 지금 남은 간극은 이 두 가지다.

지금까지 한 실험 전체는 저장소의 실험 목록에 결과와 함께 있다.

결과 말고 배운 것

시험 러너가 실험 두 개에서 선택을 3개에서 자르고 있었다. 기본값은 6개다. 발견하고 기록해 뒀고 원래 숫자는 그대로 남겼다.
작업 하나의 채점기가 틀려서 나중에 다시 채점했다. 원래 표는 그대로 두고 옆에 정정을 적었다.
내가 만든 시험을 통과한 것과 실제 사용자한테 도움이 되는 건 다른 얘기다. 진짜 시험은 내 지적이 쌓이고, 알맞은 때 돌아오는지다. 그 증거는 아직 없다.

코드, 계획, 데이터, 실패한 시험 기록은 전부 저장소 docs에 있다. 세션에서 관련 없는 인용이 붙었거나 필요한 인용이 빠졌으면 이슈로 알려 주면 좋겠다. 원문은 안 보내도 된다.

Claude Code한테 같은 지적을 또 하기 싫어서 만든 플러그인, Off the Wall

Thu, 29 Oct 2026 00:00:00 GMT

AI한테 같은 말을 또 하게 돼서, 이름과 캐릭터를 다시 고민했다

모델은 내 습관을 모른다. 커밋 메시지를 쓰는 방식, 날짜를 쓰는 방식 같은 것 말이다. 이런 일을 Claude한테 33번 시켜 봤다. Off the Wall이 없으면 Claude(Sonnet)가 습관을 2번 따랐고, 있으면 20번 따랐다. 전에 내가 한 지적을 그대로 다시 보여 주기 때문이다. 시험용으로 내가 만든 습관이고 실제 사용자 기록으로 잰 건 아니다. haiku 모델에서는 1번에서 17번, 다시 재니 2번에서 25번이었다.

공개 0.3.1을 haiku와 시험용 습관으로 검증한 결과, 습관을 따른 비율이 6%에서 58%로 올랐습니다. 회수 끔 2/33, 켬 19/33. 별도 격리 프로필에서 한 번 돌린 결과이며, 시험 기록을 공개했다.

같은 요청을 플러그인 없이 한 번, 있을 때 한 번 돌려 본 실제 출력이다. 작업 3개를 첫 실행 그대로 보여 준다. 지적은 이 데모를 위해 내가 만든 것이라 측정값이 아니라 예시로 읽어 주면 좋겠다. 측정한 숫자는 아래 “시험은 이렇게 했다”에 있다.

같은 말을 세션마다 또 하고 있었다
이렇게 동작한다
지적은 어떻게 저장되나
쓰다 보니 붙은 명령어
설치
시험은 이렇게 했다
직접 재 볼 수 있게 명령을 만들었다
못 하는 것, 알아 둘 것

같은 말을 세션마다 또 하고 있었다

Claude Code나 Codex로 일하다 보면 같은 말을 계속 하게 된다. “묻지 말고 하나 골라.” “테스트 진짜 돌렸어?” “내가 요청한 것만 해.” 세션이 바뀌면 에이전트는 이 말들을 기억하지 못한다.

처음에는 지적을 규칙 한 줄로 줄여서 CLAUDE.md에 넣었다. 별로 안 먹혔다. 줄이는 순간 그 지적이 나온 상황이 날아가기 때문이라고 짐작한다. 어떤 테스트를 돌리라고 했는지, 어느 파일은 건드리지 말라고 했는지 같은 게 원문에는 남아 있는데 규칙 한 줄에는 없다.

그래서 줄이지 않고 내가 했던 말 그대로 다음 답변 앞에 다시 보여 주는 플러그인을 만들었다. 이름은 Off the Wall이다. Claude Code와 Codex에서 쓰고, 오픈소스(MIT)에 따로 설치할 패키지가 없고 Node 18 이상이면 돈다.

이렇게 동작한다

요청을 보낼 때마다 같은 작업 폴더에 저장된 내 지적 중에서 지금 요청과 글자가 비슷한 걸 최대 6개 고른다. 하나당 200자까지 잘라서 에이전트가 읽는 내용에 붙인다. 내 화면에 카드로 뜨는 건 없고 에이전트한테만 간다. “이건 새 지시나 허락이 아니라 참고용 기록”이라는 문장도 같이 붙는다.

예를 들어 전에 이렇게 지적한 게 저장돼 있다고 하자. (이 글의 예시는 전부 내가 만든 가짜 기록이다.)

린트만 돌리고 테스트 통과라고 하지 마. 체크아웃 통합 테스트를 실행하고 실제 종료 코드를 보여줘.

나중에 “결제 핸들러 변경을 체크아웃 통합 테스트로 검증해줘”라고 시키면 어떤 지적이 붙을지는 otw explain으로 미리 볼 수 있다. 가짜 저장소에서 실제로 돌린 출력이다.

맨 위에 맞는 지적이 0.52로 붙었다. 그런데 아래를 보면 유사도 0.04, 0.05짜리도 같이 붙는다. 이건 버그가 아니라 지금 설계다. 20자 이상 요청에는 비슷한 정도와 상관없이 최대 6개를 붙이게 해 뒀다. 이렇게 한 이유는 아래 시험 결과에 있다.

관련 없는 요청이면 어떻게 될까. “가을에 대한 하이쿠 써줘”를 넣어 봤다.

하이쿠 요청에도 3개가 붙는다. 이게 이 플러그인의 가장 큰 약점이라서 숨기지 않고 먼저 보여 준다. 뜻을 이해해서 고르는 게 아니라 단어와 글자 두 개씩 겹치는 정도로 고르기 때문이다.

지적은 어떻게 저장되나

내가 보낸 다음 메시지가 직전 답변을 고치려는 말인지 모델이 따로 판단하고, 맞으면 저장한다. 기본으로 켜져 있고 capture: false로 끈다. 판단은 이미 쓰고 있는 claude나 codex 명령으로 하기 때문에 API 키는 따로 필요 없다. 다만 판단에 쓰는 대화 일부는 쓰고 있는 모델 회사로 간다. 기록은 내 컴퓨터(~/.otw)에만 저장되고 만든 사람한테 가는 데이터는 없다.

내 답변이 느려지지는 않는다. 판단은 따로 도는 프로세스에서 하고, 내가 보낸 요청은 그 결과를 기다리지 않는다.

출처도 확인한다. 플러그인이 자동으로 보낸 메시지는 내 지적으로 저장하지 않는다. 출처나 작업 폴더가 없는 옛 기록은 지우지 않고 보관만 하고 회수에는 쓰지 않는다. 설정 파일이 잘못되면 기능이 켜진 채로 도는 게 아니라 꺼진 채로 멈춘다.

같은 작업 폴더의 기록만 쓴다는 점도 중요하다. 다른 프로젝트의 지적을 끌어오거나 최근 것으로 자리를 채우지 않는다. 하위 폴더와 git worktree는 서로 다른 프로젝트로 본다.

쓰다 보니 붙은 명령어

otw report: 컴퓨터에 이미 있는 Claude Code와 Codex 대화 기록에서 내가 에이전트의 일하는 방식을 고치려던 답장을 모델이 골라서 종류별로 보여 준다. 내가 한 말이 그대로 붙어서 나온다. --seed를 붙이면 그 결과로 바로 저장을 시작한다. 분류는 모델이 한 거라 틀릴 수 있다.
otw status: 저장된 지적 수, 훅이 마지막으로 돈 때, Codex에서 허용한 항목 수를 보여 준다. 쓰는 Codex 모델과, 설명에 등급이 없어서 안 쓰는 모델도 나온다.
otw explain "<문장>": 위에서 본 그 명령이다. 모델을 부르지 않고 아무것도 바꾸지 않는다. 아직 정식 배포(0.3.1)에는 없고 최신 소스(main)에만 있다.
otw forget --all --yes / --project --yes: 저장된 지적, 세션 기록, 로그를 지운다. --yes가 없으면 뭘 지울지만 보여 준다. Claude Code나 Codex의 대화 기록, 이미 모델 회사에 보낸 내용은 못 지운다.

처음 설치하고 아무것도 저장되지 않았을 때는 otw status가 그 상태를 이렇게 알려 준다.

하위 에이전트에게 맡길 모델을 안내하는 기능도 있다. 찾기와 변환은 작은 모델, 구현과 검토는 중간 모델, 원인 분석과 설계는 큰 모델을 고르라고 알려 주고, 모델을 정하지 않은 호출은 한 번 되돌려 보낸다. 모델을 강제하지 않고 비용이 줄어든다고 약속하지도 않는다.

설치

Claude Code에서는 이렇게 한다.

/plugin install off-the-wall --marketplace toranalytics/off-the-wall

Codex에서는 이렇게 하고, 설치 후 /hooks를 열어 한 번 허용해야 한다. 허용하기 전에는 아무 일도 안 일어난다.

codex plugin marketplace add toranalytics/off-the-wall
codex plugin add off-the-wall@off-the-wall

설치 전에 report가 어떤 모양인지 보고 싶으면 저장소에 있는 가상의 대화 기록으로 돌려 보면 된다.

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs report --host claude --claude-dir examples/claude-history --days 0

브라우저에서 먼저 보고 싶으면 원문 다시 보여 주기 데모가 있다. 설치도 로그인도 필요 없고 입력은 전부 내가 만든 사례다. 소스는 GitHub에 있다.

시험은 이렇게 했다

모두 내가 만든 기록으로 쟀다. Claude Code 2.1.311을 화면 없이 자동으로 돌렸고, 작은 모델(haiku)과 큰 모델(Sonnet)을 썼다. 숫자는 이 시험에서만 맞는 값이고 실제 사용에서의 효과를 뜻하지 않는다.

모델이 알 수 없는 습관(커밋 형식, 쓰는 도구, 말투, 날짜 형식 등) 11개를 작업으로 만들어서 각각 3번씩 시켰다. 작업과 채점기는 내가 아닌 다른 모델이 만들었고, 채점은 자동이고, 계획은 시험 전에 정해 뒀다.

조건	첫 시험(haiku)	채점기 오류를 고친 뒤 다시(haiku)	Sonnet
Off the Wall 없음	1/33	2/33	2/33
이전 기본(좁게 찾기)	9/33	14/33
넓게 찾기(0.3.0부터 기본)	17/33	25/33	20/33

맞는 지적이 보이면 모델이 훨씬 자주 따랐다. 못 찾으면 달라지는 게 없었다.
큰 모델(Sonnet)에서도 같았다. 작업별로 나아진 게 7개, 나빠진 게 0개였다(우연으로 보기 어렵다, p = 0.016). Off the Wall 없이는 큰 모델도 이 습관을 따르지 못했다.
다시 잰 시험은 결과를 본 뒤에 채점기를 고쳤으니 처음 시험의 독립된 재현은 아니다. 숫자가 오른 게 오류 수정 때문인지 실행마다 달라지는 값 때문인지는 가를 수 없다.
11개 중 4개 작업은 두 모델 모두 인용이 보여도 따르지 않았다. 규칙 150줄을 그냥 넣은 쪽이 전체로는 더 잘 따랐는데, 기록이 길어지면 그 방식은 못 쓴다.
Opus와 Codex 모델은 못 재 봤다.

관련 없는 요청에 붙어도 해롭지 않은지도 따로 봤다. 습관과 상관없는 작업 14개를 3번씩 시켰더니 Off the Wall 없음이 40/42, 넓게 찾기가 41/42였다. 통과율은 안 떨어졌고 출력 토큰은 약 9% 늘었다. 20자 미만 입력 보호 장치는 모델로 재 보지 않았다.

관련 없는 인용을 줄이려고 여러 가지를 시도했는데 전부 내가 정한 기준을 못 넘겨서 넣지 않았다. 그 이야기는 따로 글로 썼다.

실제 프로그램에서의 확인도 한 번씩만 했다. Codex 0.162.1에서는 설치, 허용, 지적 저장, 다음 요청에서 다시 보여 주기까지 확인했다. Claude Code 2.1.311에서는 자동 실행으로 저장과 새 세션에서의 다시 보여 주기를 확인했다. 같은 시험의 셋째 요청에서 모델이 6분 동안 이상하게 긴 출력을 낸 적이 한 번 있었다(8번 다시 해 봤을 때는 안 나왔다).

코드 시험은 239개가 Node 18, 20, 22, 26에서 통과한다. 전부 가짜 입력과 가짜 명령으로 한 시험이다. CI는 Windows, Linux, macOS의 Node 18, 20, 22에서 돈다.

직접 재 볼 수 있게 명령을 만들었다

내 숫자를 믿으라고 하기는 어렵다. 그래서 같은 시험을 누구나 자기 claude로 돌려 볼 수 있게 otw bench를 만들었다. 모델이 알 수 없는 습관이 필요한 작은 작업 11개를 회수 없이 한 번, 있게 한 번 돌리고 습관을 지킨 횟수를 센다.

bench는 현재 저장소 main에만 있다. 0.3.1 릴리스와 npm 패키지에는 없다. Claude Code에 플러그인을 설치하고 로그인한 뒤 아래처럼 저장소를 복제해 실행한다. 공개 0.3.1 원본은 별도 격리 프로필에서 한 번 확인했지만, 일반 사용 환경 전체를 검증한 것은 아니다. Claude Code는 전역 지침과 다른 플러그인을 읽고 세션 기록을 남길 수 있다.

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs bench
node bin/otw.mjs bench --yes

내 터미널에서 실험용으로 수정한 플러그인과 격리 프로필로 처음 돌린 결과는 이렇다. 회수 없이 3/33(9%), Off the Wall이 있으면 20/33(61%)이다. 모델은 haiku이고 습관은 시험용으로 지어낸 것이다. 66번 모두 플러그인 블록이 붙은 조건과 붙지 않은 조건이 정확히 갈렸다. 작업 하나(c136)는 회수 없이도 3번 다 통과했지만 이유는 확인하지 못했다. 한 번 돌린 결과이고 내 환경에서 나온 숫자다. 다른 환경에서는 다르게 나올 수 있어서, 돌려 보고 한 줄만 이슈로 알려 주면 고맙겠다. 결과 기록은 저장소에 있다.

못 하는 것, 알아 둘 것

실수가 줄어든다고 보장하지 못한다. 시험용으로 만든 습관에서는 효과를 봤지만 실제 사용 기록에서는 재 보지 못했다.
뜻을 이해해서 고르지 않는다. 위 스크린샷처럼 관련 없는 요청에도 붙는다. 0.3.0부터 20자 이상 요청에는 항상 최대 6개(약 300토큰)가 붙는다. 20자보다 짧은 입력은 이전 기준(비슷한 정도 0.18 이상)을 쓴다. 끄려면 설정에 "recallWide": false를 넣는다.
지적이 아닌 말을 지적으로 저장하거나 진짜 지적을 놓칠 수 있다. 한 사람의 기록으로 재 보니 저장한 것 중 82%가 맞았고, 진짜 지적 중 72%를 찾았다.
지우는 명령은 0.3.1부터 있는데 Claude Code나 Codex의 대화 기록, 모델 회사에 남은 사본까지는 못 지운다.
Claude Code를 직접 쓰는 화면에서는 확인하지 못했다. 화면 없이 자동으로 돌려서 저장과 다시 보여 주기를 한 번 확인한 게 전부다.
지금 버전은 정식 릴리스가 아니라 0.3.1 사전 릴리스다.

관련 없는 지적이 붙었거나 필요한 지적이 빠졌으면 이슈로 알려 주면 정말 도움이 된다. 원문, 코드, 회사 이름은 안 보내도 된다. 계획, 스크립트, 데이터, 독립 검토에서 나온 약점은 저장소 docs에 있다.

I tried five ways to improve my Claude Code plugin. None passed my own bar.

Thu, 29 Oct 2026 00:00:00 GMT

English version of the Korean original. If they differ, the Korean article is authoritative.

Dude, Toldya? (working title)

Off the Wall is a plugin for Claude Code and Codex. It saves the corrections you give your agent and shows them again, word for word, when you ask for something similar later. This post is about what did not work. I learned more from that.

First, what does work

A model can’t know how you write commit messages or dates. I made up 11 habits like that and turned them into tasks, 3 runs each, 33 runs per condition, run headless.

Claude Sonnet without the plugin followed the habit 2 times out of 33. With it: 20.
With haiku: 1 to 17 in the first run, and 2 to 25 in a rerun.

These are habits I invented, not real users’ records. I fixed a grader bug after seeing results, so the rerun is not an independent replication either. I have not measured Opus or the Codex models. The test design is in the plain-language post.

The problem I wanted to fix

The plugin also attaches quotes to unrelated requests. On 8 prompts that had nothing to do with the stored corrections, it attached 1.8 quotes on average. I had first written “if nothing is similar, nothing is attached”. That was false, and I corrected it publicly. Here is what it looks like now, real otw explain output on a made-up repository with a haiku request:

I wanted to cut this noise and keep the useful quotes. Before running anything I wrote the plan and the pass bar into files, then ran the ideas one by one. Short version: none of the five passed.

Attempt 1. A word condition

Attach only when two words overlap, or one rare word. On a store with 150 corrections, unrelated quotes dropped from 6.0 to 2.0. It looked great. On a store with 240 corrections where habits repeat, it went from 6.0 to 5.5, almost no change. A condition that works on one store only is not worth keeping, so I dropped it.

Attempt 2. Six variants for short inputs

To cut the quotes attached to short inputs I made six variants. None passed the bar. I kept the guard that was already there (short input uses the older rule).

Attempt 3. An embedding model

To see whether picking by meaning would work, I tried a small local embedding model (all-MiniLM-L6-v2). One setting cut the noise a lot, but on held-out cases it missed too many useful quotes. Three more settings failed the same bar.

Attempt 4. Show the original request next to each correction

I checked whether showing “what I had asked back then” next to the correction helps the model follow it. Quote only: 20 of 33. Quote plus request: 19 of 33. No gain, so I did not add it.

Attempt 5. Merge repeats of the same correction

An idea from a wiki-style memory: merge repeats into one. 18/40 against 20/40, a gain of 11%. My bar was 25%. Rejected.

Three more after that (added October 30)

I wondered whether borrowing what the big memory tools do would make the effect larger, so I tested three more. Again the bar was set before each run, and again none cleared it.

Attempt 6. Show a second wording of a repeated correction. If the same correction was saved several times, show another wording of it instead of an unrelated quote at the bottom. Text similarity recognised only 40 of 90 repeats, and the policy lost one task where the target correction had been shown.

Attempt 7. Ask the judge model whether it is a repeat. At capture time I asked the judge whether a new correction is the same habit as an earlier one. It linked 73 of 90 repeats correctly (73 was the ceiling, since the right answer was among the 5 candidates for only that many), but it also linked 73 of 90 corrections that were not repeats. It could not tell “the same habit said again” from “another correction of the same kind”.

Attempt 8. Change the wording around the quotes. I replaced the text around the quotes with “standing preferences, apply what fits” and “check your answer against these before replying”. On haiku the passes out of 33 were 21 for the current wording and 22 and 20 for the new ones. No difference.

Looking at the tasks that were not followed, the cause was not the wording. For one task the correction never reached the model (a retrieval miss). For two tasks the correction was shown, but the model seems to have put the explicit current request ahead of the old habit (I did not read the raw outputs to confirm). If so, that is exactly what the block says to do (“the current request takes precedence”), so I leave it alone. These two are what remains.

Every experiment so far is listed with its result in the repository’s experiment list.

What I learned besides the results

The runner cut my selection at 3 quotes in two experiments. The default is 6. I found it, wrote it down and left the original numbers in.
One task’s grader was wrong and I re-scored it afterwards. The original table stays, with the correction next to it.
Passing a test I made is not the same as helping a real user. The real test is whether your own corrections pile up and come back at the right time. I do not have that evidence yet.

Code, plans, data and every failed run are in the repository docs. If an unrelated quote shows up in your session, or a needed one is missing, tell me through an issue. You do not need to send your original text.

I got tired of repeating myself to Claude Code, so I built Off the Wall

Thu, 29 Oct 2026 00:00:00 GMT

English version of the Korean original. If they differ, the Korean article is authoritative.

Dude, Toldya? (working title)

A model can’t know your habits, like how you write commit messages or dates. I gave Claude 33 tasks like that. Without Off the Wall, Claude (Sonnet) followed the habit 2 times. With it, 20 times. It works because your own earlier correction is shown again, word for word. These are test habits I made up, not real users’ records. With the haiku model it went from 1 to 17, and from 2 to 25 when I measured again.

In a test of the public 0.3.1 release using haiku and habits I made up for testing, the habit was followed in 2/33 runs with recall off and 19/33 with recall on. This was one run in a separate isolated profile, not a measure of real users’ results. The test record is public.

Here is the same request run once without the plugin and once with it, real outputs, three tasks, first run shown as it came out. The saved correction was made up for this demo, so please read it as an illustration, not a measurement. The measured numbers are under “How I tested it” below.

I kept saying the same things every session
How it works
How corrections get saved
Commands I ended up adding
Install
How I tested it
A command so you can check my numbers
What it cannot do, and what to know

I kept saying the same things every session

If you work with Claude Code or Codex for a while, you end up repeating yourself. “Stop asking, just pick one.” “Did you actually run the tests?” “Only do what I asked.” Start a new session and the agent has forgotten all of it.

At first I squeezed each correction into a one-line rule and put it in CLAUDE.md. It did not help much. My guess is that the squeeze throws away the situation the correction came from: which test I wanted run, which file I said not to touch. The original sentence still has that. The one-line rule does not.

So I stopped shortening them. I built a plugin that shows what I said, word for word, before the agent answers. It is called Off the Wall. It works with Claude Code and Codex, it is open source (MIT), there is nothing else to install, and it runs on Node 18 or newer.

How it works

Every time you send a request, it looks at the corrections saved for the same working folder and picks up to 6 whose original request looks like the new one. It cuts each at 200 characters and adds them to what the agent reads. Nothing shows up as a card on your screen; only the agent gets them. A line is added saying this is a record for reference, not a new instruction or permission.

Say you saved this earlier (every example in this post is made up):

Don’t just run lint and say tests pass. Run the checkout integration test and show the real exit code.

Later you ask “Verify the payment handler change with the checkout integration test.” You can preview what would be attached with otw explain. This is real output on a made-up repository:

The right correction is on top with 0.52. But look further down: 0.04 and 0.05 are attached too. That is the current design, not a bug. Any request of 20 characters or more gets up to 6 quotes whatever the similarity, and the test results below are why I did it that way.

What about an unrelated request? I tried “write a haiku about autumn”.

Even the haiku gets 3 quotes. This is the biggest weakness of the plugin, so I am showing it first. It does not understand meaning. It picks by overlapping words and letter pairs.

How corrections get saved

A model decides, on its own, whether your next message is fixing the previous answer, and saves it if so. It is on by default, and capture: false turns it off. That check runs through the claude or codex command you already use, so there is no separate API key. The part of the chat used for it goes to your model company. Records stay on your computer in ~/.otw, and nothing goes to the author.

It does not slow your answers down. The check runs as its own process, and your request does not wait for it.

It also checks where a record came from. Messages a plugin sent automatically are not saved as your corrections. Old records with no source or folder are kept but never used. If the settings file is broken, the features stay off instead of running anyway.

It only uses the same working folder. It does not pull in corrections from other projects or fill the slots with recent ones. Subfolders and git worktrees count as separate projects.

Commands I ended up adding

otw report: has a model pick out, from the Claude Code and Codex chats already on your computer, the replies where you were fixing how the agent worked, and groups them by kind with your own words under each. --seed starts saving from that result. The grouping is done by a model and can be wrong.
otw status: how many corrections are saved, when the hooks last ran, how many Codex entries you allowed. It also lists the Codex models it uses and the ones it skips because their description names no tier.
otw explain "<sentence>": the one above. It does not call a model and changes nothing. It is only in the latest source (main), not in the 0.3.1 release.
otw forget --all --yes / --project --yes: deletes saved corrections, session records and the log. Without --yes it only shows what would go. It cannot delete your Claude Code or Codex chats, or anything already sent to the model company.

Right after install, before anything is saved, otw status tells you so:

There is also a hint feature for helper agents: use a small model for search and conversion, a middle one for building and review, a large one for finding root causes and design, and a helper call that names no model is sent back once. It does not force a model and it does not promise lower cost.

Install

In Claude Code:

/plugin install off-the-wall --marketplace toranalytics/off-the-wall

In Codex, then open /hooks once and allow the hooks. Until you do, nothing happens.

codex plugin marketplace add toranalytics/off-the-wall
codex plugin add off-the-wall@off-the-wall

To see what report looks like before installing, run it on the made-up chat history in the repository:

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs report --host claude --claude-dir examples/claude-history --days 0

If you would rather look in the browser first, there is a demo of showing corrections again (the interface is in Korean). No install, no login, and every input is a made-up case. The source is on GitHub.

How I tested it

Everything used made-up records. I ran Claude Code 2.1.311 automatically without a screen, with a small model (haiku) and a larger one (Sonnet). The numbers apply to these tests only. They do not show an effect in real use.

I turned 11 habits a model cannot know (commit format, tools, tone, date format and so on) into tasks and ran each 3 times. A model other than me wrote the tasks and the graders, grading is automatic, and I fixed the plan before the runs.

Condition	First run (haiku)	Rerun after fixing a grader bug (haiku)	Sonnet
No Off the Wall	1/33	2/33	2/33
Earlier default (narrow search)	9/33	14/33
Wide search (default since 0.3.0)	17/33	25/33	20/33

When the right correction was shown, the model followed it much more often. When it was not found, nothing changed.
The same held for the larger model (Sonnet): better in 7 tasks, worse in none (hard to put down to chance, p = 0.016). Without Off the Wall the larger model also did not follow these habits.
I fixed the grader after seeing the results, so the rerun is not an independent replication. The higher numbers come partly from the fix and partly from run-to-run variation, and I cannot separate the two.
In 4 of the 11 tasks neither model followed the correction even when it was shown. Pasting 150 rules scored higher overall, but that does not work once the history grows.
I have not measured Opus or the Codex models.

I also checked whether attaching quotes to unrelated requests does harm. I ran 14 tasks that have nothing to do with habits, 3 times each: no Off the Wall 40/42, wide search 41/42. The pass rate did not drop and output tokens rose about 9%. I did not test the protection for input under 20 characters with a model.

I tried several ways to cut the unrelated quotes, and none cleared the bar I had set, so none went in. I wrote that up in a separate post.

I checked the real programs only once each. On Codex 0.162.1 I confirmed install, allowing the hooks, saving a correction and showing it again on the next request. On Claude Code 2.1.311 I confirmed, automatically, saving and showing again in a new session. In the third request of that test the model produced strangely long output for 6 minutes once (it did not appear in 8 reruns).

The code tests are 239 tests passing on Node 18, 20, 22 and 26, all with fake input and fake commands. CI runs on Windows, Linux and macOS with Node 18, 20 and 22.

A command so you can check my numbers

Asking you to trust my numbers is a lot, so I made otw bench: the same kind of test, run with your own claude. It gives a model 11 small tasks that each need a habit it cannot know, once with recall off and once with it on, and counts how often the habit was followed.

bench is currently on repository main, not in the 0.3.1 release or an npm package. Install the Claude Code plugin and sign in, then clone the repository as below. It has not yet been verified in a normal installation. Claude Code may load global instructions and other plugins and save session transcripts.

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs bench
node bin/otw.mjs bench --yes

My first run in my own terminal, using an experimentally modified plugin in an isolated profile: 3/33 (9%) with recall off, 20/33 (61%) with Off the Wall. Model haiku, habits made up for the test. In all 66 runs the plugin block was present exactly when recall was on. One task (c136) passed all 3 times even without recall; I do not know why. It is one run in one environment and yours may differ. If you run it, one line in an issue is plenty. The record is in the repo.

What it cannot do, and what to know

It cannot promise fewer mistakes. It worked on test habits; I have not measured it on real usage records.
It does not understand meaning, so unrelated requests get quotes too, as the screenshot shows. Since 0.3.0 every request of 20 characters or more gets up to 6 (about 300 tokens). Shorter input uses the earlier rule (closeness of 0.18 or more). Put "recallWide": false in the settings to turn this off.
It can save a message that is not a correction, or miss a real one. On one person’s chats, 82% of what it saved was right and it found 72% of the real corrections.
The delete command exists since 0.3.1, but it cannot remove your Claude Code or Codex chats or copies at the model company.
I did not check the screen where you use Claude Code directly. I ran it automatically without a screen and confirmed saving and showing again once, and that is all.
The current version is the 0.3.1 pre-release, not a stable release.

If an unrelated correction showed up or a needed one was missing, please tell me through an issue. It helps a lot, and you do not need to send original text, code or company names. Plans, scripts, data and the weaknesses found by an independent review are in the repository docs.

我为改进 Claude Code 插件试了五种办法,没有一个达到我自己定的标准

Thu, 29 Oct 2026 00:00:00 GMT

本文是韩文原文的简体中文翻译。如有出入,以韩文原文为准。

Dude, Toldya? (working title)

Off the Wall 是 Claude Code 和 Codex 的插件。它保存你给智能体的纠正,之后你让它做类似的事时,会用你当时的原话再显示一遍。这篇文章写的是没做成的事,因为我从那里学到的更多。

先说管用的部分

模型不知道你怎么写提交信息、怎么写日期。我编了 11 个这样的习惯,做成任务,每格 3 次,每个条件跑 33 次,全部无界面自动运行。

Claude Sonnet 没有插件时 33 次中遵守习惯 2 次,有插件时 20 次。
haiku 第一次测试从 1 次到 17 次,重测时从 2 次到 25 次。

这些是我编的习惯,不是真实用户的记录。评分器的错误是在看到结果之后修复的,所以重测也不是独立的复现。Opus 和 Codex 的模型我没有测量过。测试设计见通俗说明文章。

我想解决的问题

这个插件也会把引用附到无关的请求上。在与已存纠正毫无关系的 8 个请求里,平均附上了 1.8 条。我最初写的是”没有相似的就什么都不附”,这是不对的,我已经公开更正。现在的样子如下,这是在虚构仓库里对”写俳句”请求实际运行 otw explain 的输出:

我想在保留有用引用的同时减少这种噪声。运行之前,我先把计划和达标线写进文件,再一个一个试。先说结论:五个都没有通过。

尝试 1. 加词语条件

只在共有 2 个词,或有 1 个稀有词重合时才附上。在有 150 条纠正的库里,无关引用从 6.0 条降到 2.0 条,看起来很不错。但在习惯重复的 240 条库里,是从 6.0 条到 5.5 条,几乎没变。只在一个库里管用的条件没有保留价值,放弃。

尝试 2. 针对短输入的 6 种变体

为了减少附到短输入上的引用,我做了 6 种变体。没有一个达标,保留原有的保护措施(短输入沿用旧规则)。

尝试 3. 嵌入模型

为了看看按含义挑选行不行,我试了一个小型本地嵌入模型(all-MiniLM-L6-v2)。一个设置大幅减少了噪声,但在单独留出的案例上漏掉了太多有用的引用。另外 3 个设置在同一标准上也被淘汰。

尝试 4. 在每条纠正旁边同时显示原始请求

我查看了在纠正旁边同时显示”当时我让它做什么”是否能让模型更好地遵循。只引用 20/33,引用加请求 19/33。没有收益,没有加入。

尝试 5. 把同一条纠正的重复合并

这是来自维基式记忆的想法:把重复合并成一条。18/40 对 20/40,提升 11%,而我的标准是 25%。否决。

之后又试了三种(10 月 30 日补充)

我想,把大型记忆工具的做法搬到 OTW 上,效果会不会更大,所以又测了三种。这次也是在运行之前先定好标准,结果全部没有达标。

**尝试 6. 为重复的纠正再多显示一条。**如果同一条纠正保存了好几次,就在最下面那条无关引用的位置显示它的另一种说法。靠文字相似度只认出了 90 条重复里的 40 条,还丢掉了一个原本能看到目标纠正的任务。

**尝试 7. 让判定模型判断是不是重复。**保存时问判定模型:这条新纠正和之前某条是不是同一个习惯。它正确连上了 90 条重复中的 73 条(73 是上限,因为 5 个候选里有正确答案的只有这么多),但也把 90 条并非重复的纠正连上了 73 条。它分不清”同一个习惯又说了一遍”和”同类的另一条纠正”。

**尝试 8. 改变引用前后的措辞。**我把引用前后的文字换成”长期偏好,适用的就用”和”回答前先对照这些检查”。在 haiku 上 33 次里通过的数量是:现有措辞 21 次,新措辞 22 次和 20 次。没有差别。

单独看没有遵循的任务,原因不是措辞。一个任务里纠正根本没有送到模型(检索失败)。两个任务里纠正显示出来了,但模型似乎把请求明确要求的内容放在了旧习惯之前(我没有逐条读原始输出来确认)。如果是这样,这正是区块里写的”当前请求优先”,所以我不去动它。剩下的就是这两种情况。

到目前为止所有实验和结果,都列在仓库的实验列表里。

除了结果之外学到的

在两个实验里,测试脚本把选择截断在 3 条,默认值是 6 条。我发现后记录下来,原来的数字保持不变。
有一个任务的评分器是错的,我事后重新评分。原来的表格保留,旁边写上更正。
通过我自己做的测试,并不等于对真实用户有帮助。真正的测试是你自己的纠正会不会积累下来,并在合适的时候回来。这方面的证据我还没有。

代码、计划、数据以及所有失败的测试记录,都在仓库 docs 里。如果你的会话里出现了无关的引用,或缺少需要的引用,请通过 issue 告诉我。不必发送原文。

不想再对 Claude Code 重复同样的纠正,所以我做了 Off the Wall

Thu, 29 Oct 2026 00:00:00 GMT

本文是韩文原文的简体中文翻译。如有出入,以韩文原文为准。

Dude, Toldya? (working title)

模型不知道你的习惯,比如提交信息怎么写、日期怎么写。我让 Claude 做了 33 个这样的任务。没有 Off the Wall 时,Claude(Sonnet)遵守了习惯 2 次,有它时遵守了 20 次。原因是你以前的纠正会原样再显示一遍。这些是我编出来的测试习惯,不是真实用户的记录。haiku 模型上是从 1 次到 17 次,重测时从 2 次到 25 次。

使用 haiku 和我为测试编造的习惯验证公开版 0.3.1 时,关闭召回是 2/33,开启召回是 19/33。 这是在单独隔离配置中运行一次的结果,不能代表真实用户的效果。测试记录已公开。

下面是同一个请求不带插件和带插件各运行一次的真实输出,三个任务,展示的是第一次运行的原样结果。已保存的纠正是为这个演示编的,请把它当作示例而不是测量。测量的数字在下面的”我是这样测试的”里。

每开一个新会话,我都在重复同样的话
它是这样工作的
纠正是怎么保存的
用着用着加上的命令
安装
我是这样测试的
做了一个命令,让你自己验证我的数字
它做不到的,以及需要知道的

每开一个新会话,我都在重复同样的话

用 Claude Code 或 Codex 干活,干着干着就会一直重复同样的话。“别问了,选一个。""测试真的跑了吗?""我让你做什么就只做什么。“一换会话,智能体就把这些全忘了。

一开始我把纠正压成一行规则,放进 CLAUDE.md。效果不大。我猜是因为一压缩,这句纠正产生时的情况就丢了:我要求跑哪个测试,说过哪个文件不能动。原话里还留着这些,一行规则里没有。

所以我不再缩短它们,而是做了一个插件,在智能体回答之前把我说过的话原样再显示一遍。名字叫 Off the Wall。它能用在 Claude Code 和 Codex 上,开源(MIT),不需要另外安装软件包,在 Node 18 及以上就能运行。

它是这样工作的

每次发请求时,它会从同一工作文件夹里已存的纠正中,挑出当初针对的请求和新请求看起来相似的最多 6 条,每条截取 200 个字符,加到智能体读到的内容里。屏幕上不会出现卡片,只有智能体收到。还会附一句话,说明这只是供参考的记录,不是新指令,也不是许可。

比如你以前保存过这样一条(这篇文章里的例子全是编的):

不要只跑 lint 就说测试通过。运行结账集成测试,并给我看真实的退出码。

之后你说”用结账集成测试验证支付处理器的改动”。可以用 otw explain 预览会附上什么。下面是在虚构仓库里实际运行的输出:

对的那条以 0.52 排在最前。但往下看,0.04、0.05 的也一起附上了。这是现在的设计,不是 bug。20 个字符以上的请求,不管相似程度如何,都会附上最多 6 条,原因在后面的测试结果里。

无关的请求会怎样?我试了”写一首关于秋天的俳句”。

连俳句也会附上 3 条。这是这个插件最大的弱点,所以我先摆出来。它不理解含义,是按重叠的词和字母对来挑选的。

纠正是怎么保存的

由一个模型单独判断你的下一条消息是不是在纠正上一条回答,是的话就保存。默认开启,用 capture: false 关闭。这个判断用的是你已经在用的 claude 或 codex 命令,所以不需要单独的 API 密钥。判断时用到的那部分对话会发给你所用的模型公司。记录只保存在你自己的电脑(~/.otw)上,不会有数据发给作者。

它不会拖慢回答。判断在单独的进程里进行,你发出的请求不会等它。

它还会检查来源。插件自动发的消息不会被存成你的纠正。没有来源或文件夹的旧记录只保留、不使用。设置文件有错时,功能保持关闭,而不是照常运行。

它只用同一个工作文件夹的记录,不会拿其他项目的纠正,也不会用最近的条目凑数。子文件夹和 git worktree 算不同的项目。

用着用着加上的命令

otw report:让模型从你电脑上已有的 Claude Code 和 Codex 对话里,挑出你想纠正智能体做法的回复,按类别列出,并附上你的原话。加上 --seed 就用这个结果直接开始保存。分类由模型完成,可能有误。
otw status:显示已保存的纠正数、钩子最近运行的时间、你在 Codex 里允许的项目数。也会列出使用的 Codex 模型,以及因为描述里没写明等级而不使用的模型。
otw explain "<句子>":就是上面那个。它不调用模型,也不改变任何东西。只在最新源码(main)里,不在 0.3.1 发布版中。
otw forget --all --yes / --project --yes:删除已保存的纠正、会话记录和日志。不带 --yes 时只显示将被删除的内容。它不能删除你的 Claude Code、Codex 对话,也不能删除已经发给模型公司的内容。

刚安装、什么都还没保存时,otw status 会直接告诉你:

另外还有给辅助智能体的模型建议:搜索、转换用小模型,实现、评审用中等模型,找根因、做设计用大模型;没有指定模型的辅助调用会被退回一次。它不强制模型,也不保证降低成本。

安装

在 Claude Code 里:

/plugin install off-the-wall --marketplace toranalytics/off-the-wall

在 Codex 里,之后要打开一次 /hooks 并允许钩子。允许之前什么都不会发生。

codex plugin marketplace add toranalytics/off-the-wall
codex plugin add off-the-wall@off-the-wall

想在安装前看 report 是什么样,可以用仓库里的虚构对话记录运行:

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs report --host claude --claude-dir examples/claude-history --days 0

想先在浏览器里看,有一个再显示纠正的演示(界面是韩文)。无需安装或登录,所有输入都是编造的案例。源码在 GitHub。

我是这样测试的

全部用编造的记录测量。我在没有界面的情况下自动运行 Claude Code 2.1.311,用了一个小模型(haiku)和一个较大的模型(Sonnet)。这些数字只适用于这些测试,并不说明真实使用中的效果。

我把模型无从得知的 11 个习惯(提交格式、使用的工具、语气、日期格式等)做成任务,每个运行 3 次。任务和评分器由我之外的另一个模型编写,评分自动进行,计划在运行前就定好了。

条件	第一次(haiku)	修复评分器错误后重测(haiku)	Sonnet
没有 Off the Wall	1/33	2/33	2/33
原默认(窄检索)	9/33	14/33
宽检索(0.3.0 起默认)	17/33	25/33	20/33

正确的纠正显示出来时,模型遵循的频率高得多。找不到时则没有变化。
较大的模型(Sonnet)上也一样:按任务看更好的 7 个、更差的 0 个(很难说是偶然,p = 0.016)。没有 Off the Wall 时,较大的模型同样没有遵循这些习惯。
评分器是在看到结果之后修复的,所以重测不是独立的复现。数字变高一部分来自修复,一部分来自每次运行的波动,我无法把两者分开。
11 个任务中有 4 个,两个模型即使看到了纠正也没有遵循。直接塞入 150 条规则总体得分更高,但历史变长之后这种做法就行不通。
Opus 和 Codex 的模型我没有测量过。

我还检查了附到无关请求上有没有害处。我用 14 个与习惯无关的任务各运行 3 次:没有 Off the Wall 40/42,宽检索 41/42。通过率没有下降,输出 token 增加约 9%。短于 20 个字符的输入的保护措施,我没有用模型测试过。

我试过好几种减少无关引用的办法,没有一个达到我自己定的标准,所以都没有加入。这些我写在了另一篇文章里。

在真实程序里,我每个只确认了一次。在 Codex 0.162.1 上,确认了安装、允许钩子、保存纠正以及下一次请求时再显示。在 Claude Code 2.1.311 上,自动运行确认了保存以及在新会话里再显示。同一次测试的第三个请求中,模型有一次连续 6 分钟输出异常冗长的内容(8 次重测中没有出现)。

代码测试是 239 个测试在 Node 18、20、22、26 上通过,全部使用假输入和假命令。CI 在 Windows、Linux、macOS 的 Node 18、20、22 上运行。

做了一个命令,让你自己验证我的数字

让你直接信我的数字不太合适,所以我做了 otw bench:同样的测试,用你自己的 claude 来跑。它给模型 11 个小任务,每个都需要模型无从得知的习惯,先关闭回忆跑一次,再开启跑一次,数一数习惯被遵守了几次。

bench 目前只在仓库 main 分支,不在 0.3.1 发布版或 npm 包中。先安装 Claude Code 插件并登录,然后按下方命令克隆仓库运行。普通安装环境尚未验证。Claude Code 可能读取全局指令和其他插件,并保存会话记录。

git clone https://github.com/toranalytics/off-the-wall && cd off-the-wall
node bin/otw.mjs bench
node bin/otw.mjs bench --yes

我在自己终端里第一次跑的结果(隔离配置和实验性修改插件):关闭回忆 3/33(9%),有 Off the Wall 20/33(61%)。模型是 haiku,习惯是为测试编的。66 次里,插件块出现的情况和开启回忆的情况完全一致。有一个任务(c136)即使不回忆也 3 次全过,原因尚不清楚。这只是一个环境里的一次运行,你的结果可能不同。如果你跑了,在 issue 里写一行就足够了。记录在仓库里。

它做不到的,以及需要知道的

不能保证减少失误。在测试用的习惯上有效,在真实使用记录上我没有测量过。
它不理解含义,所以无关的请求也会被附上,截图里能看到。从 0.3.0 起,20 个字符以上的请求都会附上最多 6 条(约 300 个 token)。更短的输入沿用之前的规则(相近程度 0.18 以上)。要关闭,在设置里加入 "recallWide": false。
可能把不是纠正的话存下来,也可能漏掉真正的纠正。在一个人的对话上,保存的内容里 82% 是对的,真正的纠正中找到了 72%。
删除命令从 0.3.1 起有了,但它不能删除 Claude Code、Codex 的对话,也不能删除模型公司那里留下的副本。
我没有在直接使用 Claude Code 的界面上确认过。只是在没有界面的情况下自动运行,确认过一次保存和再显示,仅此而已。
当前版本是 0.3.1 预发布版,不是正式版。

如果出现了无关的纠正,或缺了需要的纠正,请通过 issue 告诉我,帮助很大。不必发送原文、代码或公司名称。计划、脚本、数据以及独立评审中发现的弱点,都在仓库 docs 中。

My coding agent cost $1,064 last week. 44% of it was the cache re-writing itself

Mon, 19 Oct 2026 00:00:00 GMT

Scope note, 2026-10-23: the figures below are historical API-price estimates from a separate local setup, not an invoice or a measured saving from public Off the Wall. This post does not test OTW correction recall.

I run coding agents all day, so I added up a week of my own API usage: 19,733 Claude calls, about $1,064 at API prices. The biggest line was not output and not cache reads. It was cache writes: $469, 44% of the bill.

A cache write is what you pay the first time a prefix is seen. In a long conversation almost everything should be a read. A write that large means the agent kept paying for conversations it had already paid for.

Leak 1: a note that “preserves the cache”

The agent runs with a context plugin that adds a short note (routing hints, memory) to each prompt. It added that note after the last message of the request, and the code comment said this placement preserves the prompt cache.

With automatic caching the cache breakpoint is the end of the request, so the entry was written right at the note. The next prompt no longer carries that note, so nothing it sends matches what was cached, and the whole conversation is written again.

Three one-word prompts in one session:

	cache read	cache write
prompt 1	0	35,050
prompt 2	0	34,908
prompt 3	0	34,922

The note stored once in the conversation history instead, same three prompts:

	cache read	cache write
prompt 1	0	35,045
prompt 2	35,045	320
prompt 3	35,365	14

In a week of real use this was the largest single cause of full rewrites in my logs: 355 of them.

Leak 2: no breakpoint on the system prompt

Every new session in a project sends the same tools and system prompt, about 30k tokens. With one breakpoint at the end of the request, a new session has nothing to read: its messages differ from every earlier session, so the shared part has no cache entry of its own. Two fresh sessions a minute apart each wrote ~35k and read 0.

One more breakpoint on the last system block (the API allows four):

second fresh session, first request	cache read	cache write
before	0	~35,000
after	33,460	~1,600

Restarts, new sessions and subagents all start from that prefix, so the saving repeats for each.

What I take from it

Both leaks were placed where they were to protect the cache, and both comments were reasonable. Neither had been measured. The usage estimates were the measurement.

I also build Off the Wall, which recalls past corrections. That is a separate project from this cache-layer investigation.

What correction quotes preserve, and what a replay does not prove

Mon, 19 Oct 2026 00:00:00 GMT

Dude, Toldya? (working title)

In plain words: this is about an older test where I replayed 39 real requests as text. I compared showing my own past corrections with short rules. It is not proof that the plugin works in real use. A later test is easier to read: with made-up personal habits, Claude (Sonnet) followed the habit 2 times out of 33 without Off the Wall and 20 times with it. That one is in the plain-language post.

Updated 2026-10-28: the later measurement on personal preferences (followed 1/33 with no recall, 9/33 default, 17/33 with wide recall; synthetic tasks) is in the Off the Wall post. Wide recall has been the default since 0.3.0. The replay below is unchanged.

Updated 2026-10-23: I split what a historical replay shows from what the public plugin actually demonstrates. It does not establish that quotes beat rules in general.

A correction carries details that a short rule drops: which test was missing, which files were outside the task, which decision I had already handed to the agent. That was the design question behind Off the Wall.

Open the synthetic recall demo before connecting any personal history. The interface is in Korean. The embedded JSON shows the synthetic prompts, the selected quotes, the source version and the real hook output.

A quote is a mechanism, not an outcome
What the old replay said
What the demo also gets wrong
Privacy and model-selection hints
Look at the mechanism first

A quote is a mechanism, not an outcome

Here is a made-up example. The correction says: run the checkout integration test and show its exit code, don’t claim success after lint. Later I send a related request, and that exact correction lands in its prompt context.

The demo runs the unmodified CLI hook from public OTW 0.1.1, commit 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc. Four synthetic requests, empty and seeded stores, both host modes: 16 isolated hook runs. No private history, no correction judge, no model answer and no live Claude Code or Codex session was involved. I seeded the stored corrections myself.

So it verifies how the context is assembled, and that a future-dated fixture is left out. It does not verify that the model follows the quote, that a real task succeeds, or that I repeat fewer corrections.

What the old replay said

I picked 39 requests from one person’s history (mine), limited to corrections that could be graded from text. Opus 5.5 re-answered them without tools. Sonnet compared pairs in both orders, and a win counted only when both orders agreed.

The condition with past quotes plus a line asking the model to predict my objection came out at 25 wins, 11 ties and 3 losses against adding nothing. Against random distilled lessons it was 17 wins, 14 ties and 8 losses, with a reported two-sided p of about 0.11. That is not solid evidence of an advantage. The quote format and the prediction line were one combined treatment, so this was never a test of verbatim wording alone.

The saved execution logs back up the totals and the conditions. I have not rerun the original per-case outputs independently. One user, selected requests, model grading and text-only tasks limit what this says. Neither these numbers nor a model’s guess about what would have happened is a measured prevention rate.

My hypothesis is that keeping the details of a correction may help in a later, relevant situation. It is still a hypothesis about behavior. It is not a finding that rules don’t work.

What the demo also gets wrong

The check fixture pulls in an instruction from a different task, “edit only the login file”. A completely unrelated request still gets the latest corrections. Retrieval is word and character-bigram TF-IDF over earlier requests, then recent items. It does not work out task scope.

The context block also quotes the correction without the scope of the original request, so a phrase like “this task” can lose what it pointed to. That is a limitation I demonstrated in selection and context. I did not observe the model going wrong because of it.

Separating standing preferences from one-off task limits, showing where a quote came from, and handling unrelated recent corrections are improvements I have in mind, not shipped features. One boundary fix did ship in 0.2.0: origin tags and working-directory-scoped recall, because automatic plugin messages could otherwise end up in the correction analysis. It is not proven to filter all automatic input.

Privacy and model-selection hints

Results and state are stored locally, by default in ~/.otw. Judging, and reports on personal history, send excerpts through your Claude or Codex CLI to the model company. No separate API key does not mean no usage, cost, limits or handling on the provider side.

The plugin also gives the orchestrator hints about which model to use. That is not automatic routing and not a cost-saving guarantee, and I have not measured the Codex model mapping.

Look at the mechanism first

Start with the synthetic demo, not with your own history or a seed command. I don’t recommend report --seed on personal history yet: the input-boundary fix is public but has not been checked in real use.

What helps me most is something concrete: a needed quote was missing, an unrelated quote showed up, or the agent made the same mistake even after seeing the quote. Open an issue without private transcripts, code, company names or credentials. Install steps are in the current README.

교정 원문이 보존하는 것, 재생 실험이 증명하지 못하는 것

Mon, 19 Oct 2026 00:00:00 GMT

AI한테 같은 말을 또 하게 돼서, 이름과 캐릭터를 다시 고민했다

쉽게 말하면, 이 글은 실제 요청 39개를 글로만 다시 돌려 본 오래된 시험 이야기다. 내 과거 교정을 보여 주는 방식과 짧은 규칙을 비교했고, 실제 사용에서 플러그인이 잘 동작한다는 증거는 아니다. 이후에 한 시험이 더 읽기 쉽다. 시험용으로 만든 개인 습관에서 Claude(Sonnet)는 Off the Wall이 없으면 33번 중 2번, 있으면 20번 따랐다. 쉬운 설명 글에 있다.

2026-10-28 업데이트. 개인 선호에 대한 이후 측정(회수 없음 1/33, 기존 기본 9/33, 넓게 찾기 17/33, 합성 작업)은 Off the Wall 글에 있다. 넓게 찾기는 0.3.0부터 기본값이다. 아래 재생 실험은 그대로다.

2026-10-23 업데이트. 과거 재생 실험이 보여 주는 것과 공개 플러그인이 실제로 보여 주는 것을 나눠서 적었다. 원문 인용이 규칙보다 낫다는 일반적인 결론은 아니다.

교정에는 짧은 규칙이 버리는 세부가 들어 있다. 어떤 테스트가 빠졌는지, 어떤 파일이 작업 범위 밖이었는지, 어떤 결정을 이미 에이전트에게 맡겼는지 같은 것들이다. Off the Wall의 설계 질문이 이거였다.

합성 원문 회수 데모 열기 개인 기록을 연결하기 전에 먼저 보면 좋겠다. 화면에 들어 있는 JSON에 합성 프롬프트, 선택된 인용, 소스 버전, 실제 훅 출력이 나와 있다.

인용은 결과가 아니라 장치다
예전 재생 실험은 뭐라고 했나
데모가 틀리는 부분
개인정보와 모델 선택 안내
장치부터 보자

인용은 결과가 아니라 장치다

지어낸 예시다. 교정은 “체크아웃 통합 테스트를 실행하고 종료 코드를 보여줘, 린트만 돌리고 성공이라고 하지 마”다. 나중에 관련 있는 요청을 보내면 그 교정 원문이 그대로 프롬프트 컨텍스트에 들어온다.

데모는 공개 OTW 0.1.1(커밋 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc)의 CLI 훅을 수정 없이 돌린다. 합성 요청 4개, 빈 저장소와 채운 저장소, 두 호스트 모드로 격리된 훅 실행이 16번이다. 개인 기록, 교정 판정, 모델 답변, 실제 Claude Code나 Codex 세션은 쓰지 않았다. 저장된 교정은 내가 직접 넣었다.

그래서 이 데모가 확인하는 건 컨텍스트가 어떻게 조립되는지, 미래 시점의 fixture가 빠지는지다. 모델이 인용을 따르는지, 실제 작업이 성공하는지, 내가 교정을 덜 반복하는지는 확인하지 못한다.

예전 재생 실험은 뭐라고 했나

한 사람(나)의 기록에서 요청 39개를 골랐고, 글만으로 채점할 수 있는 교정으로 한정했다. Opus 5.5가 도구 없이 다시 답했고, Sonnet이 쌍을 순서를 바꿔 두 번 비교했다. 두 순서가 일치할 때만 승리로 셌다.

과거 인용에 “이 사람이 뭐라고 지적할지 예측하라”는 문장을 붙인 조건은 아무것도 안 붙인 조건 대비 25승 11무 3패였다. 무작위로 요약한 규칙과 직접 비교하면 17승 14무 8패였고, 보고된 양측 검정 p는 약 0.11이다. 확실한 우위의 근거가 아니다. 인용 형식과 예측 문장을 한 묶음으로 시험했으니 원문 표현만의 효과를 본 것도 아니다.

보존된 실행 로그로 집계와 조건은 확인했다. 원본 case별 산출물을 독립적으로 다시 돌린 건 아니다. 사용자 한 명, 골라낸 요청, 모델 채점, 글만 쓰는 작업이라는 한계가 있다. 이 숫자도, 모델이 “그랬다면 어땠을지” 판단한 것도 측정한 예방률이 아니다.

내 가설은 교정의 세부를 남겨 두면 나중에 관련 있는 상황에서 도움이 될 수 있다는 것이다. 여전히 행동에 대한 가설이다. 규칙이 효과가 없다는 발견이 아니다.

데모가 틀리는 부분

확인용 fixture는 다른 작업의 지시(“로그인 파일만 고쳐라”)까지 끌어온다. 전혀 관련 없는 요청에도 최근 교정이 들어간다. 검색은 이전 요청에 대한 단어와 글자 bigram TF-IDF를 쓰고 그다음 최근 항목으로 채운다. 작업 범위는 판단하지 못한다.

컨텍스트 블록은 원래 요청의 범위 정보 없이 교정만 인용한다. “이번 작업”이라는 말이 무엇을 가리켰는지 잃을 수 있다. 선택과 컨텍스트의 한계를 보여 준 것이고, 모델이 이 때문에 실제로 틀렸다는 걸 본 건 아니다.

지속적인 선호와 일회성 작업 지시를 나누기, 인용의 출처 보여 주기, 관련 없는 최근 교정 처리는 생각해 둔 개선이지 이미 나온 기능이 아니다. 입력 경계 수정은 0.2.0에 나갔다. 출처 태그와 작업 디렉터리 기준 회수인데, 플러그인이 자동으로 보낸 메시지가 교정 분석에 들어갈 수 있었기 때문이다. 자동 입력을 전부 걸러낸다고 증명된 건 아니다.

개인정보와 모델 선택 안내

결과와 상태는 기본으로 로컬 ~/.otw에 저장된다. 판정과 개인 기록 리포트는 내가 쓰는 Claude나 Codex CLI를 통해 발췌문을 모델 회사로 보낸다. 별도 API 키가 없다고 사용량, 비용, 한도, 제공자 쪽 처리가 없는 건 아니다.

플러그인은 오케스트레이터에게 쓸 모델을 안내하기도 한다. 자동 라우팅도 비용 절감 보장도 아니고, Codex 모델 매핑은 재 보지 않았다.

장치부터 보자

내 기록을 올리거나 seed 명령을 돌리기 전에 합성 데모부터 보면 좋겠다. 개인 기록에 report --seed를 돌리는 건 아직 권하지 않는다. 입력 경계 수정은 공개됐지만 실제 사용으로 확인하지 못했다.

가장 도움이 되는 건 구체적인 제보다. 필요한 인용이 빠졌다, 관련 없는 인용이 나왔다, 인용을 보고도 에이전트가 같은 실수를 했다. 개인 대화 기록, 코드, 회사 이름, 인증 정보 없이 이슈로 알려 주면 된다. 설치 방법은 현재 README에 있다.

我的编码智能体上周花了 $1,064,其中 44% 是缓存在反复重写自己

Mon, 19 Oct 2026 00:00:00 GMT

本文是英文原文的简体中文翻译。如有出入,以英文原文为准。

范围说明,2026-10-23:下面的数字是另一套本地环境、按 API 价格做的历史估算,不是账单,也不是公开版 Off the Wall 测得的节省。本文没有测试 OTW 的纠正回溯。

我整天都在运行编码智能体,所以我把自己一周的 API 用量加了起来:19,733 次 Claude 调用,按 API 价格约 $1,064。最大的一项既不是输出,也不是缓存读取,而是缓存写入:$469,占账单的 44%。

缓存写入,是某个前缀第一次被看到时要付的钱。在长对话中,几乎全部都应该是读取。写入这么大,意味着智能体一直在为已经付过钱的对话重复付费。

泄漏 1:一条”保护缓存”的备注

这个智能体搭配了一个上下文插件,它会给每个提示词加一小段备注(路由提示、记忆)。它把这段备注加在请求最后一条消息之后,代码注释说这个位置能保护提示词缓存。

在自动缓存下,缓存断点就是请求的末尾,所以缓存条目恰好写在这段备注处。下一个提示词不再带这段备注,于是它发送的内容没有任何部分与已缓存的内容吻合,整段对话又被重新写入。

同一会话中的三个一个词的提示词:

	缓存读取	缓存写入
提示词 1	0	35,050
提示词 2	0	34,908
提示词 3	0	34,922

把备注改为只在对话历史中存一次,同样的三个提示词:

	缓存读取	缓存写入
提示词 1	0	35,045
提示词 2	35,045	320
提示词 3	35,365	14

在一周的真实使用中,这是我的日志里导致整段重写的最大单一原因:355 次。

泄漏 2:系统提示词上没有断点

项目里每开一个新会话,都会发送相同的工具和系统提示词,约 3 万个 token。如果请求末尾只有一个断点,新会话就没有可读的内容:它的消息与之前任何会话都不同,所以共享的部分没有自己的缓存条目。间隔一分钟新开的两个会话,各自写入约 35k,读取 0。

在最后一个系统块上再加一个断点(API 允许 4 个):

第二个新会话的第一次请求	缓存读取	缓存写入
之前	0	约 35,000
之后	33,460	约 1,600

重启、新会话和子智能体都从这个前缀开始,所以这份节省每次都会重复出现。

我从中得到的

两处泄漏,都是为了保护缓存才放在那个位置的,注释也都说得过去。两者都没有被测量过。用量估算就是测量。

我也在做 Off the Wall,它会回溯过去的纠正。那是一个与这次缓存层调查无关的独立项目。

지난주 코딩 에이전트 비용이 $1,064였습니다. 그중 44%는 캐시가 스스로를 다시 쓴 비용이었습니다

Mon, 19 Oct 2026 00:00:00 GMT

영어 원문의 한국어 번역입니다. 내용이 다르면 영어 원문이 기준입니다.

범위 메모, 2026-10-23: 아래 수치는 별도의 로컬 환경에서 낸 과거 API 가격 기준 추정치이고, 청구서나 공개 Off the Wall로 측정한 절감이 아닙니다. 이 글은 OTW의 교정 회수를 시험하지 않습니다.

저는 하루 종일 코딩 에이전트를 돌려서, 제 API 사용량을 일주일치 합산해 봤습니다. Claude 호출 19,733건, API 가격 기준 약 $1,064였습니다. 가장 큰 항목은 출력도 캐시 읽기도 아니고 캐시 쓰기였습니다. $469로 청구액의 44%였습니다.

캐시 쓰기는 어떤 접두부를 처음 볼 때 내는 비용입니다. 긴 대화에서는 거의 전부가 읽기여야 합니다. 쓰기가 이렇게 크다는 것은 에이전트가 이미 값을 치른 대화에 계속 돈을 냈다는 뜻입니다.

누수 1: “캐시를 보존한다”는 메모

에이전트는 프롬프트마다 짧은 메모(라우팅 힌트, 기억)를 덧붙이는 컨텍스트 플러그인과 함께 돌아갑니다. 이 플러그인은 메모를 요청의 마지막 메시지 뒤에 붙였고, 코드 주석에는 이 위치가 프롬프트 캐시를 보존한다고 적혀 있었습니다.

자동 캐싱에서는 캐시 브레이크포인트가 요청의 끝이라서, 항목이 정확히 메모 위치에 써졌습니다. 다음 프롬프트에는 그 메모가 붙지 않으므로, 보내는 내용 어느 것도 캐시된 것과 맞지 않고 대화 전체가 다시 써집니다.

한 세션에서 한 단어짜리 프롬프트 세 개를 보냈을 때입니다.

	캐시 읽기	캐시 쓰기
프롬프트 1	0	35,050
프롬프트 2	0	34,908
프롬프트 3	0	34,922

같은 세 프롬프트에서 메모를 대화 기록 안에 한 번만 저장하게 바꾸면 이렇게 됩니다.

	캐시 읽기	캐시 쓰기
프롬프트 1	0	35,045
프롬프트 2	35,045	320
프롬프트 3	35,365	14

일주일 실사용 기록에서 이것이 전체를 다시 쓰는 단일 원인으로는 가장 컸고, 355건이었습니다.

누수 2: 시스템 프롬프트에 브레이크포인트가 없음

프로젝트에서 새 세션을 열 때마다 같은 도구와 시스템 프롬프트(약 3만 토큰)를 보냅니다. 요청 끝에 브레이크포인트가 하나뿐이면 새 세션은 읽을 것이 없습니다. 메시지가 이전의 어떤 세션과도 다르므로, 공통 부분에는 따로 캐시 항목이 없습니다. 1분 간격으로 새로 연 두 세션이 각각 약 35k를 쓰고 0을 읽었습니다.

마지막 시스템 블록에 브레이크포인트를 하나 더 두었습니다(API는 4개까지 허용합니다).

두 번째 새 세션의 첫 요청	캐시 읽기	캐시 쓰기
변경 전	0	약 35,000
변경 후	33,460	약 1,600

재시작, 새 세션, 서브에이전트 모두 이 접두부에서 시작하므로 절감은 매번 반복됩니다.

여기서 얻은 것

두 누수 모두 캐시를 보호하려고 그 자리에 놓인 것이었고, 주석도 합리적이었습니다. 어느 쪽도 측정된 적은 없었습니다. 사용량 추정치가 측정이었습니다.

저는 과거 교정을 회수하는 Off the Wall도 만듭니다. 이것은 이 캐시 계층 조사와는 별개의 프로젝트입니다.

纠正原文保留了什么,重放实验又没能证明什么

Mon, 19 Oct 2026 00:00:00 GMT

Dude, Toldya? (working title)

通俗地说,这篇讲的是一个较早的测试:我把 39 个真实请求只以文字重放,比较了显示我自己过去的纠正和简短规则两种做法。它并不能证明插件在真实使用中有效。之后的测试更容易看懂:用编造的个人习惯,Claude(Sonnet)在没有 Off the Wall 时 33 次中遵守了 2 次,有它时遵守了 20 次。见通俗说明文章。

2026-10-28 更新:之后对个人偏好的测量(没有回忆 1/33,原默认 9/33,宽检索 17/33,合成任务)在 Off the Wall 文章里。宽检索从 0.3.0 起是默认。下面的重放没有改动。

2026-10-23 更新:我把历史重放显示的内容和公开插件实际证明的内容分开写了。它不能说明引用原文总体上优于规则。

纠正里带着简短规则会丢掉的细节:缺的是哪个测试,哪些文件在任务范围之外,哪个决定我已经交给了智能体。这就是 Off the Wall 背后的设计问题。

打开合成回忆演示 建议在连接任何个人记录之前先看。界面是韩文。页面里的 JSON 显示合成提示、被选中的引用、源码版本和真实的钩子输出。

引用是一种机制,不是一个结果
早先的重放说了什么
演示还做错了什么
隐私与模型选择建议
先看机制

引用是一种机制,不是一个结果

这是编的例子。纠正是:运行结账集成测试并显示退出码,不要跑完 lint 就说成功。之后我发一个相关的请求,那条纠正会原样进入它的提示上下文。

演示不加修改地运行公开 OTW 0.1.1(提交 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc)的命令行钩子。4 个合成请求、空库和已存库、两种宿主模式,共 16 次隔离的钩子运行。没有用到个人记录、纠正判定、模型回答,也没有真实的 Claude Code 或 Codex 会话。存入的纠正是我自己放进去的。

所以它验证的是上下文怎么组装,以及带有未来时间的测试数据会被排除。它没有验证模型是否遵循引用、真实任务是否成功,也没有验证我是否少重复了纠正。

早先的重放说了什么

我从一个人(我自己)的记录里挑了 39 个请求,限定为只靠文字就能评分的纠正。Opus 5.5 不用工具重新回答,Sonnet 把两两答案按两种顺序比较,只有两种顺序一致才算赢。

在过去引用之外再加一句”预测这个人会提出什么异议”的条件,对比什么都不加是 25 胜 11 平 3 负。和随机提炼的规则直接对比是 17 胜 14 平 8 负,报告的双侧检验 p 约为 0.11。这不是确定优势的证据。引用格式和预测句是一起测试的,所以这从来不是只针对逐字原文的测试。

保存下来的运行日志能印证总数和条件。我没有独立重跑原始的逐案输出。一个用户、挑选过的请求、模型评分、只写文字的任务,这些都限制了结论。这些数字,以及模型对”如果当时会怎样”的判断,都不是测出来的预防率。

我的假设是:保留纠正的细节,可能在之后相关的情形里有帮助。这仍然只是关于行为的假设,不是”规则没有效果”的发现。

演示还做错了什么

检查用的测试数据会把另一个任务的指令(“只改登录文件”)也拉进来。完全无关的请求也会收到最近的纠正。检索用的是对之前请求做的词与字符 bigram TF-IDF,再补上最近的条目,并不判断任务范围。

上下文块引用纠正时也没带原始请求的范围信息,所以”这次任务”这样的话可能失去所指。这是我展示出来的选择与上下文方面的局限,我并没有观察到模型因此真的出错。

把长期偏好和一次性任务限制分开、显示引用来源、处理无关的最近纠正,这些是我想做的改进,不是已经发布的功能。有一项边界修复已在 0.2.0 发布:来源标记和按工作目录限定的回忆,因为插件自动发送的消息原本可能进入纠正分析。它并没有被证明能过滤所有自动输入。

隐私与模型选择建议

结果和状态默认保存在本地 ~/.otw。判定以及个人记录报告会通过你的 Claude 或 Codex 命令行把摘录发给模型公司。没有单独的 API 密钥,不等于没有用量、费用、额度和提供方一侧的处理。

插件还会给编排智能体一些该用哪个模型的建议。这不是自动路由,也不是降低成本的保证,Codex 的模型对应关系我也没有测过。

先看机制

先看合成演示,不要先上传自己的记录或运行 seed 命令。我暂时不建议对个人记录运行 report --seed:输入边界修复已经公开,但还没有在真实使用中验证。

对我最有帮助的是具体的反馈:缺了需要的引用、出现了无关的引用、看到引用后智能体仍然犯了同样的错。请通过 issue 告诉我,不要附上私人对话记录、代码、公司名称或凭据。安装方法见当前 README。

Off the Wall: 과거의 정정이 새 요청 앞에 돌아오는 순간

Fri, 16 Oct 2026 00:00:00 GMT

AI한테 같은 말을 또 하게 돼서, 이름과 캐릭터를 다시 고민했다

쉽게 말하면, Off the Wall은 내가 전에 한 지적을 줄이지 않고 그대로, 에이전트가 답하기 전에 다시 보여 주는 플러그인이다. 모델이 모르는 내 습관을 33번 시켰을 때 없으면 2번, 있으면 20번 따랐다(Claude Sonnet, 시험용으로 만든 습관). 뭘 하고 뭘 못 하는지는 쉬운 설명 글에 따로 정리했다. 이 글은 그 전에 쓴 자세한 측정 기록이다.

업데이트 이력. 10월 29일에 큰 모델(Sonnet)에서도 같은 효과를 확인했고, 저장된 지적을 지우는 otw forget이 0.3.1에 들어갔다. 10월 28일에는 모델이 모르는 개인 선호에서 효과를 처음으로 쟀다(아래 7장). 10월 27일에는 입력 경계 수정이 0.2.0에 공개됐고 Codex 실제 호스트에서 한 번 돌려 본 기록을 추가했다. 10월 23일에는 과거 실험이 어디까지 말해 주는지 정리했다. 최신 숫자와 한계는 쉬운 설명 글에 있다.

코딩 에이전트를 고칠 때 중요한 건 “다음부터 잘해”라는 규칙만이 아니었다. 어떤 요청에서 무엇을 어떻게 고쳐 달랬는지가 다음 작업 앞에도 남아 있어야 했다.

Off the Wall은 Claude Code와 Codex에 저장된 과거 정정 원문을 다음 요청의 컨텍스트로 인용하는 초기 플러그인이다. 더 나은 답변이나 비용 절감을 보장하는 도구는 아니다.

개인 기록 없이 원문 회수 데모 보기

데모는 설치나 로그인 없이 열린다. 입력은 전부 내가 만든 사례이고, 공개 훅이 실제로 돌려준 컨텍스트와 빈 저장소의 차이를 보여 준다. 좋아진 모델 답변을 꾸민 전후 비교가 아니다.

1. 원문이 돌아오는 순간
2. 실제로 확인한 범위
- 2-1. 실제 Codex에서 한 번 돌려 본 기록 (10월 27일 추가)
3. 지금 공개판이 하는 일
4. 원문만 보존해서는 부족하다
5. 과거 실험은 어디까지 말해 주나
6. 데이터와 비용
7. 10월 28일 측정: 모델이 모르던 내 습관을 따르나
8. 써 보기 전에

1. 원문이 돌아오는 순간

아래는 개인 대화에서 가져온 게 아니라 데모용으로 지어낸 사례다.

린트만 돌리고 “테스트 통과”라고 하지 마. 체크아웃 통합 테스트를 실행하고 실제 종료 코드를 보여줘.

나중에 “결제 핸들러 변경을 체크아웃 통합 테스트로 검증해줘”라는 새 요청을 보낸다. “검증을 잘하라”는 일반 문구 대신, 어떤 테스트와 어떤 증거를 요구했는지가 원문으로 컨텍스트에 돌아온다.

합성 입력을 격리해서 돌린 화면이다. 모델의 다음 답변은 실행하지 않았다. 다른 작업의 범위 지적도 같이 섞이는 한계가 있는데, 4장에서 얘기한다.

데모에는 작업 범위를 지키는 사례, 선택을 맡겼을 때 다시 묻지 않는 사례, 무관한 요청에도 최근 교정이 들어오는 한계 사례가 있다. 핵심 세 사례의 정정은 최근 6개보다 오래된 항목이다.

2. 실제로 확인한 범위

공개 OTW 0.1.1의 고정 커밋 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc를 수정하지 않고 실행했다.

합성 요청 4개 × 빈/저장 상태 × Claude/Codex 훅 모드, 합쳐서 CLI 훅 실행 16회.
저장된 교정과 요청은 내가 직접 만든 fixture다. 자동 판정이나 과거 기록에서의 추출을 검증한 게 아니다.
관련 있고 최근인 교정이 선택돼 additionalContext에 들어가는지, 미래 시점의 교정이 빠지는지 봤다.
개인 기록, 모델 제공자, 실제 Claude Code/Codex 세션은 쓰지 않았다.

회수됨, 모델이 따름, 실제 작업이 성공함, 사용자가 덜 고침은 서로 다른 단계다. 이 재현은 첫 번째까지만 확인했다.

2-1. 실제 Codex에서 한 번 돌려 본 기록 (10월 27일 추가)

위 재현은 호스트 없이 훅만 돌린 거였다. 그래서 macOS의 실제 Codex(codex-cli 0.162.1)에서 플러그인 0.2.0을 격리된 홈 디렉터리와 합성 프롬프트로 한 번 돌렸다. 플러그인 설치, 훅 신뢰, 한 턴의 교정 저장, 다음 턴에 그 교정이 개발자 메시지로 주입되는 것, 번들 예시 기록에 대한 otw report(답변 20개 중 9개 분류)를 확인했다. 기록은 저장소 docs에 있다.

훅은 신뢰하기 전에는 돌지 않는다. 설치만 하면 조용히 아무 일도 안 일어난다. /hooks에서 신뢰해야 하고, 0.2.1부터 otw status가 최근 훅 활동과 신뢰된 항목 수를 보여 준다.
한 대의 컴퓨터에서 한 번 돌린 것이다. 모델이 회수된 교정을 따랐는지는 보지 않았다.
Claude Code는 대화형으로 돌려 보지 못했다. 처음에는 로그인된 Claude Code가 없어서 못 했고, 나중에 Claude Code 2.1.311의 헤드리스 모드에서 플러그인 0.2.1로 교정 저장과 새 세션의 회수를 한 번 확인했다. 다만 같은 시험의 셋째 턴에서 모델이 6분 동안 비정상적으로 긴 출력을 낸 적이 한 번 있었고(8회 재시험에서는 재현되지 않았다), 대화형 사용은 확인하지 못했다. 기록은 저장소 docs에 있다.

3. 지금 공개판이 하는 일

처음 공개했을 때는 저장된 교정 중 과거 요청과 문자열 특징이 비슷한 최대 3개를 먼저 고르고 최근 항목으로 채워서 최대 6개를 인용했다. 0.3.0부터는 recallWide가 기본으로 켜져 있어서, 20자 이상 요청에는 비슷한 정도 순으로 최대 6개를 붙이고 겹치는 게 전혀 없는 건 뺀다. 검색은 단어와 글자 2개 단위(bigram) 기반 TF-IDF라서, 뜻을 이해하거나 적용 범위를 정확히 판단한다고 보장하지 않는다.

판정 기능을 켜면 직전 답변과 새 메시지를 별도 프로세스에서 검토해 교정 후보를 저장한다. report는 기존 대화 기록에서 교정을 분류하는 선택 진단 기능이다. 모델 선택 안내도 들어 있지만 자동 최적화나 일반적인 비용 절감이라고 소개하지 않는다.

인용 블록은 대화창에 카드로 뜨는 게 아니라 모델에게 전달되는 추가 컨텍스트다. 이 글의 데모는 그 숨은 입력을 들여다보는 별도의 검사 화면이다.

4. 원문만 보존해서는 부족하다

데모의 결제 테스트 요청에는 “로그인 파일만 고쳐라” 같은 다른 작업의 일회성 범위 교정도 같이 뽑혔다. 무관한 화성 질문에서도 최근 교정 6개가 들어왔다.

핵심 문장이 들어왔다고 선택 전체가 적절하다고 할 수는 없다. 원문의 “이번 요청”이 과거 작업을 가리키는지, 지금도 유지해야 할 선호인지 구분해야 한다. 모델이 이 때문에 실제로 잘못 행동했다는 결과는 아직 재 보지 않았다.

다음에 검토할 과제는 지속적인 선호와 일회성 작업 지시의 구분, 원래 요청·프로젝트·적용 범위의 출처 표시, 무관한 최근 항목 처리다. 아직 공개 기능으로 구현됐다는 뜻은 아니다.

사용자 역할의 자동 플러그인 메시지가 사람 교정처럼 분류될 수 있는 입력 경계 문제도 확인했다. 출처 태그와 작업 디렉터리 기준 회수를 넣은 수정이 0.2.0으로 공개됐다. 그래도 자동 입력을 완전히 가려낸다고 보장할 수는 없다. 이전에 내가 SNS에 올렸던 개인 기록 집계(수천 건 중 가장 많은 교정 횟수, 비율 등)는 이 문제가 섞였을 수 있어서 철회했고, 다시 확인하기 전에는 쓰지 않는다.

5. 과거 실험은 어디까지 말해 주나

예전에 한 사람의 기록에서 고른 요청 39개를 도구 없이 텍스트로 다시 돌리고 모델이 채점하는 탐색 실험을 보고했다. 원문 6개와 지적 예측 지시를 같이 붙인 조건이 아무것도 안 붙인 조건 대비 25승 11무 3패로 집계됐다.

하지만 무작위 규칙과 직접 비교한 17승 14무 8패는 확실한 우위의 근거가 아니다(보고된 양측 검정 p≈0.11). 원문 형식과 예측 지시를 분리하지도 않았으니 원문 하나의 인과효과라고 할 수 없다.

보존된 과거 실행 로그에서 집계와 조건은 확인했지만 원본 case별 산출물을 독립적으로 다시 돌린 건 아니다. 실행이나 사실 확인이 필요한 업무 대부분은 이런 텍스트 재생으로 평가할 수 없다. 지금 공개 버전의 실제 작업 성공률, 장기 유지, 평균 비용 절감은 따로 검증해야 한다.

6. 데이터와 비용

저장된 결과와 세션 상태의 기본 위치는 로컬 ~/.otw다. 다만 판정과 개인 리포트 분석은 내가 쓰는 Claude/Codex CLI를 통해 대화 발췌문을 해당 모델 제공자로 보낸다. “어떤 데이터도 컴퓨터 밖으로 나가지 않는다”는 설명은 맞지 않다. 별도 API 키가 필요 없어도 제공자 호출은 플랜 한도, 사용량, 요금을 쓸 수 있다.

회수 블록이 프롬프트를 얼마나 늘리는지도 한 번 재 봤다(Codex 0.162.1, 합성 교정 6개, codex exec resume의 두 번째 턴). 회수 기능을 끄면 입력 13,743토큰, 회수만 켜면 14,028(+285), 서브에이전트 모델 선택 안내만 켜면 14,364(+621), 둘 다 켜면 14,781(+1,038)이었다. 조건당 한 번씩이라 참고용이다. 재개한 세션에서 모델 선택 안내가 두 번 주입되는 것도 봤는데, 이 중복은 0.2.2에서 고쳤다(재개 시험 추가). 이 측정은 프롬프트 크기만 본 거라 답변 품질이나 비용 절감을 뜻하지 않는다. 기록은 측정 메모에 있다. 판정은 분리된 프로세스로 돌지만 전체 사용 경험에 지연이 없다고 보장하지는 않는다. 저장소 삭제와 제공자 쪽 데이터 처리는 별개다.

7. 10월 28일 측정: 모델이 모르던 내 습관을 따르나

앞선 시험은 모델이 원래 잘하는 실수(테스트 돌리기, 끝까지 하기)를 골라서 켜도 꺼도 만점이었다. OTW가 쓸모 있어야 하는 곳은 거기가 아니라 모델이 알 수 없는 개인 습관이다. 커밋 형식, 쓰는 패키지 도구, 말투, 날짜 형식 같은 것들이다.

그래서 이런 선호 11개를 작업으로 만들어 각각 3번씩 33번 시켰다. 작업과 채점기는 내가 아닌 다른 모델이 썼고 전부 자동 채점이다. 계획은 실행 전에 고정했다.

조건	습관을 지킨 횟수
OTW 없음	1/33
OTW 기존 기본(좁게 찾기)	9/33
OTW 넓게 찾기(`recallWide`, 0.3.0부터 기본)	17/33

저장소를 바꿔 다시 했는데 비슷한 크기의 격차가 나왔다(16/33 대 8/33, 17/33 대 9/33).
원인은 검색이다. 맞는 과거 지적이 인용에 들어오면 모델이 훨씬 자주 따르고, 못 찾으면 달라지는 게 없다. 넓게 찾기가 더 자주 찾는다.
한계도 분명하다. 작업 11개 중 1개는 “한 문장” 형식이 너무 엄격해서 인용이 보여도 안 따랐다. 0/3이던 다른 작업 하나는 나중에 발견한 채점기 오류(코드 블록으로 감싼 답을 탈락시킴)였고, 기록을 다시 읽으니 교정을 본 6번 중 5번이 따랐다(사후 재집계라 표의 수치는 원래 값 그대로이고, 실제 효과를 적게 보여 준다). 모델이 원래 잘하는 실수에서는 이점을 못 찾았고(16개 중 14개 작업), 규칙 150줄을 그냥 넣은 쪽이 전체로는 더 높았다. 다만 기록이 길어지면 규칙 전체를 넣는 방식은 못 쓴다.
채점기 오류를 고친 뒤 같은 저장소와 작업으로 한 번 더 돌렸다(99회). 회수 없음 2/33, 기존 기본 14/33, 넓게 찾기 25/33이다. 방향은 같은데 숫자가 높아진 건 일부는 오류 수정, 일부는 실행마다 달라지는 변동 때문이라 위 표는 바꾸지 않았다. 기록은 저장소 docs에 있다.
아직 모르는 것은 실제 사용자의 긴 기록, haiku와 Sonnet 말고 다른 모델(Opus, Codex 모델), 대화형 사용, 장기 효과다. (10월 29일에 Sonnet으로도 같은 작업을 돌려 회수 없음 2/33, 현재 기본 20/33을 얻었다.) 이 지적들은 모델이 쓴 합성 기록이다. 넓게 찾기는 모든 요청에 인용 최대 6개(약 300토큰)를 붙이는 대가가 있어서, 선호와 무관한 작업 14개에서 방해가 되는지도 따로 확인했다(OTW 없음 40/42, 넓게 찾기 41/42, 방해 없음 확인. 출력 토큰은 약 9% 늘었다). 그래서 0.3.0부터 기본값으로 켰고, 20자 미만의 짧은 입력은 기존 기준을 쓴다(이 보호 장치 자체는 시험하지 않았다). 끄려면 설정에 "recallWide": false를 넣으면 된다.

실험 기록, 계획, 스크립트, 독립 검토에서 나온 약점까지 저장소 docs에 있다.

8. 써 보기 전에

먼저 합성 원문 회수 데모를 보면 좋겠다. 실제 개인 기록 분석과 회상 저장은 별도로 고르는 기능이다. 입력 경계 수정은 공개됐지만 실제 사용으로 충분히 검증되지는 않았다. 그래서 이 글은 개인 기록에 report --seed를 돌리는 걸 아직 권하지 않는다.

설치와 설정은 현재 README를 보면 된다. Codex는 /hooks에서 훅을 신뢰하는 단계가 필요하고, 안 하면 훅이 조용히 돌지 않는다(otw status로 확인할 수 있다). Windows는 CI의 테스트와 훅 실행이 성공한 것과 실제 호스트 세션이 성공한 것을 구분해야 한다.

가장 필요한 피드백은 성공담만이 아니다. 관련 없는 교정이 돌아왔는지, 필요한 교정이 빠졌는지, 회수된 뒤에도 같은 실수를 했는지를 알고 싶다. 원문, 코드, 회사 이름 없이 이슈로 알려 줘도 된다. 개인 기록이나 리포트 원문을 내라고 하지 않는다.

Off the Wall: when a past correction returns before a new request

Fri, 16 Oct 2026 00:00:00 GMT

English version of the Korean original. If they differ, the Korean article is authoritative.

Dude, Toldya? (working title)

In plain words, Off the Wall is a plugin that shows my own earlier corrections again, unshortened, before the agent answers. I gave Claude 33 tasks about habits a model can’t know: without the plugin it followed the habit 2 times, with it 20 times (Claude Sonnet, test habits I made up). What it does and does not do is in the plain-language post. This post is the longer measurement log I wrote before it.

Update history. 2026-10-29: the same effect showed up with a larger model (Sonnet), and otw forget, which deletes saved corrections, shipped in 0.3.1. 2026-10-28: the first measurement of an effect on personal preferences the model cannot know (section 7 below). 2026-10-27: the input-boundary fix shipped in 0.2.0, and I added a single run on a real Codex host. 2026-10-23: I separated what the old experiment shows from what the public plugin demonstrates. The latest numbers and limits are in the plain-language post.

When you correct a coding agent, the important thing was not only a rule like “do better next time”. What you corrected, in which request, and how has to still be there before the next task.

Off the Wall is an early plugin that quotes the saved text of your past corrections into the context of the next request in Claude Code and Codex. It is not a tool that guarantees better answers or lower cost.

See the recall demo without any personal history

The demo opens with no install and no login. Every input is a made-up case, and it shows the context the public hook really returned next to an empty store. It is not a staged before/after of a better model answer.

1. The moment the original text comes back
2. What I actually checked
- 2-1. One run on a real Codex (added October 27)
3. What the public version does now
4. Preserving the original text is not enough
5. What the old experiment says
6. Data and cost
7. The October 28 measurement: does the model follow habits it didn’t know
8. Before you try it

1. The moment the original text comes back

The example below is not from a personal chat. I made it up for the demo.

Don’t just run lint and say “tests pass”. Run the checkout integration test and show the real exit code.

Later I send a new request: “Verify the payment handler change with the checkout integration test.” Instead of a general “verify well”, the exact test and the exact evidence I asked for come back in the context, in my own words.

A screen from an isolated run on synthetic input. I did not run the model’s next answer. Corrections about other tasks’ scope get mixed in too, which is a limit I come back to in section 4.

The demo has a case that keeps the task scope, a case where I delegated the choice so the agent should not ask again, and a limit case where an unrelated request still receives recent corrections. The corrections for the three core cases are older than the latest 6 items.

2. What I actually checked

I ran the fixed commit 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc of public OTW 0.1.1 without changing it.

4 synthetic requests × empty and stored states × Claude and Codex hook modes: 16 CLI hook runs in total.
The stored corrections and requests are fixtures I made by hand. I did not verify automatic judging or extraction from past history.
I checked that related, recent corrections are selected and end up in additionalContext, and that future-dated corrections are left out.
I used no personal history, no model provider and no real Claude Code or Codex session.

Recalled, followed by the model, the real task succeeding, and the user correcting less are different stages. This reproduction only confirmed the first.

2-1. One run on a real Codex (added October 27)

The reproduction above ran the hooks without a host. So I ran plugin 0.2.0 once on a real Codex on macOS (codex-cli 0.162.1) with an isolated home directory and synthetic prompts. I confirmed plugin install, hook trust, saving a correction in one turn, that correction being injected as a developer message in the next turn, and otw report on the bundled example history (9 of 20 answers classified). The record is in the repository docs.

Hooks do not run before you trust them. After install only, nothing happens, quietly. You have to trust them in /hooks, and since 0.2.1 otw status shows recent hook activity and the number of trusted entries.
It is one run on one computer. I did not check whether the model followed the recalled correction.
I could not run Claude Code interactively. At first there was no logged-in Claude Code, so I could not. Later I confirmed saving a correction and recalling it in a new session once, with plugin 0.2.1 in headless mode on Claude Code 2.1.311. In the third turn of the same test the model produced strangely long output for 6 minutes once (it did not reproduce in 8 reruns), and I did not check interactive use. The record is in the repository docs.

3. What the public version does now

When first published, it picked up to 3 saved corrections whose past requests resemble the new one in string features, then filled up to 6 with recent ones. Since 0.3.0 recallWide is on by default: a request of 20 characters or more gets up to 6 corrections ranked by similarity, and ones with no overlap at all are left out. Search is word and character-bigram TF-IDF, so I do not claim it understands meaning or judges scope exactly.

When the judging feature is on, a separate process reviews the previous answer and your new message and saves correction candidates. report is an optional diagnostic that classifies corrections in existing chats. There is also a model-selection hint, but I do not present it as automatic optimization or a general cost saving.

The quoted block is not a card in your chat window. It is extra context handed to the model. The demo in this post is a separate inspection screen for that hidden input.

4. Preserving the original text is not enough

For the payment test request in the demo, a one-off scope correction from another task, “only fix the login file”, was selected too. For an unrelated question about Mars, the latest 6 corrections came in.

The key sentence coming in does not make the whole selection appropriate. I have to tell whether “this request” in the original points at a past task, and whether it is a preference that should still hold. I have not measured a case where the model actually behaved wrongly because of this.

What I want to look at next is separating standing preferences from one-off task instructions, showing the original request, project and scope as the source, and handling unrelated recent items. That does not mean it is already a public feature.

I also found an input-boundary problem: an automatic plugin message in a user role can be classified like a human correction. A fix with origin tags and working-directory recall shipped in 0.2.0. Even so, I cannot promise it filters all automatic input. A tally of my personal history that I once posted on social media (the most corrections out of several thousand, a rate and so on) may have been mixed up by this problem, so I retracted it and will not use it until I recheck.

5. What the old experiment says

Earlier I reported an exploratory experiment that replayed 39 requests picked from one person’s history as text, without tools, and graded with a model. The condition with 6 quotes plus an instruction to predict the person’s objection was tallied at 25 wins, 11 ties and 3 losses against attaching nothing.

But the direct comparison with random rules, 17 wins, 14 ties and 8 losses, is not solid evidence of an advantage (reported two-sided p of about 0.11). The quote format and the prediction instruction were not separated, so I cannot call it the causal effect of the original text alone.

I checked the totals and the conditions in the saved execution logs, but I did not independently rerun the original per-case outputs. Most work that needs running things or checking facts cannot be evaluated by this kind of text replay. The real task success rate of the current public version, long-term retention and average cost saving need separate verification.

6. Data and cost

Saved results and session state live by default in local ~/.otw. But judging and personal report analysis send conversation excerpts through the Claude or Codex CLI I use to that model provider. The statement “no data leaves the computer” is not true. Even without a separate API key, provider calls can use plan limits, usage and fees.

I also measured once how much the recall block grows the prompt (Codex 0.162.1, 6 synthetic corrections, the second turn of codex exec resume). With recall off the input was 13,743 tokens, recall only 14,028 (+285), subagent model-selection hint only 14,364 (+621), both 14,781 (+1,038). One run per condition, so it is for reference. I also saw the model-selection hint injected twice in a resumed session, and I fixed that duplication in 0.2.2 (a resume test was added). This measured prompt size only, not answer quality or cost saving. The record is in the measurement note. Judging runs in a separate process, but I do not guarantee there is no delay in the whole experience. Deleting the store and the provider’s handling of data are separate things.

7. The October 28 measurement: does the model follow habits it didn’t know

The earlier tests picked mistakes the model already avoids (running tests, finishing the job), so it got full marks with recall on or off. The place where OTW has to be useful is not there. It is personal habits the model cannot know: commit format, package tool, tone, date format.

So I turned 11 such preferences into tasks and ran each 3 times, 33 runs. A model other than me wrote the tasks and the graders, and grading is fully automatic. I fixed the plan before the runs.

Condition	Times the habit was followed
No OTW	1/33
OTW earlier default (narrow search)	9/33
OTW wide search (`recallWide`, default since 0.3.0)	17/33

I switched to another store and reran it, and a gap of a similar size came out (16/33 against 8/33, 17/33 against 9/33).
The cause is search. When the right past correction makes it into the quotes the model follows much more often, and when it is not found nothing changes. Wide search finds it more often.
The limits are clear too. In 1 of the 11 tasks the “one sentence” format was too strict, so the model did not follow even with the quote shown. Another task at 0/3 turned out to be a grader bug I found later (it failed answers wrapped in a code block), and on rereading the records 5 of the 6 runs that saw the correction followed it (a later regrading, so the number in the table stays as it was, and it understates the real effect). I found no benefit on mistakes the model already avoids (14 of 16 tasks), and just pasting 150 rules scored higher overall. But once the history grows, pasting all the rules does not work.
After fixing the grader bug I ran the same store and tasks once more (99 runs): no recall 2/33, earlier default 14/33, wide search 25/33. The direction is the same. The numbers went up partly from the fix and partly from run-to-run variation, so I did not change the table above. The record is in the repository docs.
What I still don’t know: real users’ long histories, models other than haiku and Sonnet (Opus, Codex models), interactive use, long-term effects. (On October 29 I ran the same tasks on Sonnet: no recall 2/33, current default 20/33.) These corrections are synthetic records written by a model. Wide search has a cost of attaching up to 6 quotes (about 300 tokens) to every request, so I also checked separately whether it gets in the way on 14 tasks unrelated to preferences (no OTW 40/42, wide search 41/42, no interference seen; output tokens rose about 9%). That is why I turned it on by default from 0.3.0, and input under 20 characters uses the earlier rule (I did not test that protection itself). To turn it off, put "recallWide": false in the settings.

The experiment records, plans, scripts and the weaknesses found by an independent review are in the repository docs.

8. Before you try it

I’d like you to look at the synthetic recall demo first. Analysis of your own history and saving recall are separate choices. The input-boundary fix is public but has not been checked enough in real use, so this post does not yet recommend running report --seed on personal history.

For install and settings, see the current README. Codex needs the step of trusting hooks in /hooks, and if you skip it the hooks quietly do not run (otw status shows it). On Windows, keep passing tests and hook runs in CI separate from success in a real host session.

The feedback I need most is not only success stories. I want to know whether an unrelated correction came back, whether a needed one was missing, and whether the agent made the same mistake even after the recall. You can tell me through an issue without original text, code or company names. I am not asking for personal records or report text.

Off the Wall:过去的纠正在新请求之前重新出现的那一刻

Fri, 16 Oct 2026 00:00:00 GMT

本文是韩文原文的简体中文翻译。如有出入,以韩文原文为准。

Dude, Toldya? (working title)

通俗地说,Off the Wall 是一个插件,在智能体回答之前,把我自己以前的纠正不加缩短地再显示一遍。我让 Claude 做了 33 个关于模型无从得知的习惯的任务:没有插件时遵守了 2 次,有插件时遵守了 20 次(Claude Sonnet,我编出来的测试习惯)。它能做什么、不能做什么,见通俗说明文章。本文是在那之前写的、更详细的测量记录。

更新记录。2026-10-29:在更大的模型(Sonnet)上也看到了同样的效果,删除已存纠正的 otw forget 已随 0.3.1 发布。2026-10-28:第一次测量了对模型无从得知的个人偏好的效果(下面第 7 节)。2026-10-27:输入边界修复已随 0.2.0 发布,并增加了在真实 Codex 宿主上运行一次的记录。2026-10-23:我把旧实验显示的内容和公开插件实际证明的内容分开写了。最新的数字和局限见通俗说明文章。

纠正编码智能体时,重要的不只是一条”下次做好”的规则。你纠正了什么、在哪个请求里、怎么纠正的,这些在下一个任务之前也得还在。

Off the Wall 是一个早期插件,把保存的过去纠正原文,作为下一个请求的上下文引用给 Claude Code 和 Codex。它不是保证更好回答或更低成本的工具。

不需要任何个人记录,先看回忆演示

演示无需安装或登录。所有输入都是编出来的案例,展示公开钩子真正返回的上下文和空库的差别。它不是把更好的模型回答做成的前后对比。

1. 原文回来的那一刻
2. 我实际检查了什么
- 2-1. 在真实 Codex 上运行一次(10 月 27 日新增)
3. 现在的公开版本做什么
4. 只保留原文是不够的
5. 旧实验说明了什么
6. 数据与成本
7. 10 月 28 日的测量:模型会遵循它原本不知道的习惯吗
8. 试用之前

1. 原文回来的那一刻

下面不是从个人对话里拿来的,是为演示编的例子。

不要只跑 lint 就说”测试通过”。运行结账集成测试,并给我看真实的退出码。

之后我发一个新请求:“用结账集成测试验证支付处理器的改动。“不是笼统的”好好验证”,而是我要求的是哪个测试、什么证据,用我自己的话回到上下文里。

这是在合成输入上隔离运行的画面。我没有运行模型的下一次回答。别的任务的范围纠正也会混进来,这是第 4 节要说的局限。

演示里有保持任务范围的例子、我把选择权交给智能体所以不该再问的例子,还有无关请求也会收到最近纠正的局限例子。三个核心例子的纠正都比最近 6 条更旧。

2. 我实际检查了什么

我不加修改地运行了公开 OTW 0.1.1 的固定提交 07fe3d3d4f4accc153eb0684f506e0d3c206fdcc。

4 个合成请求 × 空库/已存库 × Claude/Codex 钩子模式,共 16 次命令行钩子运行。
存入的纠正和请求是我手工做的测试数据。我没有验证自动判定或从过去记录中提取。
我检查了相关且较新的纠正会被选中并进入 additionalContext,以及带有未来时间的纠正会被排除。
没有用到个人记录、模型提供方,也没有真实的 Claude Code 或 Codex 会话。

被回忆、模型遵循、真实任务成功、用户少纠正,这是不同的阶段。这次复现只确认了第一个。

2-1. 在真实 Codex 上运行一次(10 月 27 日新增)

上面的复现是不带宿主、只运行钩子。所以我在 macOS 的真实 Codex(codex-cli 0.162.1)上,用隔离的主目录和合成提示把插件 0.2.0 运行了一次。我确认了插件安装、钩子信任、一轮里保存纠正、下一轮里该纠正以开发者消息注入,以及对自带示例记录运行 otw report(20 条回答中分类了 9 条)。记录在仓库 docs 里。

钩子在被信任之前不会运行。只安装的话,什么都悄悄不发生。要在 /hooks 里信任,从 0.2.1 起 otw status 会显示最近的钩子活动和已信任的项目数。
这是在一台电脑上运行一次。我没有查看模型是否遵循了被回忆的纠正。
我没能以交互方式运行 Claude Code。一开始没有登录的 Claude Code,所以做不了。后来在 Claude Code 2.1.311 的无头模式下用插件 0.2.1 确认过一次保存纠正和在新会话里回忆。同一次测试的第三轮中,模型有一次连续 6 分钟输出异常冗长的内容(8 次重测没有复现),交互使用我没有确认。记录在仓库 docs 里。

3. 现在的公开版本做什么

首次发布时,它先挑出最多 3 条保存的纠正(对应的过去请求在字符串特征上与新请求相似),再用最近的条目补足到最多 6 条。从 0.3.0 起 recallWide 默认开启:20 个字符以上的请求会按相似程度附上最多 6 条纠正,完全没有重合的则不附。检索是基于词和字符 bigram 的 TF-IDF,所以我不声称它理解含义或能准确判断适用范围。

开启判定功能后,会由单独的进程审阅上一条回答和新消息,保存纠正候选。report 是对已有对话里的纠正做分类的可选诊断功能。也有模型选择建议,但我不把它说成自动优化或一般意义上的节省成本。

被引用的块不是聊天窗口里的卡片,而是交给模型的额外上下文。本文的演示是用来查看这个隐藏输入的单独检查画面。

4. 只保留原文是不够的

演示里的支付测试请求,也选中了另一个任务的一次性范围纠正”只改登录文件”。对于一个无关的关于火星的问题,最近的 6 条纠正也进来了。

关键的那句话进来了,不代表整个选择就是恰当的。我得分清原文里的”这次请求”指的是不是过去的任务,以及它是不是现在还该保持的偏好。我还没有测过模型是否因此真的做错了。

接下来我想检查的是:区分长期偏好和一次性任务指令,显示原始请求、项目和适用范围这些来源,以及处理无关的最近条目。这不代表它已经是公开功能。

我还发现了一个输入边界问题:用户角色下插件自动发送的消息,可能被当成人的纠正来分类。加入来源标记和按工作目录回忆的修复已随 0.2.0 发布。即便如此,我也不能保证它能完全过滤自动输入。我以前在社交媒体上发过的个人记录统计(几千条里最多的纠正次数、比例等)可能被这个问题混淆,所以我撤回了,重新确认之前不再使用。

5. 旧实验说明了什么

以前我报告过一个探索性实验:把一个人记录里挑出的 39 个请求只以文字重放,不用工具,由模型评分。6 条引用加上”预测这个人会提出什么异议”这句话的条件,对比什么都不附,统计为 25 胜 11 平 3 负。

但与随机规则直接对比的 17 胜 14 平 8 负,不是确定优势的证据(报告的双侧检验 p 约为 0.11)。引用格式和预测指令没有分开,所以不能说是原文本身的因果效果。

我在保存的运行日志里确认了总数和条件,但没有独立重跑原始的逐案输出。需要运行东西或核对事实的工作,大多无法用这种文字重放来评估。当前公开版本的真实任务成功率、长期保持和平均成本节省,都需要另外验证。

6. 数据与成本

保存的结果和会话状态默认放在本地 ~/.otw。但判定和个人报告分析,会通过我用的 Claude 或 Codex 命令行把对话摘录发给该模型提供方。“任何数据都不会离开电脑”这种说法是不对的。即使不需要单独的 API 密钥,调用提供方也可能消耗套餐额度、用量和费用。

我还测了一次回忆块让提示增加多少(Codex 0.162.1,合成纠正 6 条,codex exec resume 的第二轮)。关闭回忆时输入为 13,743 个 token,只开回忆为 14,028(+285),只开子智能体模型选择建议为 14,364(+621),两者都开为 14,781(+1,038)。每个条件只测一次,仅供参考。我还看到恢复的会话里模型选择建议被注入了两次,这个重复已在 0.2.2 修复(增加了恢复测试)。这只测了提示大小,不代表回答质量或节省成本。记录在测量备忘里。判定在分离的进程里运行,但我不保证整体使用体验没有延迟。删除存储和提供方一侧的数据处理是两回事。

7. 10 月 28 日的测量:模型会遵循它原本不知道的习惯吗

之前的测试挑的是模型本来就不会犯的错(跑测试、做到底),所以开不开回忆都是满分。OTW 该有用的地方不在那里,而在模型无从得知的个人习惯:提交格式、使用的包工具、语气、日期格式。

所以我把这样的偏好 11 个做成任务,每个跑 3 次,共 33 次。任务和评分器由我之外的另一个模型编写,评分全部自动。计划在运行前就定好了。

条件	遵守习惯的次数
没有 OTW	1/33
OTW 原默认(窄检索)	9/33
OTW 宽检索(`recallWide`,0.3.0 起默认)	17/33

我换了一个库重做,出现了大小相近的差距(16/33 对 8/33,17/33 对 9/33)。
原因在检索。对的那条过去纠正进入引用时,模型遵循得多得多,找不到时则没有变化。宽检索更常找到。
局限也很明确。11 个任务中有 1 个,“一句话”的格式要求太严,即使显示了引用模型也没有遵循。另一个 0/3 的任务,后来发现是评分器的错误(把用代码块包起来的回答判为不通过),重新读记录发现看到纠正的 6 次里有 5 次遵循了(事后重新统计,所以表里的数字保持原值,它低估了真实效果)。在模型本来就不会犯的错上我没有找到好处(16 个任务中的 14 个),直接塞入 150 条规则总体得分更高。但历史变长之后,把所有规则塞进去的做法就行不通。
修复评分器错误后,我用同一个库和任务又跑了一次(99 次):没有回忆 2/33,原默认 14/33,宽检索 25/33。方向一样。数字变高一部分来自修复,一部分来自每次运行的波动,所以我没有改上面的表。记录在仓库 docs 里。
我还不知道的:真实用户的长记录、haiku 和 Sonnet 之外的模型(Opus、Codex 模型)、交互使用、长期效果。(10 月 29 日我用 Sonnet 跑了同样的任务:没有回忆 2/33,当前默认 20/33。)这些纠正是模型写的合成记录。宽检索的代价是给每个请求附上最多 6 条引用(约 300 个 token),所以我还另外检查了它在与偏好无关的 14 个任务上是否碍事(没有 OTW 40/42,宽检索 41/42,没有看到干扰;输出 token 增加约 9%)。因此从 0.3.0 起默认开启,短于 20 个字符的输入沿用之前的规则(这个保护措施本身我没有测试)。要关闭,在设置里加入 "recallWide": false。

实验记录、计划、脚本以及独立评审中发现的弱点,都在仓库 docs 里。

8. 试用之前

希望你先看合成回忆演示。分析你自己的记录和保存回忆是另外的选择。输入边界修复已经公开,但还没有在真实使用中充分验证,所以本文暂时不建议对个人记录运行 report --seed。

安装和设置请看当前 README。Codex 需要在 /hooks 里信任钩子这一步,不做的话钩子会悄悄不运行(可以用 otw status 查看)。在 Windows 上,要把 CI 里测试和钩子运行通过,与真实宿主会话成功区分开。

我最需要的反馈不只是成功的经历。我想知道无关的纠正是否回来了、需要的纠正是否缺了、回忆之后智能体是否仍然犯了同样的错。可以通过 issue 告诉我,不必附上原文、代码或公司名称。我不要求提交个人记录或报告原文。