저는 Claude Code, Hermes Agent, OpenClaw, 그리고 OpenCode를 실행하면서 모든 긴 세션이 API 비용으로 이어지는 것을 방지하고 싶었습니다. 그 해답은 또 다른 구독이 아니었습니다. 그것은 수십 개의 무료 추론 허용량 (inference allowances)을 하나의 풀 (pool)처럼 작동하게 만드는 것이었습니다.

무료 추론은 이미 생태계 전반에 흩어져 있었습니다. 개별 제공업체들은 유용한 허용량을 제공했지만, 각기 다른 엔드포인트 (endpoint), 자격 증명 (credentials), 모델 (models), 할당량 (quotas), 그리고 초기화 일정 (reset schedule)을 가지고 있었습니다. 어떤 하나의 허용량이라도 쉽게 소진될 수 있었습니다. 이들을 합치면 상당한 용량을 나타내지만, 수동으로는 효율적으로 사용할 수 없었습니다.

저는 이러한 제공업체들을 하나의 로컬 엔드포인트 (local endpoint) 뒤에 배치하기 위해 OmniRoute를 설치했습니다. 그런 다음 가용성과 속도를 기준으로 정렬된 조합을 통해 저의 코딩 에이전트 (coding agents)를 라우팅했습니다. 제가 추적한 사용량은 결국 10억 토큰을 넘어섰고, 추론 (inference)에 쓴 비용은 0달러였습니다.

이 결과에는 맥락이 필요합니다. 저는 무제한 토큰을 무료로 제공하는 단일 제공업체를 찾은 것이 아닙니다. 저는 작고 큰 여러 허용량을 결합했고, 활성 모델 (active model)이 변경될 수 있음을 수용했으며, 무료 추론을 영구적인 권리가 아닌 라우팅 문제 (routing problem)로 취급했습니다.

제가 OmniRoute를 시도한 이유

OmniRoute를 사용하기 전에는, 모든 무료 제공업체가 유지 관리해야 할 또 다른 통합 (integration)을 만들어냈습니다. 어떤 클라이언트가 어떤 API 형식을 지원하는지, 어떤 키가 여전히 작동하는지, 어떤 모델이 현재 사용 가능한지, 그리고 요청 실패가 일시적인 속도 제한 (rate limit)을 의미하는지 아니면 할당량 소진을 의미하는지를 기억해야 했습니다.

제공업체가 두 개라면 관리할 수 있습니다. 하지만 수십 개가 되면 지루해집니다.

OmniRoute는 로컬 서버를 실행하고 http://localhost:20128/v1에서 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 노출합니다. 현재의 quick start는 npm install -g omniroute를 실행한 후 omniroute를 사용하는 방식입니다. OpenAI API 형식을 이해하는 클라이언트들은 모든 업스트림 제공업체 (upstream provider)에 개별적으로 연결하는 대신 로컬 엔드포인트로 연결할 수 있습니다.

저는 이것을 저의 Mac mini M4에 호스팅했습니다. 하드웨어는 흥미로운 부분이 아니었습니다. 유용한 변화는 아키텍처 (architectural) 측면에서 일어났습니다. 이제 저의 에이전트 (agents)들은 하나의 게이트웨이 (gateway)와 통신하며, 게이트웨이는 그 뒤에서 변화하는 제공업체 풀 (provider pool)을 관리합니다.

이 프로젝트는 현재 290개의 제공업체와 90개 이상의 무료 옵션을 홍보하고 있습니다. 하지만 그 마케팅 수치가 독립적으로 문서화된 할당량 풀 (quota pools)과 동일한 것은 아닙니다. 프로젝트의 더 보수적인 무료 티어 장부 (free-tier ledger)에는 50개의 제공업체 무료 티어 풀이 나열되어 있으며, 자체 가정을 바탕으로 월간 약 19억 4천만 개의 무료 토큰을 추산합니다. 장부에서는 이 수치들을 약속된 용량이 아닌 상한선 추정치로 표기하며, 독자들에게 이를 신뢰하기 전에 제한 사항을 확인할 것을 권고합니다.

저는 위에서 언급된 두 수치 중 어느 하나를 기준으로 설정을 설계하지 않았습니다. 저는 제가 사용할 수 있는 무료 소스들을 연결했고, 라우팅 (routing)이 불균등한 제한 사항들을 흡수하도록 두었습니다.

제공업체 풀을 구축한 방법

저는 OmniRoute가 즉시 노출할 수 있는 무료 제공업체들로 시작하여, 나머지 풀에 필요한 계정들과 자격 증명 (credentials)들을 추가했습니다. OpenRouter와 OpenCode와 관련된 무료 옵션들이 많은 소규모 소스들과 함께 그 일부로 포함되었습니다.

이것들은 동일한 토큰들이 담긴 교체 가능한 바구니가 아닙니다. OmniRoute 장부에는 분당 토큰 (tokens per minute), 일일 요청 수 (requests per day), 일일 토큰 제한 (daily token limits), 월간 크레딧 (monthly credits), 체험 잔액 (trial balances), 그리고 GPU 시간 허용량 (GPU-time allowances)이 혼합되어 있습니다. 어떤 것들은 빠르게 초기화됩니다. 어떤 것들은 더 오래 지속되지만 체험 기간이 지나면 사라집니다. 다른 것들은 가용성 (availability)이 덜 예측 가능하지만 계속 무료로 유지됩니다.

그러한 혼합이 바로 풀링 (pooling)이 작동하는 이유입니다. 주 용도로 쓰기에는 너무 작아 보이는 일일 허용량이라도, 다른 제공업체가 한도에 도달했을 때 여전히 요청을 처리할 수 있습니다. 더 느린 모델은 백그라운드 작업 (background task)을 계속 진행할 수 있게 해줍니다. 제한된 체험판은 일시적인 폭증 (burst)을 흡수할 수 있습니다. 제한 사항들이 모두 동시에 작동을 멈추지 않기 때문에 결합된 시스템은 유용합니다.

이것이 제가 이 결과를 '무제한 추론 (unlimited inference)'이라고 설명하지 않는 이유이기도 합니다. '거의 연속적인 (Near-continuous)'이라는 표현이 더 정확합니다. 할당량 (quota)이 사라졌기 때문이 아니라, 다른 경로가 보통 사용 가능했기 때문에 제 워크로드에 대해 풀 (pool)이 유용하게 유지된 것입니다.

실제 라우팅 작동 방식

저는 가용성과 속도에 따라 타겟을 우선순위화하는 조합을 만들었습니다. 선호하는 경로를 사용할 수 없거나 소진되면, OmniRoute는 제가 각 에이전트 (agent)의 설정을 일일이 수정하도록 강제하는 대신 남은 타겟들을 통해 이동합니다.

이러한 동작은 무작위 키 로테이션 (random key rotation)보다 더 의도적입니다. OmniRoute의 문서화된 할당량 로직은 선택 전에 소진된 연결을 필터링하는 반면, 콤보 (combo)는 실패한 타겟을 건너뛰고 다음 사용 가능한 경로를 시도하는 순서가 정해진 폴백 체인 (fallback chain)입니다. 사용 가이드에 따르면 각 요청 레코드에는 제공자 (provider), 모델 (model), 토큰 수 (token counts), 계산된 비용 (computed cost), 지연 시간 (latency), 그리고 상태 (status)가 포함됩니다. 또한 할당량 스냅샷 (quota snapshots)과 리셋 정보도 유지합니다.

그러한 텔레메트리 (telemetry)는 저에게 피드백 루프 (feedback loop)를 제공했습니다. 어떤 제공자가 실제로 트래픽을 처리하고 있는지, 어떤 경로가 실패하고 있는지, 그리고 소위 무료라고 여겨진 경로에서 비용이 발생했는지 여부를 확인할 수 있었습니다. OmniRoute는 사용량, 할당량, 비용 요약도 제공하므로 대시보드 (dashboard)에만 의존할 필요가 없었습니다.

저는 여전히 무엇을 가치 있게 여길지 결정해야 했습니다. 대화형 코딩 (interactive coding)의 경우, 흐름을 유지할 수 있는 응답성이 좋은 경로를 선호했습니다. 자율적 (autonomous)이거나 백그라운드 작업의 경우, 작업이 계속 실행될 수 있다면 더 느린 제공자도 용인할 수 있었습니다. 단일한 글로벌 순위 (global ranking)는 터미널에서 대기할 때와 에이전트가 무인으로 작업할 때 지연 시간 (latency)이 갖는 의미가 다르기 때문에 덜 유용했을 것입니다.

비용 0달러로 추적된 10억 개의 토큰이 의미하는 것

나의 OmniRoute 사용량 보고서는 결국 10억 개의 토큰을 돌파했으며, 비용 보고서에는 이 실험의 트래픽에 대해 0달러로 표시되었습니다. OmniRoute는 제공업체가 보고한 토큰 수(token counts)가 있는 경우 이를 기록하고, 상위(upstream) 응답에 포함되지 않은 경우 사용량을 추정합니다. 따라서 이 총계는 로컬 텔레메트리(telemetry) 수치이며, 감사된 제공업체의 인보이스(invoice)나 다른 사용자가 내 결과를 재현할 수 있다는 약속은 아닙니다.

몇 가지 조건이 이를 가능하게 했습니다. 나는 유료 폴백(fallback)을 몰래 섞어 쓰는 대신 무료 경로(free routes)를 사용했습니다. 하나의 계정이 모든 워크로드를 감당하기를 기대하는 대신 광범위한 제공업체 세트를 연결했습니다. 또한 여러 코딩 도구를 실행했기 때문에, 총량에는 최종 답변에 보이는 텍스트보다 훨씬 더 많은 양이 포함되었습니다. 에이전트 루프(Agent loops)는 저장소 컨텍스트(repository context), 도구 결과, 계획, 수정 사항 및 생성된 코드를 반복적으로 전송합니다. 긴 자율 세션(autonomous sessions)은 인간에게 보이는 출력이 겸손해 보일 때조차도 대량의 토큰 볼륨을 소비할 수 있습니다.

이 수치를 동일하게 가치 있는 10억 개의 토큰으로 해석해서는 안 됩니다. 모델마다 코딩 능력, 컨텍스트 처리(context handling), 도구 사용(tool use), 속도 및 신뢰성이 다릅니다. 변화하는 풀(pool)을 통해 라우팅된 10억 개의 추적된 토큰은, 하나의 안정적인 프리미엄 모델로부터 제공업체가 청구한 10억 개의 토큰과 동일하지 않습니다.

추론(inference) 비용이 0달러라는 것이 총비용이 0달러라는 의미도 아닙니다. 나는 계정을 생성하고, 자격 증명(credentials)을 추가하고, 실패를 지켜보고, 우선순위를 조정하는 데 시간을 소비했습니다. 나는 이미 비용을 지불한 하드웨어와 인터넷 연결에서 게이트웨이(gateway)를 실행했습니다. 추적된 추론 지출은 0이었지만, 시스템에는 여전히 유지보수와 인프라가 필요했습니다.

가장 어려운 문제는 모델 드리프트(model drift)였다

가장 큰 약점은 라우팅이 내가 요청한 대로 정확히 작동할 때 나타났습니다.

요청이 하나의 무료 모델에서 다른 모델로 이동하면, 에이전트의 동작이 갑작스럽게 변할 수 있습니다. 어떤 모델은 저장소 지침을 주의 깊게 따르지만 도구 사용에는 신중할 수 있습니다. 다른 모델은 더 광범위한 편집을 수행하면서 더 빠르게 동작할 수 있습니다. 세 번째 모델은 긴 컨텍스트(long context)로 인해 어려움을 겪거나 다른 스타일의 계획을 반환할 수도 있습니다.

OpenRouter의 공식 free router는 이러한 트레이드오프(tradeoff)를 명확하게 보여줍니다. 이 라우터는 호환 가능한 무료 모델들을 필터링한 다음, 해당 풀(pool)에서 하나를 무작위로 선택합니다. 문서에 따르면 무료 모델의 가용성은 변동될 수 있고, 속도 제한(rate limits)이 더 낮을 수 있으며, 수요가 몰리는 피크 시간대에는 지연 시간(latency)이 증가할 수 있습니다. 또한 사용자는 라우터에 의해 선택되는 정확한 모델을 제어할 수 없습니다.

OpenCode는 이와 관련된 또 다른 변화의 원인을 만듭니다. OpenCode 자체는 코딩 클라이언트(coding client)이며, OpenCode Zen은 선택 사항인 모델 게이트웨이(model gateway)입니다. Zen은 여러 무료 모델을 나열하고 있지만, 문서에서는 이들 중 일부를 피드백을 수집하는 동안 한시적으로 무료로 제공되는 것이라고 설명합니다. 이는 해당 모델들이 풀(pool)에 유용한 추가 요소가 될 수는 있지만, 변하지 않고 유지될 것이라고 가정할 수 있는 영구적인 기반은 아님을 의미합니다.

이러한 가변성은 단순한 채팅보다 에이전트(agent)에게 더 중요합니다. 에이전트는 여러 턴(turn)에 걸쳐 계획을 수행합니다. 만약 중간에 모델이 바뀌면, 새로운 모델은 대화 기록(transcript)은 물려받지만 이전 모델의 판단력까지 물려받지는 못합니다. 작업은 계속될 수 있지만, 편집 스타일, 주의 깊음, 또는 해석 방식이 달라질 수 있습니다.

저는 워크로드(workload)가 요구하는 일관성 수준에 따라 작업을 분리하는 법을 배웠습니다. 일상적인 탐색, 요약, 테스트 반복, 그리고 위험도가 낮은 백그라운드 작업은 모델이 교체되는 것을 잘 견뎌냈습니다. 반면 대규모 리팩터링(refactor)이나 미묘한 아키텍처 제약 조건이 있는 작업은 고정된 모델(pinned model)이나 더 좁은 폴백 체인(fallback chain)을 사용하는 것이 유리했습니다. 무료 용량은 변동성을 견딜 수 있는 작업에 매칭했을 때 가장 가치 있었습니다.

네 가지 코딩 도구의 결합 방식

Claude Code, Hermes Agent, OpenClaw, 그리고 OpenCode는 게이트웨이를 사용하는 순간 별도의 제공자(provider) 전략을 세울 필요가 없었습니다. 이들은 각자의 인터페이스와 에이전트 동작을 유지하면서도 동일한 기반 풀(pool)을 공유할 수 있었습니다.

Claude Code는 도구 사용(tool use)과 지시 이행(instruction following)이 중요한 리포지토리(repository) 작업에서 여전히 유용했습니다. Hermes Agent와 OpenClaw는 더 긴 에이전트적(agentic) 작업을 실행할 수 있는 다른 방법들을 제공했습니다. OpenCode는 또 다른 코딩 인터페이스를 제공했으며, 별도로 선택 사항인 Zen 게이트웨이(gateway)에 대한 접근 권한을 제공했습니다.

주요 이점은 OmniRoute가 이러한 도구들을 동일하게 만들었다는 점이 아니었습니다. 클라이언트(client)를 선택할 때 제공자(provider) 설정 단계를 제거했다는 점입니다. 저는 작업에 적합한 에이전트 인터페이스를 선택하는 동시에, 무료 추론(inference)을 중앙에서 관리할 수 있었습니다.

이러한 분리는 장애 진단도 더 쉽게 만들었습니다. 여러 클라이언트가 동일한 경로(route)에서 실패하기 시작하면, 서로 관련 없는 네 가지 설정을 디버깅하는 대신 게이트웨이를 점검하면 되었습니다. 만약 단 하나의 클라이언트만 제대로 작동하지 않는다면, 제공자 풀(provider pool)이 원인일 가능성은 낮아집니다.

다시 신뢰하기 전에 변경하고 싶은 점

광범위한 무료 풀(free pool)은 유지하되, 더 명확한 차선(lanes)을 정의하겠습니다.

하나의 차선은 탐색을 위해 속도와 폭넓은 가용성을 우선시할 것입니다. 다른 차선은 코드 변경 중에 예측 가능하게 동작하는 더 작은 모델 세트를 포함할 것입니다. 세 번째 차선은 지연 시간(latency)이 덜 중요한 백그라운드 작업을 처리할 것입니다. 중요한 작업은 세션 어피니티(session affinity) 또는 고정된 경로(pinned route)를 사용하여, 하나의 모델이 계획부터 검증까지 제어권을 유지할 수 있도록 할 것입니다.

또한 유료 폴백(fallback)은 기본적으로 비활성화 상태로 유지하겠습니다. 수백 개의 제공자에 접근할 수 있는 게이트웨이는 요청이 어디로 갔는지 숨기기 쉽습니다. 비용 텔레메트리(cost telemetry)가 도움이 되긴 하지만, 분명한 경계를 설정하는 것이 나중에 무료 워크플로(workflow)라고 생각했던 것이 유료 모델로 넘어갔음을 발견하는 것보다 더 안전합니다.

마지막으로, 제공자 규칙을 정기적으로 재확인하겠습니다. 문서화된 무료 티어(free-tier) 총량은 스냅샷일 뿐이며, 일부 제공자는 자신들의 무료 모델을 일시적인 것으로 설명합니다. 오늘 작동하는 경로가 다음 달의 계약을 보장하지는 않습니다.

거의 무료인 코딩은 시스템의 문제입니다

이 실험은 제가 추론 비용 (inference cost)에 대해 생각하는 방식을 바꾸어 놓았습니다. 일반적인 비교는 어떤 제공업체가 가장 저렴한 모델을 보유하고 있는지를 묻습니다. 하지만 저의 설정은 다른 질문을 던졌습니다. 독립적으로 제한된 여러 무료 경로 (free routes)를 가로질러 이동할 수 있을 때, 코딩 시스템이 얼마나 많은 유용한 작업을 완료할 수 있는가 하는 점입니다.

저의 워크로드 (workload)에 대한 답은 여러 코딩 에이전트 (coding agents)를 활성 상태로 유지하고, 로컬에서 집계된 10억 개의 토큰을 통과시키며, 추론 비용을 0달러로 기록하기에 충분했습니다. 타협점은 일관성이었습니다. 라우팅 (routing)은 가용성 (availability)을 보호했지만, 모델이 바뀔 때마다 에이전트가 다르게 행동할 가능성이 생겼습니다.

저는 이 설정을 다시 사용할 것입니다. 특히 모델의 변화를 견딜 수 있는 탐색 및 자율 작업 (autonomous work)의 경우에 말입니다. 다만, 이것이 모든 작업에 대해 안정적인 프리미엄 모델을 대체한다고 주장하지는 않겠습니다. OmniRoute는 흩어져 있는 허용량 (allowances)을 하나의 풀 (pool)로 전환함으로써 무료 추론을 실용적으로 만들었습니다. 다음 단계는 가능한 모든 제공업체를 추가하는 것이 아닙니다. 어떤 작업이 연속성을 보장받아야 하는지, 그리고 어떤 작업이 순환 (rotation)을 탈 수 있는지 결정하는 것입니다.