掘金2026년 11월 5일 18:08중국어 → 한국어

HiRoute 새 버전, 실제 작업 방식에 맞춰 최적 모델 선택 지원

로컬에서 실행되는 오픈소스 에이전트 스마트 라우팅 엔진 HiRoute가 자신의 실제 작업에 맞춰 최적 모델을 고르는 새 버전을 공개했다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

이 글은 오픈소스 프로젝트 Alibaba Cloud AI Agent Handbook에 수록되었으며, 더 나은 읽기 경험을 원하시면 다음에서 확인할 수 있습니다: aliyun.github.io/ai-agent-ha…

최근 몇 주마다 거의 새 모델이 출시되고 있는데, 가격은 주력 모델의 몇 푼 수준인데도 범용 점수는 이미 상당히 근접해 있다. Epoch AI가 올해 9월에 발표한 보고서 《The plunging price of thought》는 2023년 이후 동일한 능력 수준에 도달하는 비용이 평균적으로 분기마다 약 47%씩 하락했다고 추산했다. 저렴하고 충분히 쓸 만한 모델은 갈수록 많아질 뿐이고, 진짜 어려워진 것은 두 가지 일이 되었다. 바로 내 업무에서 어떤 단계를 모델에게 맡길 수 있는지, 그리고 하나의 작업을 어떤 Agent에게 맡겨야 하는지다.

HiRoute [1]는 오픈소스로 로컬에서 실행되는 Agent 지능형 라우팅 엔진이다. 사용자는 계속 Codex, Claude Code, Qoder, Pi, OpenCode, Hermes, DeepSeek Harness 등 익숙한 Agent를 사용하고, HiRoute가 각 단계를 어떤 모델에 맡길지 판단한다. 이번 업데이트는 위의 두 가지 일을 중심으로 이루어졌다.

- 새 모델은 쓰면서 평가 : 홈페이지의 「새 모델」에서 시험 사용을 시작하고, 신뢰도는 연속적으로 조정할 수 있다. 모델 성과 보고서는 사용자 자신의 작업 속 증거를 바탕으로 신뢰도를 올리거나 내리도록 제안하며, 리플레이로 확인한 뒤 공개한다.

- System One의 매 라운드 세 가지 질문 : 이전 단계를 되돌아보고, 이번 단계를 판단하며, 다음 단계를 지킨다. 논문의 검토 부분집합에서 두 결정 모델은 공학과 수학 시나리오에서 선정 그룹 정확도가 모두 뚜렷이 향상되었다. 결정 모델에 OpenAI Decisions를 새로 추가했으며, 기존의 바이롄(百炼), OpenAI 또는 OpenRouter 연결을 그대로 재사용할 수도 있다.

- 작업을 적합한 Agent에게 맡김 : 라우팅 계획에 실행 Agent를 바인딩할 수 있다. Hermes에는 모델 라우팅과 작업 라우팅을 새로 추가했고, OpenCode는 작업을 위임할 수도 있고 실행 Agent가 될 수도 있다. Hermes와 HiRoute를 함께 쓰면 DeepSeek이 최근 제안한 Super Agent 아키텍처와 유사한 구조를 만들 수 있다.

- 세 플랫폼 모두 그래픽 인터페이스 제공 : Windows 데스크톱 버전을 처음으로 출시했고, Linux에서는 브라우저에서 동일한 인터페이스를 사용할 수 있다.

- 그 밖의 개선 : 구독과 API 동시 연결, API Key 지출 한도, 연결별 프록시 설정, 더 적은 공간을 쓰는 로컬 기록.

매 단계 재판단: 복잡한 작업에도 간단한 일이 있다

흔한 방법은 시나리오별로 분업하는 것이다. 코드 작성에는 강한 모델을 붙이고, 자료 정리에는 저렴한 모델을 붙인다. 서로 다른 시나리오가 요구하는 능력이 실제로 다른 것은 맞지만, 실제 대화에서 우리는 난이도가 단계마다 변한다는 것을 확인했다. 복잡한 시나리오에도 간단한 일이 대량으로 있고, 간단한 시나리오에서도 갑자기 어려운 문제가 튀어나온다.

우리는 기술 선정 비교 실험을 한 번 진행했다. 먼저 여섯 가지 후보 기술을 조사하고 공식 자료를 검증한 뒤, 마지막에 핵심 방안의 의사결정 메모를 작성하는 것이다. 자료 정리는 저렴한 모델에 맡기고 핵심 판단은 주력에 맡겼더니, 핵심 판단의 품질은 전 과정을 주력으로 처리한 것과 같았고 전체 작업 비용은 후자의 약 12분의 1에 불과했다. 반대로 전 과정을 저렴한 모델로 처리하자 자료 정리는 나쁘지 않았지만, 세 번의 핵심 판단 중 두 번에서 중대한 오류가 발생했다.

그림 1: 동일한 검수 기준 아래의 전체 작업 비용 비교

그래서 HiRoute의 분업은 이렇다. 시나리오가 어떤 후보 모델이 있는지, 어떤 기준으로 검수할지를 결정하고, 매 단계에 어떤 모델을 쓸지는 이 단계에 이르러서 판단한다. 전환은 사용자가 새 메시지를 보내거나 컨텍스트가 압축 또는 재구성될 때만 발생하며, 같은 라운드 안의 도구 호출은 늘 동일한 모델을 사용하고, 전환 후에는 첫 번째 요청만 캐시를 놓친다.

자세한 내용은 실전 사례와 모델 전환과 캐시의 비용 분석을 참고하기 바란다.

아래는 실제 대화의 화면 녹화 한 편이다. 왼쪽은 DeepSeek Harness, 오른쪽은 HiRoute이며, 라우팅 계획은 DeepSeek V4.1 Flash를 시험해 볼 새 모델로, GPT-6 Astra를 주력으로 삼았다. 사용자는 Agent에서 평소처럼 요구사항만 제시했고, 처음부터 끝까지 모델을 수동으로 바꾼 적이 없다.

원본 영상은 공식 계정 원문에서 볼 수 있다: 오픈소스 모델 지능형 라우팅 #HiRoute.

테스트를 보충하고 설계 트레이드오프를 논의하는 이 두 라운드는 그렇게 간단하지 않아 주력이 처리했다. 첫 라운드의 21회 호출은 모두 같은 모델에 머물렀고, 캐시 적중률은 거의 90%였다.

사용 설명 한 단락을 작성하는 것은 충분히 간단하므로 새 모델에 맡겼다.

사용자가 이 버전은 기능 소개처럼 읽힌다고 말했다. 이전 단계의 점수는 0.32였고, 이 문제는 이어지는 개작과 직접 관련이 있어 저점 보호가 작동해 주력이 이어받았다.

개작 후 버전의 점수는 0.83이었고 문제가 해결되었으며, 다음 단계인 데이터 내보내기는 다시 새 모델로 돌아갔다.

그림 2: 대화 타임라인이 매 라운드에 어떤 모델을 썼는지, 왜 그렇게 선택했는지를 기록한다.

새 모델: 내 업무 속에서 쓰면서 평가하기

각종 평가와 순위표는 1차 선별에는 적합하지만, "이 모델이 내 업무에서 되는가"라는 질문에는 답하지 못한다. Scale AI가 작년 9월에 발표한 SWE-Bench Pro가 그 예이다. SWE-bench Verified에서 70% 이상의 문제를 해결할 수 있는 상위 모델도 SWE-Bench Pro의 공개 문제에서는 23% 정도에 불과했고, 스타트업의 비공개 코드베이스로 바꾸면 최고 성적이 다시 17.8%로 떨어졌다.

문제 자체가 더 어려워서 앞부분의 격차를 전부 "못 봤기 때문"으로 돌릴 수는 없지만, 공개 문제와 비공개 문제는 동일한 방법으로 구성되었기에 뒤쪽의 격차가 문제를 더 잘 설명해 준다. 당신의 코드베이스야말로 모델에게는 바로 못 본 비공개 코드인 것이다.

새 모델이 너무 빨리 나오기에 새 모델이 나올 때마다 전용 평가 세트를 만드는 것은 불가능하다. 우리의 구상은 쓰면서 평가하는 것이다. 먼저 충분히 간단한 단계를 새 모델에 맡기고, 매 단계가 끝날 때마다 결과를 확인하고, 문제가 생기면 주력이 이어받으며, 증거가 쌓이면 점차 더 많이 맡기는 것이다. 이번 업데이트는 이 경로를 완성했다.

- 홈페이지에서 시험 사용 시작 : 홈페이지의 「새 모델」이 추천 새 모델을 보여 준다. 시험해 볼 새 모델과 익숙한 주력을 선택해 당신의 Agent에 매핑하면, 공개 전에 모든 변경 사항을 나열해 준다. Agent에서 쓰는 모델명은 바뀌지 않으므로 Agent 설정을 고칠 필요가 없다.

- 신뢰도 연속 조정 : 신뢰도란 곧 난이도 문턱으로, 오른쪽으로 갈수록 더 많은 간단한 작업을 새 모델에 맡긴다. 시험 사용, 익숙, 신뢰, 방임, 위탁의 다섯 단계 외에도 어느 위치에서든 멈출 수 있다.

- 주력이 언제든 이어받음 : 새 모델의 어느 단계 점수가 역량 하한보다 낮고 그 문제가 여전히 이어지는 작업과 관련이 있을 때, 저점 보호가 작동해 주력이 이어받는다. 문제가 더 이상 관련이 없으면 난이도에 따른 선택으로 돌아간다.

그림 3: 새 모델 신뢰도 설정

"이 단계를 잘했는가"를 판단할 때 가장 직접적인 증거는 사용자의 다음 메시지에 있다. 이전 단계의 결과를 명백히 부정하는 것은 해내지 못했다는 증거이고, 그저 다음 일을 이어서 지시하거나 아무 말도 하지 않는 것은 실패를 의미하지 않는다. 이번 업데이트는 점수가 실제 피드백에 더 가까워지도록 했다. 명확한 인정을 식별하고, 부분 긍정과 완전 통과를 구분하며, 부분적으로 쓸 수 있는 진전도 반영한다.

한동안 사용하면 모델 성과 보고서가 단계별 점수, 새 모델이 담당한 비율과 비용 추정을 집계한다. 단일 점수에는 오차가 있을 수 있으므로 신뢰도 조정은 충분히 많은 증거를 보고 판단해야 한다:

상향 조정 권고: 지난 조정 이후 최소 3개 이상의 세션에서 최소 30개의 완전한 평가 단계가 쌓였고, 평가가 육할 이상을 커버하며, 그중 85% 이상이 역량 기준선에 도달한 경우.

하향 조정 권고: 최소 30개의 완전한 평가 단계 중 기준을 충족한 단계가 70% 미만인 경우.

그림 4: 각 규칙의 실제 값과 요구 조건을 나란히 나열하고, 기록에 따라 조정 후의 효과를 재생한다. 비용은 API 환산 추정치다.

상향 조정의 문턱은 하향 조정보다 높다. 이는 의도된 것으로, 간혹 몇 번 잘했다고 해서 더 많이 손을 놓을 수는 없고, 문제가 충분히 뚜렷할 때는 거둬들이는 것이 더 신속해야 한다. 권고는 어디까지나 권고일 뿐이며, 배포 전에는 라우팅을 바꾸지 않고, 현재 단계를 유지하는 것도 정상적인 선택이다. 「Agent」에서 일상적으로 사용하는 Agent에 대해 「HiRoute 관리」를 켜면, 모델 성과 보고서와 조정 권고를 직접 읽게 할 수도 있다. 정기적인 재검토가 필요하면 Agent 자체의 예약 작업에 맡기면 된다.

System One: 매 라운드 단 세 가지 질문만

위의 판단은 매 라운드마다 해야 한다. 가장 직접적인 방법은 작업, 이력, 라우팅 정책을 모두 의사결정 모델에 넘기고 "이 단계에서는 어떤 모델을 써야 하는가"라고 묻는 것이다. 우리가 시도해 본 결과, 이는 안정적이지 않았다. 작업 난이도, 과거 성과, 문제가 해결되었는지 여부, 정책이 어떻게 규정되어 있는지를 동시에 저울질해야 하는데, 어느 하나라도 판단이 어긋나면 결론도 틀리게 된다.

System One은 이를 세 가지 독립적인 질문으로 나누어, 한 번의 요청 안에서 각각 답하게 한다:

그림 5: System One의 매 라운드 세 가지 질문

이전 단계 · 되돌아보기: 어떻게 했는가? 역량 점수를 제시하며, 동시에 모델 성과 보고서에 집계된다.

이번 단계 · 현재: 얼마나 어려운가? 단순 확률을 제시하며, 충분히 단순한 작업만 경제 모델에 맡길 수 있다.

다음 단계 · 앞을 보기: 이전 단계의 문제가 다음 단계로 이어질 것인가? 다음 단계의 성공 가능성을 예측하는 것이 아니라, 알려진 미해결 문제가 여전히 적용되는지를 판단한다.

의사결정 모델은 질문에 답만 하고, 임계값과 그룹 선택, 실행은 모두 HiRoute가 담당한다. 신뢰도를 조정하는 것은 임계값을 바꾸는 것이지 질문 자체를 바꾸는 것이 아니다. 이번 업데이트부터 세 번째 질문이 기본 판단의 일부가 된다. 이전 단계를 잘하지 못했고 문제가 이어질 경우 주력이 맡고, 문제가 해결되었거나 더 이상 관련이 없으면 보호를 해제한다.

우리는 이 메커니즘을 논문으로 작성해 중국어·영어 데이터셋, 원본 모델 응답, 오프라인 재현 도구를 공개했다. 실험에서 두 가지 방법은 동일한 작업 컨텍스트와 완전한 라우팅 정책을 읽는다. 하나는 모델 그룹을 직접 고르고, 다른 하나는 세 가지 질문에 답한 뒤 HiRoute가 조합하여 판단한다.

그림 6: 검토 하위 집합의 최종 그룹 선택 정확도

이 데이터에서 한 가지는 좀 더 언급할 만하다. 두 의사결정 모델이 직접 그룹을 고를 때 오류의 방향이 정반대였다. 수학 시나리오에서 Jev 1.14는 대담한 쪽으로 치우쳐, 보호가 필요한 24개 기록 중 6개만 맞혔다. OpenAI Decisions는 보수적인 쪽으로 치우쳐, 보호를 해제해야 하는 16개 기록 중 2개만 맞혔다. 세 가지 질문으로 바꾼 뒤, Jev 1.14의 24개 보호는 모두 맞혔고 16개 해제도 전부 맞혔으며, OpenAI Decisions의 해제는 14개로 올라갔고 보호는 24개에서 22개가 되었다.

방향이 반대인 두 가지 편향이 같은 방식의 분해로 모두 뚜렷하게 억제되었다.

비용과 지연도 문제가 아니다. Jev의 실제 과금 기준으로 1,000회당 세 가지 질문 의사결정은 약 0.084–0.086달러이며, 연결 수립을 제외하면 실측 의사결정 소요 시간의 중앙값은 0.5초에서 1초 사이로, 매 라운드 다시 판단하는 비용을 감당할 수 있다.

밝혀 둘 것은, 이 데이터가 측정하는 것은 "선언된 정책대로 모델 그룹을 맞게 골랐는가"이지 작업 완료율도, 실제로 절약한 비용도 아니라는 점이다. 이 비교는 출력을 확인한 뒤 검토한 하위 집합을 사용했고, 모든 모델과 두 방법은 동일한 제외 목록을 사용하며, 향상 폭도 의사결정 모델과 시나리오에 따라 다르다. OpenAI의 결과는 실험의 연구 어댑터에서 나온 것으로, 내장 OpenAI 연결의 성능을 대표하지 않는다.

전체 데이터, 제외 목록, 한계는 논문 [2]를 참조하라.

의사결정 모델의 연결도 더 유연해졌다:

OpenAI Decisions를 새로 추가했으며, 내장 연결은 바이롄(百炼), OpenRouter Jev, TypeSafe 및 호환 접속점도 지원한다.

기존 API 연결 재사용: OpenAI, OpenRouter, 그리고 바이롄의 Token Plan과 워크스페이스 연결은 일반 모델과 Key를 공유할 수 있으며, TypeSafe와 기타 호환 접속점은 여전히 주소와 Key를 별도로 입력할 수 있다.

의사결정 컨텍스트는 모델 윈도에 따라 배분: 알려진 모델은 공식 자료를 따르며, 직접 상한을 설정할 수도 있다. 현재 입력과 세 가지 질문은 항상 완전히 유지하고, 그 위에 최근의 완전한 단계를 가능한 한 많이 넣는다.

작업 라우팅: 각 작업을 적합한 Agent에 맡기기

모델 라우팅은 "이 단계에서 어떤 모델을 쓸지"를 정하고, 작업 라우팅은 "이 작업을 어떤 실행 Agent에 맡길지"를 정한다. 각 라우팅 계획은 어떤 종류의 작업에 적합한지 명시하고, 실행 Agent 하나를 바인딩할 수 있다: Codex CLI, Claude Code, Qoder CLI, Pi, DeepSeek Harness 또는 OpenCode. 실행 시 이 Agent의 매 라운드는 여전히 계획의 모델 라우팅에 따라 경제 그룹과 주력 그룹 사이에서 판단한다.

이번 업데이트에서:

Hermes는 자신의 모델 요청을 HiRoute에 연결할 수 있고, 작업 라우팅을 켜서 이미 배포된 계획을 위임할 수도 있다.

OpenCode는 일상적으로 사용하는 Agent로서 작업을 위임할 수도 있고, 실행 Agent로도 쓸 수 있다.

실행 Agent는 본 기기에 실제 설치된 능력으로 사용 가능 여부를 확인하며, 실행 실패 원인은 있는 그대로 남긴다. CLI도 위임 설정에서 무엇이 빠졌는지, 예컨대 계획의 사용 시나리오 등을 직접 지적한다.

DeepSeek Harness 팀은 10월 31일 장문 《Super-agent 설계 탐구: 더 자율적인 Agent 시스템을 향하여》를 발표하고 연구 프로토타입 dsh-superagent-prototype [3]을 오픈소스로 공개했다.

그것은 시스템을 두 계층으로 나눈다. 상주하는 Router는 대외 소통, 전역 조정, 작업 분배를 담당하며 스스로는 작업을 전혀 실행하지 않을 수 있다. Worker는 격리된 컨텍스트에서 단일 작업 실행에 집중하고, 결과를 Router에 돌려보내 통일적으로 응답한다. 이렇게 하면 Router가 항상 새 메시지에 신속히 응답할 수 있어, 어떤 장기 작업에도 막히지 않는다. 글의 출발점은 매우 현실적이다. 한 사람이 동시에 돌볼 수 있는 Agent 세션은 대략 세에서 다섯 개뿐이라, 사람의 주의력이 병목이 되었다.

유사한 아키텍처는 HiRoute의 기존 능력만으로도 구축할 수 있으며, Super Agent용 라우팅 메커니즘을 따로 새로 만들 필요가 없다:

그림 7: Hermes와 HiRoute의 Super Agent 아키텍처

personal agent가 Router 역할: Hermes는 HiRoute에서 바로 작업 라우팅을 켤 수 있고, OpenClaw 등 다른 personal agent도 본 기기에서 명령줄을 실행할 수 있기만 하면 동일한 명령 세트를 호출할 수 있다.

`hiroute worker exec`로 위임하기: 작업, 작업 디렉터리, 검수 요구 사항을 hiroute worker exec에 넘깁니다. `--no-wait`을 붙이면 작업이 접수되는 즉시 반환되고, Router는 곧바로 대화로 돌아갑니다. 여러 작업은 병렬로 실행할 수 있습니다.

작업이 끝나면 자동으로 보고: Hermes를 예로 들면, 제출한 뒤 백그라운드 프로세스에서 작업이 끝날 때까지 계속 기다리며 자체 notify_on_complete를 켜 둡니다. 작업이 끝나면 이 프로세스가 종료되고, Hermes가 깨어나 결과를 가져와 대화에서 알려 줍니다.

실행 Agent를 지정할 수 있음: 자료 수집 같은 경량 작업은 Pi에 바인딩된 계획에, 엔지니어링 코드 개발은 Qoder CLI에 바인딩된 계획에, 코드 리뷰는 Codex CLI에 바인딩된 계획에 맡깁니다. 위임할 때 계획을 직접 지목할 수도 있고, Router가 각 계획에 적힌 용도에 따라 알아서 고르게 할 수도 있습니다.

자료 수집을 Pi에 바인딩된 계획에 맡기고, 제출 후 즉시 반환 hiroute worker exec --plan <PLAN_ID> --cwd /work/mq-research --no-wait \ -- "세 가지 메시지 큐의 공식 문서와 릴리스 노트를 수집해 비교표로 정리" # 언제든 진행 상황 확인, 작업 종료 후 결과 가져오기 hiroute worker status --run <RUN_ID> hiroute worker result --run <RUN_ID>

Router는 의도 이해, 작업 분배, 결과 취합만 담당하며, 각 실행 Agent가 얼마나 비싼 모델을 쓸지는 그 Agent가 속한 계획이 매 라운드 판단합니다. Hermes로 구축하는 전체 과정은 《Hermes와 HiRoute로 DeepSeek식 Super Agent 구축하기》 [4]를 참고하십시오.

macOS, Windows, Linux 모두 GUI 제공

macOS: 데스크톱 앱으로, macOS 15 이상, Apple 칩과 Intel을 지원합니다.

Windows: 데스크톱 버전이 처음 출시되었습니다. x64 설치 패키지는 현재 사용자 기준으로 설치되며, 명령줄, 백그라운드 서비스, WebView2 부트스트랩 설치 프로그램이 포함되어 있고 Python이나 관리자 권한이 필요하지 않습니다. 앱에서 업그레이드할 때는 진행 중인 호출과 Worker 작업이 끝날 때까지 기다린 뒤 설치합니다.

Linux: x86_64와 ARM64를 지원하며, 현재 사용자 디렉터리에 설치되고 sudo가 필요하지 않습니다. 브라우저에서 여는 것은 데스크톱 버전과 동일한 인터페이스입니다. 서버에는 데스크톱이 필요 없으며, `hiroute console open`이 로그인 링크를 생성합니다.

``` curl -fsSL https://hiroute.ai/install.sh | sh -s -- --console-mode loopback --console-port 5838 hiroute service start --output json hiroute console open ```

추가 개선 사항

▍ 구독과 API를 함께 연결

Codex 또는 Claude 구독을 연결할 때, 대응하는 OpenAI 또는 Anthropic API Key를 함께 입력할 수 있습니다. 모델을 한 번 선택하고 한 번 저장하면, 양쪽의 모델이 동시에 가져와집니다.

구독에 딸린 API 크레딧을 바로 활용할 수 있습니다. 조건을 충족하는 ChatGPT Pro / Business와 Claude Max / Ultra / Team은 청구 주기마다 API 크레딧을 받을 수 있으며, 다 쓰지 못한 크레딧은 이월되지 않습니다(OpenAI [5] 및 Anthropic [6]의 공식 설명 참조).

여기에는 크레딧을 받는 조직의 Key를 입력한 뒤, 모델 상세에서 구독 모델용 라우트를 생성합니다. HiRoute는 API에서 같은 이름의 모델을 발견하여 후보에 함께 추가할 수 있습니다. 이렇게 하면 구독과 API의 같은 이름 모델이 하나의 모델로 구성됩니다. Agent는 모델 이름 하나만 사용하고, HiRoute는 구독을 먼저 사용하며, 구독을 일시적으로 쓸 수 없을 때 자동으로 이어서 API를 사용합니다.

▍ API Key에 지출 한도 설정

일회성 한도, 달력 주기별 보충, 또는 여러 Key가 한도의 일부를 공유하도록 설정할 수 있습니다. HiRoute는 요청을 전달하기 전에 먼저 예약하고, 완료 후 정산합니다. 금액은 HiRoute가 전달한 트래픽을 기준으로 추정하며, 공급자의 계정 잔액이 아닙니다. 크레딧 관리에도 적합합니다. 크레딧 금액에 맞춰 해당 Key에 월별 보충 한도를 설정해 두면, 다 쓴 뒤에는 이 Key가 건너뛰어집니다.

▍ 연결별 프록시 설정

각 API 연결은 직접 연결, 백그라운드 서비스의 환경 프록시 사용, 또는 HTTP(S) 프록시와 우회 규칙 수동 입력 중에서 선택할 수 있으며, 이 연결을 공유하는 의사결정 모델도 같은 설정을 따릅니다.

▍ 로컬 기록의 공간 절약

긴 세션에서 더 이상 전체 요청 스냅샷과 프로토콜 로그를 반복 저장하지 않고, 이력 조회, 평가, 모델 귀속에 필요한 내용만 보관합니다. 로컬 기록은 기본적으로 최대 20 GB를 차지하며, 조정하거나 끌 수 있고, 7일 보존 기간은 평소대로 적용됩니다.

▍ 모델 자료 별도 업데이트

컨텍스트 윈도우 등 공식 모델 자료와 홈페이지의 신규 모델 추천은 HiRoute의 모델 카탈로그를 통해 별도로 배포되므로, 앱 업그레이드를 기다릴 필요가 없습니다.

▍ 로컬 실행, 오픈 소스

HiRoute는 당신의 컴퓨터나 서버에서 실행되며, Apache-2.0 라이선스를 사용합니다.

시작하기

모델 연결: 지원되는 구독 또는 API를 추가하고, 경제 모델과 주력 모델을 선택합니다.

역할 분담 설정: 「모델 → 의사결정 모델」에서 의사결정 서비스를 연결하고, 신뢰도를 선택한 뒤, 게시하고 Agent에 매핑합니다.

평소처럼 작업: 기존 Agent에서 계속 사용하고, HiRoute에서 모델 전환과 모델 성능 리포트를 확인합니다. 작업을 위임해야 할 때는 스마트 작업 라우팅 [7]을 참고하여 계획에 실행 Agent를 선택합니다.

HiRoute는 완벽하지 않으며, 의사결정 모델도 판단을 틀릴 수 있습니다. 자신의 시나리오에서 한번 시험해 보시고, 어디서 판단을 잘못했는지도 알려 주시기 바랍니다.