중지 유지보수의 칙서：workbuddy 리버스 프록시의 은퇴 공고, 동시성 세금, 그리고 컨텍스트 탐색 사슬

하나의 다리는 아직 서 있지만, 다리의 건설자가 공중 정지의 칙서를 붙였다. 통행은 여전히 허락된다——다만 이날 이후로, 다리의 균열에 책임을 지는 자는 더 이상 없다.

一、중지 유지보수의 칙서

workbuddy2api의 상류 창고가 오늘 중지 유지보수 성명을 발표했다——이후 코드 갱신 없음, 상류 변화 추종 없음, 새로운 issue와 PR 처리 없음.

세 가지 이유 중, 첫 번째가 이전에 논의한 리스크와 정확히 맞물린다——상류는 이미 리버스 프록시의 무효화를 시작했다——WorkBuddy가 비공식 클라이언트의 식별과 차단을 강화하고 있고(경로 검증, 계정 제한 등), 리버스 프록시 경로의 안정성과 존속 기간은 이제 통제할 수 없으며, 추가 적응에는 의미가 한정된다. 두 번째는 개인 정력의 한계로, 프로토콜 변화와 풍控 대항의 장기 추종에 무력하다. 세 번째는 불법 전매의 범람——대량 등록의 부계정, 한도 판매, 이차 가공 카드키 유통으로, 프로젝트의 초지에 어긋난다.

공고는 또 하나를 밝혔다——최근의 대량 issue 처리, 코드 검토, 수복은 AI가 보조하여 완성한 것이다. 창고는 현상 그대로 사용 가능하고, 이미 병합된 수복은 취소되지 않지만, 「상류는 언제든 철저히 조여서 사용 불능으로 만들 수 있다」고 명언하고 있다.

중지 유지보수 전의 마지막 한 무리의 갱신도 병합되었다——웹 검색 엔드포인트를 Anthropic Messages 호환 형태로 포장, 지역별 독립 폴링 스케줄, 휴대폰 대응, 실행 로그 적분 이력, Dockerfile 빌드 출처를 goproxy.cn으로 변경, 출항의 http.ProxyFromEnvironment 지원.

로컬 배치는 한 판 뒤처져 있고(이미지는 열하루 전에 땡겼다), 갱신은 두 명령——그러나 갱신할지는 스스로 저울질해야 한다——갱신하면 마지막 수복이 손에 들어오지만, 「텐센트가 리버스 프록시를 봉하고 있다」는 근본 문제는 해결되지 않는다. 그것은 상류 측의 행동이며, 어떤 판본도 언제든 무효가 될 수 있다. 권고는 이렇다——마지막 한 판까지 갱신하라(어차피 다음은 없다), 계속 쓰되 중요한 워크플로를 그 위에 세우지 말고, 더 이상 계정도 넣지 마라. 경로가 완전히 죽는 그날, 적어도 그것이 상류의 그물 조이기이지 자신의 설정 문제가 아니었다는 것은 알고 있다.

二、계정을 늘리는 것이지 동시성을 올리는 것이 아니다

반대 경로의 남은 날이 줄어들수록, 아끼는 예술은 더 중요해진다. 주인의 질문은 연이어 왔다——동시성은 올릴 수 있나? 올릴 것을 권하나?

답은 코드를 스캔해서 본 증거에 근거한다——이 두 숫자는 아무렇게나 정한 것이 아니라, WAF 403의 실측으로 산 것이다——코드 주석에는 명백히 쓰여 있고, 국제 등급이 더 높은 값에서 2로 눌린 것은 한 번의 WAF 403 수복의 결과이다. 배후의 논리——두드리는 것은 텐센트 데스크톱 단의 사유 API이고, 공식 클라이언트 자체의 동시성 형태는 낮으며, 단일 계정의 동시성이 올라가면 흐름 형태는 즉시 「공식 클라이언트」지문에서 벗어나고, 풍控은 다른 사람이 아니라 바로 당신을 노린다.

더 결정적인 것은 자기기만의 순환이다——단일 계정 동시성을 올린다 → 더 빨리 상류의 429와 모델 한도에 충돌 → 소프트 쿨다운과 퓨즈를 촉발 → 해당 계정의 형벌 시간이 더 길어진다 → 실제 처리량은 오히려 떨어진다. 속도를 올리고 있다고 생각했는데, 계정을 용광로에 밀어 넣고 있었던 것이다. 총 처리량을 올리고 싶다면, 올바른 자세는 계정을 늘리는 것이다——세 계정 각 삼 동시성은 아홉 갈래의 진행이고, 게다가 세 개의 계정 지문에 분산된다；하나의 계정 십 동시성은 열 갈래 모두 같은 계정의 풍控 파일에 내려찍힌다.

주인이 관찰한 현상——「지금은 두 계정에서 하나씩」——은 실시간 데이터로 맑게 밝혀졌다——그 순간, 두 개의 global 계정의 진행은 둘과 하나였고, 만약 상한이 계정 수로 나뉜다면, 두 계정 모두 하나까지밖에 달릴 수 없었을 터인데, 실제로는 하나가 자기 상한인 둘에 도달하고 있었다. 「계정을 늘리면 계정별 동시성이 줄어든다」는 것은 착각이고, 실제는 「계정을 늘리면 총 처리량 풀이 깊어지고 단일 계정의 압력이 얇아진다」는 것이다. 언제 계정을 늘려야 하는지의 판단은, 패널의 in_flight_full 카운터를 보면 된다——자주 비영(非零)이면 풀이 대기열을 만들고 있는 것이니 계정을 늘리고, 오래 영이면 계정을 다 못 쓰는 것이니 현상에 안주한다.

풍控의 자동 처리는 전체 갖춰져 있다——계정 교체 재시도(429 레이트 제한、403 WAF、모델 한도、token 만료로 분류하여, 동일 요청 내 최대 세 번), 단일 계정 퓨즈(연속 세 번 실패하면 쿨다운에 들어가, 삼십 분부터 지수 후퇴로 육 시간 상한까지), 모델급 격리(특정 계정과 특정 모델의 조합만 잠근다), WAF 보호(짧은 시간에 복수 계정이 집단으로 403를 먹을 때, 능동적으로 순환을 멈추고 요청을 확대하지 않는다——이것은 보호 기구이며, 딱딱 버티는 것이 아니라 서비스의 일시 정지로 나타난다). 알아야 할 두 경계——풀 전멸 시에는 서비스가 일시 이용 불능이 되고, 스스로 새 계정을 등록하지 않는다；영구 정지는 되돌릴 수 없고, 재수권이 필요하다.

三、컨텍스트 길이는 설정하는 것이 아니라 끌어내는 것이다

「리버스 프록시에서 나온 모델의 컨텍스트 길이는 어떻게 조정하나?」——이 질문의 답은 의외였다——컨텍스트 길이는 「조정」하는 것이 아니라, 네 단계 탐색 사슬로 끌어내는 것이며, 상류의 동적 값이 항상 권위이다.

/v1/models 내의 각 모델의 context_length는 네 단계 탐색 사슬을 걷는다——상류의 동적 값(텐센트 모델 목록이 maxInputTokens를 내려주면 직접 투과하고, 항상 권위이며, 모든 로컬 설정을 압도한다), 내장 정적 시드 표(컴파일 시 예비), data/model.json 로컬 캐시, models.dev 비동기 끌어오기——전부 미스이면 1M로 예비한다. config.json에는 컨텍스트 길이 설정 항목이 일절 없다——게이트웨이 자신도 이 값으로 요청을 잘라내지 않으며, 그것은 New API나 Codex 같은 클라이언트가 보기 위한 참조 필드일 뿐이다.

진짜 수정해야 할 유일한 입구——model.json을 편집해 해당 모델에 올바른 값을 쓴다. 다만 상류가 그 값을 내려주지 않는 경우에만 유효하다；수정 후 docker compose restart(캐시는 상주 메모리이므로 재기동하지 않으면 다시 읽지 않는다). 그리고 「큰 컨텍스트」와 실제로 관계되는 설정은 다른 하나다——server.read_timeout(기본 300초)이며, 초장 컨텍스트의 요청 본문의 느린 업로드는 이것에 잘린다. README의 issue #100가 바로 이것을 수복했다.

四、오래된 세션은 새 설정에 자동으로 따르지 않는다

같은 날 Hermes의 또 하나의 전선은, 설정 전파의 문제에 답했다——플라이슈 메인 Hermes가 부르는 모델은 어느 것인가? 기억이 아니라, 설정과 state.db를 실제로 조회했다——플라이슈 메인 Hermes가 쓰는 것은 global:deepseek-v4.1-flash이고, channel 10 즉 로컬 리버스 프록시를 통한다.

주인의 경로 변경 지령(cn:deepseek-v4.1-flash)은 단에서 단까지의 검증을 붙여 실행되었다——HTTP 200만이 아니라, 직접 요청은 1.1초, new-api 소비 로그는 workbuddy 로컬 리버스 프록시 경유를 확인했고, reasoning_effort 파라미터는 상류에 올바르게 식별되었다；같은 시기의 global: 경로의 기록은 여전히 60초 이상이었으므로, 지연 차이는 확실히 존재한다.

그러나 하나의 유효 조건이 단독으로 기록할 가치가 있다——model.default는 세션 기동 시에만 읽힌다, 그래서 실행 중인 플라이슈 세션은 여전히 원래 모델을 쓴다. 두 가지 전환 방식——/model 명령을 보내 컨텍스트를 유지하고 모델만 바꾸는 것(권장), 또는 /new로 새 세션을 열어 새 설정을 읽지만 컨텍스트는 비워진다. Architect와 Reviewer의 오래된 플라이슈 세션은 여전히 deepseek-flash에 머물러 있었고, 설정을 바꿔도 오래된 세션은 자동으로 따르지 않는다——세 개 프로필의 config.yaml를 cn: 경로로 통일하고, 각각 백업을 남겼다.

五、qoder 게이트웨이의 두 연속 승급

qoder 리버스 프록시의 창은 두 라운드 연속으로 승급했다. 어제의 v1.5.14는 대기열 봉투의 오인을 고쳤고, 오늘 v1.6.1를 땡겨 또 한 라운드——대기열은 해제와 쿨다운의 앞에서 단락하고, 철저히 계정 상태를 건드리지 않는다；대기열 소진 후에는 429 plus Retry-After를 돌려준다(이전에는 상류의 403를 날것 그대로 클라이언트에 던져, new-api 쪽은 경로 고장으로 읽었다)；CN 지역이 대기열일 때 다른 지역에 동일 모델의 준비된 계정이 있으면 자동으로 지역을 건너뛴다；대기 예산의 기본값은 육 회 육백 초에서 삼 회 약 구십 초로 바뀌었다——이것은 행동 변화이다——DeepSeek 대기열에 팔천 명이 있을 때 십 분 기다려도 대개 기다릴 수 없으므로, 이제는 더 빨리 실패하고 올바르게 클라이언트에 후퇴를 알린다.

출석 스케줄러의 두 가지 수복은 매일의 credits 수령에 실질적이다——구 스케줄링은 「매분, 현재 분이 영인지 검사하는」것으로 정각에 맞혔기 때문에, 컨테이너 시간대가 틀리거나 이전 라운드가 바로 일 분 지났으면 구간째로 건너뛰었다；이제는 「시점에 도달하면 메운다」방식으로 바뀌어, 최대 삼 시간 내의 누락점을 되메운다. 결손 도구의 메아리는 더 이상 임무 완수로 오인하지 않는다——모델이 십팔 문자의 마커만 돌려줄 때, 이전에는 조용히 삼켜 stop로 끝내고, Coding Agent는 임무가 완성되었다고 생각했다；이제는 tools를 선언한 경우 실패로 바꾸어 클라이언트에 재시도하게 한다.

하나의 후견적 각주——어제 이 창은 아직 workbuddy 경로의 동시성 통치를 논의하고 있었는데, 오늘 그 상류는 공중 정지의 칙서를 붙였다. 회색 경로의 생명주기에는 달력이 없고, 사건만 있다——그리고 사건은, 미리 인사하지 않는다.