oh-my-openagent install --platform=native를 사용하면 이제 OmO Native가 자동으로 설치되므로 더 이상 패키지 이름이나 권장 런타임을 알 필요가 없습니다. native는 이제 공개 플랫폼으로, install --help와 OpenCode, Codex, Both 옆의 대화형 선택기에 목록으로 나타납니다. 선택하면 실제 설치가 수행됩니다. bun이 PATH에 있을 때는 bun add -g omo-ai@beta, 없을 때는 npm i -g omo-ai@beta를 실행하며, bun이 권장 런타임으로 지정됩니다. 그 다음 omo setup을 안내합니다. 전역 설치가 실패하면 수행할 정확한 명령어와 실패 이유가 원본 오류 대신 출력됩니다. 저장소 내 개발 어댑터는 --platform=native-dev 아래에서 오늘의 동작을 유지하며, 여전히 환경 플래그(OMO_ENABLE_NATIVE_DEV_PLATFORM)로 제어되고 이전의 OMO_ENABLE_SENPI_PLATFORM도 계속 허용됩니다. (#8618)
OpenCode 세션에서 TUI 내부의 OmO Native를 안내받을 수 있습니다. 이전에는 설치 시점에만 포인터가 출력되었는데, npm이 기본적으로 숨기고 다른 사용자는 스크롤되어 사라집니다. 이제 세션 시작 시 제한된 토스트 메시지가 OmO Native와 설치 명령어를 표시하고, 명령 팔레트의 /native를 사용하면 대화 상자가 열립니다. 설치를 출력하거나 가이드를 열거나 일주일 뒤에 상기받도록 설정하거나 묻지 않도록 설정할 수 있습니다. 네이티브가 이미 설치되어 있을 때, native-edition-nudge가 disabled_hooks에 있을 때, 자식 세션에서, 그리고 토스트가 자신을 기록할 수 없을 때 토스트는 표시되지 않습니다. 기억할 수 없는 표시는 건너뛰므로 매 세션마다 방해할 수 없습니다. 자동 표시는 4회 이후 중단되며, 간격이 점점 벌어지고 프로세스당 최대 한 번입니다. (#8619)
unspecified-low 카테고리는 이제 먼저 MiMo V2.6 Pro에서 실행되고, Grok 런그는 Grok 4.7로 이동합니다. (#8652)
unspecified-low는 적합한 전문 카테고리가 없고 작업이 포함될 때 위임된 작업이 도착하는 곳입니다. 체인은 xhigh에서 Grok 4.6으로 시작했으며, 이제 max에서 MiMo V2.6 Pro로 시작하여 Xiaomi 또는 opencode-go에서 제공되며, 바로 뒤에 xhigh에서 Grok 4.7이 있습니다. Grok 4.7은 opencode 제공자에서 제공되지 않으므로 해당 레인이 런그를 떠났고 opencode-go가 참여했습니다. 체인의 나머지 부분(GPT-5.6 Terra, Claude Sonnet 5, Qwen 3.8 Max Preview, DeepSeek V4 Pro)는 변경되지 않았으며, MiMo V2.5 Pro는 마지막 런그로 남아 있습니다.
omo.json에서 하니스 블록을 [native]로 작성하고 omo-native-* 검토자에게 위임합니다. (#8620)
독립형 판은 OmO Native로 브랜드되지만, omo.json에서 작성하는 설정 재정의 블록은 [senpi]로 표기되었고, 이름으로 위임하는 검토자 에이전트는 omo-senpi-code-reviewer, omo-senpi-qa-executor, omo-senpi-gate-reviewer였습니다. 두 표기법 모두 엔진의 패키지 이름에서 나왔습니다.
[senpi]는 계속 작동합니다. 설정을 읽을 때 정규화되므로 구성을 다시 쓸 수 없다 하더라도 설정한 모든 값이 계속 적용되며, 첫 시작 시 파일의 키를 한 번 다시 쓰고 시작 공지에서 이름을 지정합니다. 두 블록을 모두 포함하는 파일은 [native]를 확인하고 무시된 파일을 보고합니다. [senpi]를 언급하지 않은 구성은 전혀 손상되지 않습니다.
검토자 에이전트는 이제 omo-native-code-reviewer, omo-native-qa-executor, omo-native-gate-reviewer로 응답합니다. 이전 이름은 한 릴리즈 라인 동안 계속 확인되므로 기존 스킬과 AGENTS.md 파일은 이름을 바꾸는 동안 계속 작동합니다.
OmO Native 아래의 엔진은 여전히 senpi이며 여전히 senpi라고 불립니다. senpi 명령, @code-yeongyu/senpi, SENPI_CODING_AGENT_DIR와 원격 분석 식별자는 변경되지 않습니다.
포괄 unspecified-high 카테고리는 더 이상 GPT-6 Astra에서 실행되지 않습니다. (#8616)
작업이 unspecified-high에 도착할 때는 적합한 전문 카테고리가 없고 작업이 크므로, 해당 레인은 위임된 턴의 큰 부분을 흡수합니다. 해당 체인은 high에서 Astra로 시작했는데, 이는 가장 비용이 많이 드는 추론 모델을 가장 일반적인 레인에 배치했습니다.
체인은 이미 Astra 뒤에 있던 런그에서 시작됩니다: xhigh에서 Claude Opus 5, 그 다음 max에서 GLM 5.3, 그 다음 max에서 Kimi K3. 카테고리 설정에 작성된 기본값은 Opus 5와 함께 이동하므로, 기본 런그와 사용자가 구성에서 읽는 모델이 일치합니다.
Astra는 의도적으로 선택한 곳에 남아 있습니다: ultrabrain, deep-high, 그리고 계획 검토자. 자신의 구성에서 카테고리를 GPT-6 모델로 다시 지정하면 자식은 여전히 Astra 튜닝된 프롬프트 추가를 받습니다.
quick은 Kimi HighSpeed를 모델 체인에서 제거하고, 두 검색 에이전트(explore, librarian)는 생각하기를 끈 상태로 이를 가집니다. (#8616)
Kimi HighSpeed는 quick 체인을 선도했으며 다른 레인에서는 사용하지 않았습니다. quick 체인은 이제 low에서 GPT-5.6 Luna Fast로 시작하고, 그 다음 off에서 DeepSeek V4 Flash가 따릅니다.
explore와 librarian은 이제 변형 off에서 Kimi HighSpeed로 시작합니다. Kimi 엔드포인트는 명시적으로 비활성화된 생각하기 블록을 거부하므로, senpi는 생각하기 매개변수 없이 그리고 가장 낮은 적응형 노력으로 요청을 보냅니다. 이것이 grep 및 보고 에이전트가 필요한 것입니다. Kimi Code 구독이 없는 컴퓨터는 Luna Fast로 넘어가며, 이는 이 변경 전에 이 두 에이전트가 실행된 모델입니다.
독립형 판은 모든 곳에서 OmO Native로 불립니다. 설치 관리자 힌트, 패키지 사후 설치 공지, 설치 가이드, README 및 그 4가지 번역, omo-ai 패키지 설명은 이를 "Senpi 판"으로 불렀습니다. 제품 자체는 TUI 바닥글에서 OmO Native라고 말하고 omo doctor에서 Edition: Native라고 말하면서 이 이름을 사용한 적이 없습니다. 같은 화면의 원격 분석, 모델 프로필, 설정 시작 공지는 omo-senpi로 열렸습니다. 모두 이제 OmO Native라고 말하며, 힌트는 얻는 것을 명시합니다: OpenCode 호스트가 필요 없는 동일한 omo 명령이지만, 이미 있는 설치는 계속 작동합니다. senpi는 여전히 omo doctor에서, 이 파일의 엔진 제목에서, 그리고 자신의 환경 변수 및 경로에서 엔진을 이름 지합니다. 원격 분석 식별자는 변경되지 않습니다. 이전 판 문구가 돌아오면 회귀 테스트가 실패합니다. (#8618, #8629)
공유 RPC 호스트는 세션당 하나씩이 아니라 소스 버전당 하나의 확장 모듈 생성을 컴파일합니다. 세션을 열 때 모든 확장의 새 복사본을 컴파일하고 호스트의 수명 동안 모듈 레지스트리에 남겨두었으므로, 장기 실행 데몬은 매번 다른 전체 그래프를 유지했습니다. 소스는 한 번 컴파일되고 소스 파일이 변경될 때까지 재사용됩니다. 각 세션은 여전히 자신의 확장 인스턴스를 얻습니다. 한 컴퓨터에서 측정한 결과, 세션당 유지 크기는 74.6 MiB에서 3.1 MiB로 감소했습니다. (senpi #1952)
Grok 4.7은 지원되는 모델 패밀리입니다. 집계자 ID(예: openrouter/x-ai/grok-4.7)와 Venice의 대시 grok-4-7을 포함한 모든 grok-4.7 ID 형태는 Grok 4.6 시스템 프롬프트를 재사용하고, grok-4.7은 promptPreset 값이며, xAI 제공자 기본값은 grok-4.5에서 grok-4.7로 이동합니다. (senpi #1990)
하드 OpenAI 사용량 제한 429는 첫 실패 시 종료됩니다. usage_limit_reached / "사용량 제한에 도달했습니다"는 일시적 속도 제한으로 분류되었으므로, 턴은 약 1분 동안 5회 재시도에 소비되었습니다. 이는 더 이상 요청을 처리할 수 없는 계정입니다. 같은 문구는 이제 세션의 나머지 동안 청구 폴백을 고정합니다. 제한에만 접근하는 경고는 여전히 재시도합니다. (senpi #1969)
도구 호출의 인수를 정규화할 때 더 이상 모델이 생성한 보조 메시지를 다시 쓰지 않습니다. 두 인수 정규화자(eval 셀의 요약에 대한 80자 제한과 편집 도구의 edits 목록 다시 쓰기)는 이전에 메시지를 제자리에서 변경했습니다. claude-sdk-oauth 레인에서는 이것이 Session continuity lost - resent the full conversation (assistant_rewritten)의 일반적인 원인이었습니다. 이제 분리된 복사본에서 실행됩니다. 80자 eval 요약 제한은 변경되지 않습니다: 렌더링된 라인에 적용됩니다. (senpi #1472)
감독 RPC 호스트의 감독자가 옵저버를 잃으면 재연결을 계속하고, 소켓 파일이 삭제되면 호스트는 드레인되고 종료됩니다. 감독자는 손실된 옵저버를 한 번 재시도하고 포기했으므로, 건강하지 않은 옵저버가 바쁜 상태로 계산되기 때문에 유휴 창이 경과할 수 없었습니다. 재연결은 이제 성공할 때까지 계속되며, 전체 유휴 창 동안 건강하지 않은 상태로 유지되는 옵저버는 더 이상 바쁜 상태로 계산되지 않습니다. 작업 공간을 제거하거나 소켓을 삭제하는 것은 재부팅할 때까지 쌍을 실행한 상태로 두었습니다. 연결된 세션이 완료되면 호스트가 종료됩니다. persistent로 시작한 호스트는 여전히 유휴로 인해 종료되지 않습니다. (senpi #1979, #1961)
라이브 Claude SDK 세션에서 두 번째 터미널을 열면 더 이상 재개 가능한 바인딩(다음 턴이 전체 대화를 다시 보내는 대신 대화를 계속할 수 있는 저장된 링크)이 버려지지 않습니다. 추가하는 시작 공지는 바인딩을 폐지했으므로, 다음 턴은 registry_miss로 전체 대화를 다시 보냈습니다. 커밋된 보조자 뒤의 추가 전용 항목은 바인딩을 유지합니다. 나중의 보조자 메시지, 압축, 분기 요약, 명시적 무효화는 여전히 이를 버립니다. Claude Code가 누락되었다고 보고하는 포크 포인트(대화가 분기한 메시지)는 매 턴마다 다시 요청되는 대신 제거됩니다. (senpi #1964, #1958, #1973)
워커가 열리는 동안 죽으면 세션은 session_closing 대신 워커의 이유를 포함하는 open_failed를 보고합니다. 이는 다른 사람이 가지고 있는 세션입니다. (senpi #1953)
DAG 스냅샷은 이제 각 노드가 실제로 반환한 것을 포함하고 실행 중인 노드의 자식이 마지막으로 뭔가를 한 시점을 표시합니다. (#8674)
workflow는 action=snapshot으로 분리되어 들여다보도록 지시하지만, 스냅샷은 노드의 출력을 포함하지 않았습니다. 텍스트가 저장되고 있었습니다. 다만 차단 대기를 통해서만 도달할 수 있었으므로, 감독하던 실행은 읽을 수 있는 것이 없는 6개의 노드를 표시했고, 자식이 한 일을 배우는 유일한 방법은 작성한 파일을 보는 것이었습니다.
정착한 노드는 이제 output(자식의 최종 메시지, 최대 2000자)과 outputBytes(전체 크기로, 잘린 미리보기와 전체 항목을 구별할 수 있고, 아무것도 반환하지 않은 노드는 기록되지 않은 것이 아니라 0으로 읽음)를 포함합니다. 실행 중인 노드는 lastActivityAt(자식이 마지막으로 뭔가를 쓴 시간)를 포함하고 snapshot은 10분 이상 침묵한 모든 실행 중인 노드를 이름 지웁니다. 침묵은 보고됩니다. 판단하지 않습니다. 한 번의 긴 도구 호출은 정지된 자식과 같이 보입니다. 하지만 이제 50분 동안 조용한 노드는 추측해야 하는 것이 아니라 볼 수 있는 것입니다.
종료 시간은 이미 completed_at이라는 이름으로 기록되었습니다. 자식이 완료했지만 재수거되지 않아 running에서 막혀 있는 노드는 별개의 결함이며, #8659에서 추적됩니다.
명령 도중 죽는 git은 더 이상 도우미가 종료될 때까지 격리 작업을 중단시키지 않습니다. runGit은 자식 close 이벤트에 정착했습니다. 이는 모든 stdio 파이프가 닫힌 후에만 발생합니다. 하지만 git의 ! 별칭 셸은 이러한 파이프를 상속합니다. Windows에서는 git만 죽이면(TerminateProcess에 트리 의미가 없음) 이러한 셸이 모든 핸들을 보유하므로, git이 이미 실패한 실행은 마지막 생존자가 종료될 때까지 대기 상태로 유지됩니다. CI에서는 30초 테스트 예산을 경합하며 간헐적으로 손실되고, 생존자의 잠긴 작업 디렉터리는 EBUSY로 고정 분해로 나타납니다. 신호 사망이나 허용되지 않은 종료 코드로 종료되는 git은 이제 한 번에 정착합니다: 트리의 나머지는 즉시 삭제되고, 1초 후에도 여전히 보유한 파이프는 강제로 닫혀 지금까지 유지한 출력과 함께 입력한 GitCommandError가 나타납니다. 일반 명령은 영향을 받지 않습니다. 해당 파이프는 어차피 밀리초 내에 닫힙니다. (#8663)
재개한 DAG는 더 이상 아무것도 실행하지 않을 때 노드를 실행 중으로 표시하지 않습니다. (#8657)
세션을 재개할 때 자식 작업 기록이 여전히 running이라고 말하는 모든 DAG 노드를 다시 채택했습니다. 재개 프로세스가 여전히 해당 자식을 보유하고 있는지 묻지 않았습니다. 호스트가 사라진 자식은 의도적으로 running으로 유지되므로 나중에 기록에서 다시 열 수 있습니다. 하지만 해당 자식을 기다리는 DAG 노드는 영원히 기다립니다. 실행이 자식이 여기서 정착할 때만 노드를 폴드하기 때문입니다. 노드는 따라서 재시작에서 재시작으로 저장된 실행 상태에서 running으로 유지되고, 뒤의 작업은 차단되며, 위젯은 시간 전에 죽은 자식에 대해 시간을 계속 계산했습니다.
이러한 노드는 이제 작업과 도달할 수 없는 이유를 이름 지운 이유로 재개 시 실패하고, 뒤의 노드는 다른 실패와 마찬가지로 건너뛰며, 재시도 또는 전송은 여전히 이를 부활시킵니다. 이 세션이 정말로 보유한 자식을 가진 노드는 이전과 같이 재연결됩니다.
DAG 기록이 있는 세션을 재개할 때 더 이상 TUI가 정지되지 않습니다. DAG 실행을 나열하면 각 호출에서 실행 디렉터리의 모든 체크포인트를 구문 분석했고, 상태 위젯은 약 초당 한 번 해당 목록을 요청했으므로, 재개(체크포인트 쓰기 버스트)는 프로세스가 살아 있고 여전히 프롬프트에 응답하는 동안 화면을 금단했습니다. 목록은 이제 실행당 요약 캐시를 유지합니다. 710개의 체크포인트 디렉터리에서 한 호출은 473ms 중앙값에서 3.4ms로 감소했습니다. (#8649)
DAG 실행 기록은 광고된 7일 보존에 따라 정리됩니다. 정리는 존재했고, 테스트되었으며, 어디에서도 호출되지 않았으므로 체크포인트, 이벤트 로그, 결과, 키가 영구적으로 누적되었습니다. 장기 실행 프로젝트 디렉터리는 711개의 체크포인트를 보유했으며, 가장 오래된 것은 7일 정책에 대해 25일입니다. 스윕은 이제 세션 시작 후 DAG 런타임당 한 번 실행되며, 시작 경로 밖에서 오래된 파일이 세션을 실패시킬 수 없고, 스윕당 키와 잠금 디렉터리를 한 번 인덱싱합니다. 리스 홀더가 여전히 살아 있는 일시 중지된 실행은 유지됩니다. 170 MB 상태 디렉터리의 복사본에 대해 스윕은 10,623개의 파일을 1,779로 줄였고 170 MB을 38 MB로 줄였습니다. (#8651)
남은 config.jsonc를 마이그레이션할 때 [native]를 작성하고, [native] 블록은 이전 이름과 동일한 추론 정리를 받습니다. 첫 시작 시 폐지된 하니스 키를 새 파일에 복사했으므로, 나중에 이름을 바꿀 수 있었습니다. 남은 파일 변환은 이제 [native]를 내보냅니다. 추론 키 통합은 이전 표기법뿐만 아니라 [native]도 검사합니다. 이 정리가 이름 바꾸기 통과 전에 실행되고 문서화된 이름으로 이미 작성된 파일을 건너뛰고 있기 때문입니다. (#8631)
위임된 작업의 실패한 턴은 더 이상 턴으로 계산되지 않습니다. 제공자 오류가 보조자 턴을 종료하면 해당 턴은 이제 failed_turns 통계로 이동하여 turns를 부풀리지 않으며, 해당 사용량(제공자가 오류와 함께 보내는 일반적으로 모든 영 블록)은 토큰, 비용, 생성 시간에 기여하지 않습니다. 성공한 턴을 생성하지 않은 실행은 토큰 및 비용 범위를 unavailable로 보고하고 비용 필드를 완전히 생략합니다. 6개의 연속 실패에 대해 turns: 6이라고 주장하는 대신입니다. $0의 비용이 드는 성공한 턴은 계속 0의 비용을 보고하고, 실패는 생성 창을 다시 앵커로 지정하여 다음의 성공한 턴의 처리량은 생성이 아니라 실패에서 측정됩니다. 라이브 작업 행은 이제 같은 이야기를 말합니다: 첫 성공한 턴이 나타날 때까지 starting을 읽습니다. 팬텀 turn 0, 비용 토큰이 없습니다. 제공자 시도가 계속 실패하는 동안 동사 retrying을 사용하여 failed N을 표시하고, 실제 턴 이후에만 running으로 돌아갑니다. TUI 상태 라인과 배경 작업 행 모두 하나의 공유 빌더에서 상태 토큰을 그립니다. 따라서 두 문법이 다시 분리될 수 없습니다. (#8627)
ulw-loop 게이트 검토자는 Codex 표면에서 다시 적용됩니다. (#8630)
검토자 에이전트의 이름을 omo-native-*로 바꾸면 Codex 측 ulw-loop 가드(수동 QA 아티팩트가 존재한 후에만 게이트 검토자가 시작되는지 확인)만 폐지된 omo-senpi-* 표기법과 일치하도록 남겨 두었습니다. 리졸버(검토자의 이전 이름을 새 이름으로 매핑)가 가드가 보기 전에 이름을 정규화하기 때문에, 가드는 인식할 수 없는 이름을 수신하고 스폰을 일반 작업으로 처리했습니다: 게이트 검토자는 수동 QA 아티팩트 없이 시작할 수 있었고, 검토자별 진행률 없음 상한선은 계산을 중단했습니다. 두 검사가 다시 적용되며, 두 표기법이 인식되므로 이전 검토자를 명시한 아무것도 중단되지 않습니다. 거부 메시지와 스폰 카운터는 이제 실제로 실행된 검토자 이름을 지정합니다.
하나의 Windows 전용 테스트 불안정성은 이 릴리즈에서 수정되지 않았습니다. 느린 Windows CI 러너에서, senpi-task(store.test.ts)의 DAG 잠금 테스트는 이전 실행이 잠금을 지우는 동안 충돌했을 때 여전히 Timed out acquiring DAG lock으로 실패할 수 있습니다. 수정(#8672)은 5.0.0-beta.84에서 제공됩니다. Windows에서 남은 잠금 파일을 지우는 방법만 변경됩니다. 이 빌드의 아무것도 사용자에게 다르게 작동하지 않습니다.
분량 관계로 이후 내용은 번역에서 제외했습니다. 전체 내용은 위 원문 링크에서 확인하세요.