←Tornar al blog
claudeiaagentshermesoauthproxyclaude-codeproductivitat
·7 min de lectura

Quan el proxy no n'hi fa prou — com vaig acabar usant Claude Code com a backend

Ahir estava celebrant-ho. El proxy OAuth funcionava, Harvie parlava a través de Sonnet, tot era bonic. Avui? Tot es va trencar un altre cop.

Què va fallar

El proxy d'ahir reenvia peticions API a api.anthropic.com usant el token OAuth de Claude Code. Simple, elegant. Però avui va començar a retornar això:

You're out of extra usage. Add more at claude.ai/settings/usage and keep going.

No era un rate limit. No era un timeout. Un error de facturació — en peticions amb més de ~720 tokens d'entrada. Les peticions petites anaven bé. El system prompt complet de Harvie (35KB, ~9000 tokens) — rebuig instantani.

El cau del conill

Vam passar hores provant de tot:

  • Replicar cada header que envia Claude Code (x-stainless-*, anthropic-beta: claude-code-20250219, headers de facturació)
  • Provar diferents valors de hash cch al header de facturació
  • Testejar amb el token del VPS i el del Mac
  • Curl directe a l'API saltant-nos el proxy

Res va funcionar. Fins i tot el token del Mac — el que alimenta una sessió de Claude Code totalment funcional — fallava en usar-lo des de curl amb els mateixos headers exactes.

El problema real

Finalment vam revisar la configuració d'organitzacions del compte:

Org: joca.dev
  capabilities: ['api']
  billing_type: prepaid
  rate_limit_tier: auto_prepaid_tier_0  ← sense crèdits

Org: [email protected]
  capabilities: ['claude_max', 'chat']  ← SENSE 'api'!
  billing_type: stripe_subscription
  rate_limit_tier: default_claude_max_5x

Dues organitzacions. La personal té Claude Max 5x però sense capacitat API. L'altra té capacitat API però sense crèdits. Les crides API s'encaminen a l'organització equivocada.

Claude Code funciona perquè usa facturació claude_max, no facturació api. Són canals diferents. El token OAuth et dóna accés a tots dos, però les crides API directes van pel canal api — que no té crèdits.

La solució: claude -p com a backend

Si Claude Code pot usar la subscripció, per què no usar Claude Code com a backend?

Hermes → POST /v1/messages → proxy (Node.js) → escriu el system prompt com a CLAUDE.md → executa: claude -p --output-format stream-json --model opus → tradueix la resposta al format API d'Anthropic → retorna a Hermes

La clau: CLAUDE.md. Quan Claude Code arranca, carrega CLAUDE.md del directori de treball com a part del seu system prompt. Aquest contingut s'integra amb el sistema de facturació de Claude Code correctament — sense límits de tokens, sense «out of extra usage». Vam provar amb 35KB de system prompt i més de 25.000 tokens. Funciona perfecte.

--append-system-prompt té el mateix límit de 720 tokens que l'API. Però CLAUDE.md? Sense límit. Mateixa subscripció, diferent ruta de facturació.

L'arquitectura

Telegram → Hermes (agent, tools, memòria, SOUL.md) → HTTP proxy (:18791) → escriu CLAUDE.md amb el system prompt de Hermes → llança: claude -p --output-format stream-json → parseja events estructurats (tool_use, text, result) → envia progrés de tools a Telegram (edita el mateix missatge) → retorna resposta final en format API d'Anthropic → Hermes envia resposta a Telegram

El proxy tradueix entre el format API d'Anthropic (el que parla Hermes) i el CLI de Claude Code (el que realment parla amb els models). Hermes no sap que hi ha un CLI darrere el teló.

Progrés d'eines a Telegram

Una cosa que vam perdre amb aquest enfocament: Hermes abans mostrava el progrés de tools en viu a Telegram (què està executant, lectures de fitxers, etc.). Amb claude -p, les tools s'executen dins de Claude Code — Hermes no les veu mai.

La solució: el proxy parseja els events de --output-format stream-json, detecta blocs tool_use i els envia directament a Telegram via l'API del bot. Mateix format visual que Hermes: un missatge que es va editant amb cada nova tool, dedup amb comptadors (×2).

Compromisos

El que funciona:

  • Subscripció completa de Claude Max, sense facturació API
  • Opus amb 1M de context, system prompts de 35KB, tools, tot
  • Progrés de tools visible a Telegram
  • Cua de peticions (d'una en una, les altres esperen)

El que és més lent:

  • Cada missatge llança un nou procés claude -p (~8-10s d'overhead d'arrancada)
  • Sense streaming real — la resposta arriba tota junta quan Claude acaba
  • Més pesat al VPS (procés Node.js + Claude Code per petició)

El que es perd:

  • L'elegància d'un proxy HTTP simple
  • Temps de resposta API sub-segon
  • Streaming SSE real al client

El que vaig aprendre

  1. claude_max ≠ api. Són capacitats de facturació separades. La teva subscripció Max no inclou accés API directe.
  2. Els tokens OAuth funcionen per a tots dos, però l'API s'encamina per l'org que tingui capacitat api — que pot no ser la de la teva subscripció.
  3. CLAUDE.md és màgia. S'integra amb la facturació de Claude Code d'una manera que --system-prompt i --append-system-prompt no.
  4. --output-format stream-json et dóna events estructurats (crides a tools, deltes de text, resultats) — molt millor que parsejar text cru.

Propers passos

L'enfocament amb claude -p funciona però és un compromís. La solució ideal seria afegir capacitat api a l'org de Max — llavors el proxy ràpid original funciona a l'instant. Fins que Anthropic inclogui accés API amb les subscripcions Max (o et deixin activar-lo), això és el millor que tenim.

Següent: investigar sessions persistents de Claude Code (--input-format stream-json) per eliminar els 8-10s d'arrancada per missatge. Mantenir un procés viu, enviar-li missatges per pipe. Això ho faria gairebé tan ràpid com l'API directa.

El que l'agent va fer avui a la pràctica

Tot l'anterior — el debugging del proxy, el canvi d'arquitectura — era la infraestructura. Però la gràcia de la infraestructura és el que corre a sobre. Això és el que Harvie va fer avui mentre jo estava treballant:

Va construir un vault d'Obsidian per a OhanaSmart amb el patró LLM Wiki. Li vaig passar un vídeo de Karpathy sobre reemplaçar RAG amb wikis en markdown gestionades per un LLM. Harvie va analitzar el vídeo, va extreure l'arquitectura i la va aplicar al nostre projecte de vending. El resultat: un vault complet amb 31 leads documentats (cadascun amb la seva pròpia pàgina — dades de contacte, objeccions, properes accions), anàlisi de competència, pàgines de normativa i estratègia de pitch. Tot creuat. La idea és que cada interacció amb un lead millora la wiki, així que pel lead #15 ja has vist totes les objeccions possibles.

Va analitzar un vídeo de YouTube i en va extreure conclusions de negoci. No un resum — conclusions estratègiques mapejades als meus tres projectes. «Aquest patró podria ser un servei premium per a Pimesit.es.» «Així hauríem d'estructurar el coneixement d'OhanaSmart.» Aquest és el filtre: si un vídeo no connecta amb ingressos o LOIs, no passa el tall.

Va arreglar els seus propis bugs. La transcripció de veu estava fallant perquè una config apuntava a whisper-1 (el model cloud d'OpenAI) en comptes del nom del model local de Whisper (base). Harvie va trobar el bug, el va pegar i va continuar. Jo ni sabia que estava trencat fins que ja estava arreglat.

Res d'això va requerir que jo obrís un terminal. Vaig enviar missatges de veu des de Telegram mentre els nens jugaven. L'agent va fer la resta.

Aquest és el valor real d'embolcallar Claude Code com a backend: no el diagrama d'arquitectura, sinó el fet que un agent d'IA està construint bases de coneixement, analitzant contingut, generant media i arreglant-se a si mateix — tot a través d'un xat de Telegram, alimentat per una subscripció de Claude Max i un proxy Node.js barroer en un VPS de 7€/mes.

— jo, Johnny — agent configurat: Harvie. La millor arquitectura és la que funciona; la segona millor, la que pots arreglar a les 3 de la matinada.