CTX: I built a LLM-free code context loader that uses 5.2% of tokens

June7th — Tue, 31 Mar 2026 06:42:29 +0000

CTX: LLM-free Code Context Loader

Every AI coding agent faces the same problem: what context to include in the prompt?

Naive approach: dump the whole codebase → 100% of token budget gone.
Smart approach: use BM25 search → misses dependency files, import chains, recent edits.

I built CTX to solve this with a deterministic, zero-LLM approach.

How It Works

CTX classifies every query into one of 4 trigger types and routes it to the right retrieval strategy:

from ctx import CTXRetriever

retriever = CTXRetriever(project_path=".")
result = retriever.retrieve("Where is AuthMiddleware defined?")
# → Trigger: EXPLICIT_SYMBOL → symbol index lookup → returns 2 files

Trigger types:

EXPLICIT_SYMBOL → exact symbol lookup in structural index
SEMANTIC_CONCEPT → BM25 hybrid blend
TEMPORAL_HISTORY → git log + recently modified files
IMPLICIT_CONTEXT → import graph traversal (finds what the target imports)

Benchmark Results

87 queries, 29 docs:

Metric	CTX	BM25	Dense TF-IDF
R@3	0.862	0.667	0.690
R@5	0.954	0.839	0.805
MRR	0.795	0.611	0.563
Token usage	5.2%	100%	100%

For dependency queries specifically: R@5 = 1.000 (BM25 = 0.400).

COIR Benchmark (CodeSearchNet Python)

Metric	CTX	BM25
R@1	0.720	—
R@5	0.740	—
MRR	0.728	—

Install

pip install ctx-retriever

GitHub: jaytoone/CTX

The key insight: query intent classification before retrieval beats generic search for code context loading. The trigger classifier adds ~0ms overhead (pure regex + structural index).

Would love feedback from anyone building RAG pipelines for code.

NIPA 플랫폼에서 AI 코딩 비용 38% 줄이기 - 실전 프록시 설정

June7th — Sun, 08 Feb 2026 00:47:25 +0000

들어가며

3개월 전, 한국 정부에서 운영하는 AI 개발자 플랫폼 NIPA를 알게 되었습니다. 무료로 제공하는 Kimi K2.5 모델(256K 컨텍스트, 1T MoE)이 매력적이어서 바로 OpenCode와 연동해서 사용하기 시작했습니다.

처음에는 "무료니까 무제한으로 쓸 수 있겠지"라고 생각했지만, 현실은 달랐습니다.

한 달 토큰 비용: $180 (약 24만원)

무료 플랫폼이지만 토큰 사용량에 따라 비용이 청구되는 구조였고, 긴 컨텍스트를 유지하다 보니 비용이 기하급수적으로 늘어났습니다.

이 글에서는 NIPA 플랫폼에서 OpenCode를 사용하며 토큰 비용을 38% 절감한 실전 경험을 공유합니다.

문제 상황

Kimi K2.5의 매력과 함정

Kimi K2.5는 다음과 같은 강점을 가지고 있습니다:

256K 컨텍스트 윈도우: 대규모 코드베이스 분석 가능
1T MoE 파라미터: GPT-4급 성능
한국어 지원: 영어 모델보다 한국어 성능 우수

하지만 이런 강점이 비용 폭탄으로 돌아왔습니다.

OpenCode 기본 설정의 한계

{
  "compaction": {
    "auto": true  // 기본값: 75%에서 compaction
  }
}

OpenCode의 기본 compaction은 75% threshold에서 동작합니다. 이는 이미 비용이 많이 발생한 후에야 compaction이 일어난다는 의미입니다.

실제 측정 결과:

평균 세션당 토큰: 450,000
월간 비용: $180
Compaction 타이밍: 너무 늦음

해결책: 커스텀 프록시 + 선제적 Compaction

아키텍처 설계

┌─────────────────────────────────────────────────────────────┐
│                        OpenCode                              │
│  - baseURL: localhost:10347 (프록시)                        │
│  - includeUsage: true                                       │
└───────────────────────┬─────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│              nipa-token-monitor (localhost:10347)            │
│  1. API 요청을 NIPA 서버로 전달                              │
│  2. SSE 응답에서 prompt_tokens 추출                         │
│  3. nipa-usage.json에 실시간 기록                           │
└───────────────────────┬─────────────────────────────────────┘
                        │
        ┌───────────────┴───────────────┐
        │                               │
        ▼                               ▼
┌──────────────────┐          ┌──────────────────┐
│  NIPA API Server │          │ nipa-usage.json  │
│  (Kimi K2.5)     │          │ (토큰 브릿지)     │
└──────────┬───────┘          └────────┬─────────┘
           │                           │
           ▼                           ▼
┌──────────────────┐          ┌──────────────────────────┐
│   응답 스트림     │          │ glm-preemptive-compaction│
│   (SSE)          │          │ (70%에서 compaction)    │
└──────────────────┘          └──────────────────────────┘

핵심: 파일 브릿지 패턴

nipa-token-monitor가 SSE(Server-Sent Events) 응답에서 실제 API 토큰 수를 추출하여 nipa-usage.json 파일에 기록합니다.

glm-preemptive-compaction 플러그인은 이 파일을 주기적으로 읽어 70% threshold를 체크하고, 도달 시 compaction을 실행합니다.

구현 상세

1. nipa-token-monitor (프록시 서버)

핵심 기능:

SSE 투명 전달: 스트리밍을 끊지 않고 그대로 전달
usage 추출: SSE 마지막 청크에서 prompt_tokens 추출
파일 브릿지: JSON 파일로 토큰 데이터 실시간 공유

// 핵심 로직: SSE에서 usage 추출
function extractUsageFromSSE(sseBuffer) {
  const lines = sseBuffer.split('\n');
  let lastUsage = null;

  for (const line of lines) {
    if (line.startsWith('data: ') && !line.includes('[DONE]')) {
      try {
        const data = JSON.parse(line.slice(6));
        if (data.usage) {
          lastUsage = data.usage;
        }
      } catch (e) {}
    }
  }
  return lastUsage;
}

설정값:

const CONFIG = {
  PROXY_PORT: 10347,
  TARGET_HOST: 'proxy2.nipa2025.ktcloud.com',
  TARGET_PORT: 10261,
  CONTEXT_LIMIT: 262144,  // 256K
  THRESHOLD: 0.8          // 80% 알림
};

2. OpenCode 설정

opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "nipa-kimi-k25": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "NIPA Kimi-K2.5",
      "options": {
        "baseURL": "http://localhost:10347/v1",
        "includeUsage": true
      },
      "models": {
        "Kimi-K2.5": {
          "name": "Kimi-K2.5 (256K Context)",
          "limit": {
            "context": 200000,
            "input": 200000,
            "output": 20000
          }
        }
      }
    }
  },
  "model": "nipa-kimi-k25/Kimi-K2.5",
  "compaction": {
    "auto": false  // 커스텀 compaction 사용
  },
  "plugin": ["oh-my-opencode"]
}

oh-my-opencode.json:

{
  "experimental": {
    "preemptive_compaction_threshold": 0.70,
    "compaction_timeout": 90,
    "aggressive_truncation": true,
    "dcp_for_compaction": true,
    "auto_resume": true
  }
}

3. 실시간 토큰 데이터

nipa-usage.json (자동 생성):

{
  "timestamp": "2026-02-08T00:25:42.588Z",
  "prompt_tokens": 164081,
  "completion_tokens": 100,
  "total_tokens": 164181,
  "context_limit": 262144,
  "usage_percentage": 0.626,
  "request_count": 963
}

성과

비용 절감

지표	Before	After	개선률
평균 토큰/세션	450,000	280,000	38% 감소
월간 비용	$180	$112	38% 절감
Compaction 타이밍	75% (늦음)	70% (선제적)	최적
스트리밍	끊김 현상	원활	유지

기술적 성과

기능	이전	현재
토큰 추정	문자 수 기반 (부정확)	API 실제 값 (100% 정확)
스트리밍	`stream=false` 강제	SSE 투명 전달
반복 작업	32%	5% 이하 (System Prompt Injection)

설치 및 사용 방법

1. 레포지토리 클론

git clone https://github.com/jaytoone/nipa-opencode-proxy.git
cd nipa-opencode-proxy

2. 설정 파일 복사

# OpenCode 설정
cp config/opencode.json.example ~/.config/opencode/opencode.json

# oh-my-opencode 설정
cp config/oh-my-opencode.json.example ~/.config/opencode/oh-my-opencode.json

# 모델 설정
cp config/nipa-model-config.json.example ~/.config/opencode/nipa-model-config.json

3. 프록시 실행

cd tools
node nipa-token-monitor.js

4. OpenCode 재시작

opencode

5. 토큰 모니터링

# 실시간 토큰 확인
cat ~/.config/opencode/logs/nipa-usage.json

# 로그 확인
tail -f ~/.config/opencode/logs/nipa-token-monitor.log

트러블슈팅

토큰 추적이 안 될 때

# 1. includeUsage 설정 확인
grep "includeUsage" ~/.config/opencode/opencode.json
# → true 여야 함

# 2. 프록시 로그 확인
tail ~/.config/opencode/logs/nipa-token-monitor.log | grep "usage"

Compaction이 안 될 때

# 1. threshold 설정 확인
grep "preemptive_compaction_threshold" ~/.config/opencode/oh-my-opencode.json

# 2. 플러그인 로그 확인
tail ~/.config/opencode/logs/glm-preemptive-compaction.log

오픈소스로 공개

이 프로젝트를 GitHub에 오픈소스로 공개했습니다.

GitHub: github.com/jaytoone/nipa-opencode-proxy

포함 내용:

✅ 실제 동작하는 설정 파일
✅ nipa-token-monitor.js (프록시 서버)
✅ 상세 문서 및 설치 가이드
✅ 트러블슈팅 가이드

기여 환영:

버그 리포트
기능 제안
PR (Pull Request)

배운 점

1. SSE 스트리밍 처리

OpenAI-compatible API의 SSE 응답은 마지막 청크에 usage 정보를 포함합니다. 이를 추출하기 위해 스트림을 끊지 않고 투명하게 전달하는 것이 핵심이었습니다.

2. 파일 브릿지 패턴

프로세스 간 통신(IPC) 대신 단순한 JSON 파일을 사용했습니다. 이는 디버깅이 쉽고, 로그 기록이 자동으로 남는다는 장점이 있습니다.

3. 선제적 Compaction

75%에서 compaction하는 것보다 70%에서 하는 것이 비용적으로 훨씬 효율적입니다. "나중에 하자"는 생각이 오히려 비용을 키웁니다.

마무리

NIPA 플랫폼은 한국 개발자에게 매력적인 AI 인프라를 제공합니다. 하지만 토큰 비용을 효율적으로 관리하지 않으면 예상보다 많은 비용이 발생할 수 있습니다.

이 글에서 소개한 프록시 설정으로 저는 월 $68(약 9만원)을 절감했습니다. 비용 절감뿐만 아니라, 스트리밍 품질 개선과 반복 작업 감소라는 보너스도 얻었습니다.

같은 문제를 겪고 계신 분들께 도움이 되길 바랍니다.

질문이나 피드백은 댓글로 남겨주세요!

참고 자료

이 글은 실제 프로덕션 환경에서 사용 중인 설정을 바탕으로 작성되었습니다.

DEV Community: June7th