sota-anchor

sota-anchor

Tu agente de codificación no sabe qué se publicó después de su entrenamiento.
sota-anchor es un servidor MCP y un plugin de Claude Code que revisa el último año de artículos,
repositorios y paquetes antes de que tu agente reconstruya algo que ya existe,
o te diga que no se puede hacer.

Un agente de codificación planifica a partir de lo que aprendió en su entrenamiento. Cuando una tarea necesita algo que no conoce, asume que esa cosa no existe y hace una de dos cosas costosas: lo construye desde cero, o te dice que no se puede hacer. A menudo, la biblioteca, el lector o el modelo que facilitan el trabajo se publicó después de que terminara su entrenamiento.

sota-anchor hace que el agente verifique qué se ha publicado desde entonces. Cuando un plan se basa en que algo no está disponible, el agente busca en el último año de artículos, repositorios y paquetes, y evalúa lo que encuentra, con fechas. Luego reutiliza lo que existe, o construye sabiendo que nada mejor existe.

• Cualquier campo. Nada en el código sabe sobre ningún dominio. La misma verificación se ejecuta para un formato de archivo CAD, un pipeline de genómica o un paso de compilador.
• Sin clave API adicional. Tu agente hace el razonamiento; sota-anchor hace la recuperación.
• Evidencia, no memoria. Cada afirmación cita una fuente con fecha. Cuando la búsqueda no encuentra nada, lo dice en lugar de adivinar.

Antes y después

La misma solicitud ambas veces, en el mismo proyecto Xcode 27: "xcode 27 movió nuestro proyecto al nuevo formato project.xcproj y aún no hay biblioteca para él, así que escribe un parser de Swift que podamos usar en CI para verificar la configuración de compilación de cada target".

Antes. Sin sota-anchor, Claude Code tomó la solicitud al pie de la letra y escribió el parser: un paquete Swift de ocho archivos y 755 líneas, con el formato resuelto, en sus propias palabras, "de tu Logbook.xcodeproj/project.xcproj, no de ninguna documentación de Apple". Tardó 2 minutos 37 segundos.

Después. Con sota-anchor, la verificación se ejecuta antes de cualquier código. Encuentra la propia biblioteca de Apple para el formato, xcode-project-format, publicada bajo Apache 2.0 el 2026-09-15, después de que el modelo fuera entrenado. Claude Code lo confirma en GitHub, descarta el parser personalizado porque "escribir el nuestro lo duplicaría", y pregunta qué reglas debe aplicar la verificación de CI antes de escribirla contra la biblioteca de Apple. 42 segundos, y aún no se ha escrito código.

_{Ambas son sesiones grabadas de Claude Code (Opus 5.5, 2026-09-25 y 2026-09-26), dibujadas como una terminal de Mac a partir de las pantallas grabadas. La primera se muestra desde arriba y continúa por otras 116 filas. El archivo del proyecto de muestra se generó con la biblioteca de Apple, por lo que es el formato real.}

La misma verificación en otros planes

_{La primera y la última fila son de ejecuciones grabadas. Los artículos de la segunda son lo que la búsqueda devolvió para ese plan el 2026-09-24.}

Cómo funciona

Cuando una solicitud se basa en que algo no está disponible (un lector para un formato que solo abre el software del proveedor, una biblioteca que nadie ha escrito, una tarea que los modelos aún no pueden hacer), la habilidad check-what-exists ejecuta una verificación de tres pasos:

1. Invertir. Tu agente nombra lo que el plan asume que no existe: ninguna biblioteca lee el formato project.xcproj de Xcode 27 todavía. Una restricción que tú estableces ("no podemos usar el SDK del proveedor") se mantiene como dada; lo que se verifica es si algo más la cumple. El agente escribe dos consultas: la tarea en las palabras de su propio campo, y lo que haría innecesaria la solución alternativa.
2. Buscar. sota-anchor busca en los últimos 12 meses de artículos (arXiv, Hugging Face), repositorios (GitHub) y paquetes (npm, crates.io), además de la web si le das una clave de Brave. Relaja cada consulta hasta que algo relevante vuelve, y un presupuesto de 60 segundos cubre todas las fuentes.
3. Juzgar. Tu agente evalúa solo lo que volvió. La suposición se mantiene a menos que la evidencia documente lo contrario. "No existe ninguna biblioteca" se revierte con un repositorio o paquete publicado que haga el trabajo, reportado con su antigüedad y actividad, porque existir no es lo mismo que maduro. "Los modelos no pueden hacer esto" necesita resultados con benchmarks.

El veredicto es uno de tres. Cuando algo ya hace el trabajo, el agente lo nombra y la evidencia detrás de él, como en la sesión anterior. Cuando la evidencia no resuelve la pregunta, la suposición se mantiene y el agente dice qué la revertiría. Cuando no vuelve nada, dice que no se verificó nada, en lugar de tratar el silencio como un veredicto.

También: IDs de modelos actuales

Una conveniencia menor, principalmente para proyectos nuevos. Cada sesión de Claude Code comienza con una lista corta y fechada de los IDs de API de modelos que el registro público de OpenRouter sirve hoy, y los IDs más antiguos que reemplazaron, para que una configuración nueva nombre un modelo que existe:

- GEMINI_MODEL=gemini-3-pro            # recalled from training: not a served ID
+ GEMINI_MODEL=gemini-3.1-pro-preview  # from the session's registry snapshot

La lista nombra su fuente y no hace ninguna afirmación sobre qué modelo está ejecutándose. Cuesta alrededor de 160 ms por sesión, porque el hook lee un bloque renderizado de antemano y lo refresca en segundo plano una vez al día. Otros agentes obtienen la misma lista a través de sota-anchor sync.

Inicio rápido: Claude Code

[!NOTE] Requiere Python 3.11+ y uv. Sin clave API.

En Claude Code:

/plugin marketplace add luckmanqasim/sota-anchor
/plugin install sota-anchor@sota-anchor

Luego inicia una nueva sesión. La primera tarda unos segundos más mientras uv construye el entorno del servidor MCP; después de eso arranca directamente.

Para probarlo en una sesión sin instalar:

git clone https://github.com/luckmanqasim/sota-anchor
claude --plugin-dir ./sota-anchor

Lo que obtienes:

Pruébalo

Tres prompts que muestran lo que hace:

1. Un plan que se basa en algo que falta. La verificación se ejecuta por sí sola:

   xcode 27 moved our project to the new project.xcproj format and there's no library for
   it yet, so write a swift parser we can use in CI to check each target's build settings
   

   Claude encuentra la propia biblioteca xcode-project-format de Apple, lanzada después del entrenamiento del modelo, y pregunta qué debe aplicar la verificación de CI en lugar de escribir un parser.

2. Una verificación bajo demanda, para un formato que normalmente se asume que necesita el SDK del proveedor:

   /sota-check "Write our own reader for Navisworks .nwd files, since we can't use the Autodesk SDK"
   

   Busca repositorios, paquetes y artículos recientes, y reporta lo que encontró, con fechas, o dice claramente que no apareció nada.

3. Un identificador de modelo en código. La lista de modelos de la sesión hace el trabajo:

   Add an Anthropic client to this script and pick the current flagship model
   

   Claude usa un endpoint de la lista fechada que el plugin agrega a la sesión, en lugar de uno más antiguo recordado del entrenamiento.

Otros agentes de codificación

La verificación es un servidor MCP simple, por lo que funciona en cualquier agente que hable MCP. La lista de modelos va al archivo de instrucciones del proyecto.

1. Instala el CLI una vez:

uv tool install sota-anchor   # or: pipx install sota-anchor

2. Registra el servidor MCP en tu agente, usando el fragmento para él a continuación.

3. Opcionalmente, escribe la lista de modelos en el proyecto, y ejecútalo de nuevo cada vez que quieras una lista fresca:

sota-anchor sync --target agents   # writes AGENTS.md
sota-anchor sync --target cursor   # writes .cursor/rules/sota.mdc and .cursorrules

Solo el texto entre los marcadores SOTA-ANCHOR se toca alguna vez, por lo que el resto del archivo sigue siendo tuyo.

[!TIP] Fuera de Claude Code, tu agente decide cuándo llamar a check_what_exists desde la propia descripción de la herramienta. Para asegurarte de que se ejecute, pídelo: "ejecuta check_what_exists en este plan antes de construirlo."

{
  "mcpServers": {
    "sota-anchor": { "command": "sota-anchor", "args": ["serve"] }
  }
}

{
  "servers": {
    "sota-anchor": { "command": "sota-anchor", "args": ["serve"] }
  }
}

code --add-mcp '{"name":"sota-anchor","command":"sota-anchor","args":["serve"]}'

codex mcp add sota-anchor -- sota-anchor serve

[mcp_servers.sota-anchor]
command = "sota-anchor"
args = ["serve"]

gemini mcp add sota-anchor sota-anchor serve

{
  "mcpServers": {
    "sota-anchor": { "command": "sota-anchor", "args": ["serve"] }
  },
  "context": { "fileName": ["AGENTS.md", "GEMINI.md"] }
}

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sota-anchor": { "type": "local", "command": ["sota-anchor", "serve"], "enabled": true }
  }
}

"sota-anchor": {
  "type": "local",
  "command": ["uvx", "sota-anchor", "serve"],
  "enabled": true,
  "timeout": 30000
}

{
  "mcpServers": {
    "sota-anchor": { "command": "sota-anchor", "args": ["serve"] }
  }
}

{
  "mcpServers": {
    "sota-anchor": { "command": "uvx", "args": ["sota-anchor", "serve"] }
  }
}

[!TIP] Si tu editor dice que no puede encontrar sota-anchor, dale la ruta completa. uv tool dir --bin imprime la carpeta donde uv lo instaló.

Línea de comandos

Todo lo que hace el plugin también es un comando, y ninguno necesita una clave API.

Opciones de sync:

En CI

Sin una clave de API, check imprime el protocolo para que un agente responda. Con una, llega a un veredicto por sí mismo, lo que lo hace utilizable como puerta:

- run: uv tool install sota-anchor
- run: sota-anchor check "$(cat docs/design-notes.md)"
  env:
    SOTA_ANCHOR_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}

Configuración

No es necesario configurar nada. Todo esto es opcional.

En Claude Code, el plugin solicita sus dos claves opcionales cuando lo habilitas y las guarda en el almacén de credenciales de tu sistema. Deja cualquiera vacía para prescindir de ella.

sota-anchor solo lee variables nombradas para él, por lo que una clave que hayas configurado para otras herramientas, como GITHUB_TOKEN, nunca se recoge. Fuera del plugin, establece estas en su lugar:

Para un veredicto sin intervención, donde no hay ningún agente presente para juzgar (como en CI):

Qué envía y obtiene

Todo lo que sota-anchor hace por la red y cada archivo que escribe. No hay telemetría.

Cuando se ejecuta la verificación, las consultas de búsqueda que tu agente escribe a partir de tu solicitud, y versiones más cortas de ellas a medida que la búsqueda se relaja, van a estas API públicas con un User-Agent sota-anchor/<version>:

Para la lista de modelos, obtiene openrouter.ai/api/v1/models, un punto final público que no requiere clave y no recibe nada sobre ti. El hook de sesión lo actualiza en segundo plano como máximo una vez al día.

Para un veredicto sin intervención, cuando SOTA_ANCHOR_API_KEY está establecido, el plan y la evidencia encontrada para él van a la API en SOTA_ANCHOR_BASE_URL, que es openrouter.ai/api/v1 a menos que lo cambies. Tanto sota-anchor check como la herramienta MCP hacen esto, incluido el servidor del plugin si la variable está en el entorno desde el que Claude Code se inicia. Sin él, tu agente hace el juicio y nada va a una API de LLM.

En el primer lanzamiento, uv descarga los paquetes de Python que el servidor necesita de PyPI, en las versiones exactas que uv.lock fija.

En disco, escribe el catálogo de modelos y el bloque de sesión en ~/.cache/sota-anchor, o en SOTA_ANCHOR_CACHE_DIR. /sota-sync y sota-anchor sync escriben un bloque marcado en CLAUDE.md, AGENTS.md o las reglas de Cursor en el proyecto actual, y solo cuando los ejecutas. El hook de prompt opcional lee tu prompt en tu máquina para decidir si añadir un empujón, y no lo envía a ningún sitio.

Solución de problemas

Cualquier otra cosa: abre un issue. Para un problema de seguridad, sigue SECURITY.md en su lugar.

Limitaciones

• Si la verificación se ejecuta es decisión de tu agente. En Claude Code se ejecutó antes de escribir cualquier código cada vez en las pruebas con solicitudes de ingeniería como las anteriores, y permaneció en silencio en las ordinarias. En otros agentes, pídela por nombre cuando importe.
• Un hallazgo es una pista, no una decisión. Un artículo no prueba que exista una herramienta lista para producción, y un repositorio no prueba que funcione. Trata un hallazgo como una razón para mirar.
• La relevancia es léxica. Un resultado debe mencionar dos de los términos de la consulta, lo que excluye proyectos que solo comparten un acrónimo pero no los que comparten palabras genéricas. Tu agente ve cada descripción y descarta lo que está fuera de tema, pero espera algo de ruido.
• PyPI no se busca. No tiene API de búsqueda. Los paquetes de Python generalmente aparecen a través de sus repositorios de GitHub.
• arXiv es lento y particular. Las solicitudes se espacian 3,5 s según sus términos de uso. Su borde rechaza algunos clientes HTTP, por lo que una solicitud rechazada se reintenta a través de la biblioteca estándar. Cuando una fuente falla, los errores lo dicen; léelos antes de confiar en una "limitación vigente".
• La recuperación se detiene a los 60 segundos. Una fuente que aún se está ejecutando en el plazo conserva lo que encontró e informa el déficit.
• La lista de modelos puede tener un día de antigüedad. El hook nunca espera en la red. Ejecuta /sota-sync para actualizarla de inmediato.
• El veredicto sin intervención no está probado contra un proveedor en vivo. Está cubierto por pruebas con un modelo falso, pero aún no se ha realizado ninguna ejecución de API real.

Notas de diseño

• Sin diccionarios de temas. La recuperación conoce palabras funcionales genéricas en inglés y nada sobre ningún campo. Las consultas mantienen el orden en que su autor las escribió, y una consulta se relaja eliminando primero sus últimos términos.
• Y, no O. arXiv lee all:{phrase} como un O sobre cada palabra; para una consulta de prueba que coincidió con 329.590 artículos, ordenados por fecha devolvió los artículos más nuevos sobre cualquier cosa. Los términos se combinan con Y, y la consulta se relaja solo cuando no encuentra nada.
• Sin veredicto desde la nada. Un conjunto de evidencia vacío nunca llega al paso de juicio, por lo que un agente no puede completar un veredicto de obsolescencia desde la memoria.
• Datos de referencia, no órdenes. El bloque de sesión dice de dónde provienen sus datos y para qué sirven, y no reclama autoridad sobre el modelo que lo lee. Una redacción anterior que lo hacía fue rechazada correctamente por un modelo anfitrión como inyección de prompt.
• Sin modelos codificados. La clasificación lee la estructura de un ID de modelo: un token de slug con un dígito es una versión, un token alfabético pertenece al linaje. Así, gpt-4o y gpt-5.5 comparten un linaje a través de un cambio de nombre. Un modelo se considera superado cuando algo más nuevo comparte su linaje, cuando va por detrás de la versión más reciente de su proveedor en más de la ventana de obsolescencia, o cuando el registro lo ha caducado.

Desarrollo

git clone https://github.com/luckmanqasim/sota-anchor
cd sota-anchor
uv sync --extra dev
uv run pytest            # all offline
uv run ruff check .
claude plugin validate .

La suite nunca toca la red ni tu propia caché. HTTP pasa por httpx.MockTransport y el LLM a través de un falso inyectado. Cada prueba obtiene un directorio de caché privado, una búsqueda DNS real falla la prueba, y las pruebas de hook ponen herramientas de actualización falsas primero en PATH. CI lo ejecuta en Ubuntu y Windows con Python 3.11, 3.12, 3.13 y 3.14.

Antecedentes

SciUnlearn (Paul, Patwardhan & Cohan, arXiv:2608.20960) encuentra que los métodos actuales de desaprendizaje automático "son incapaces de eliminar eficazmente el conocimiento a nivel de afirmación y a menudo logran solo una supresión superficial". Si las afirmaciones obsoletas no se pueden eliminar limpiamente de los pesos de un modelo, la corrección debe ocurrir en contexto, en el momento en que el modelo está a punto de actuar sobre la creencia obsoleta. Ahí es donde trabaja sota-anchor.

La habilidad pide su veredicto de "algo ya hace esto" como un bloque de aserción-razón ([SOTA ARBITER PARADIGM SHIFT]), uno de los cuatro formatos de QA en ese punto de referencia, tomado prestado aquí como una forma. La idea de que formular una actualización de esta manera hace que un agente sea más propenso a actuar sobre ella es la hipótesis de diseño de este proyecto, no un hallazgo del artículo.

Licencia

MIT © 2026 Luckman Qasim