diffcontext

Mostre a um assistente de codificação por IA apenas o código que importa para uma mudança — chamadores, chamados e funções relacionadas empacotados em um orçamento de tokens, com recuperação autoavaliada que imprime NULL RESULT quando não cabe no seu repositório.

GitHub
4
Experimente este MCPPatrocinado

Documentação

DiffContext

Mostre a um assistente de codificação com IA apenas o código que importa para a mudança que ele está fazendo.

Python 3.9+ CI License: MIT

DiffContext é um compilador de contexto para agentes de codificação com LLM. Dê a ele um repositório Python e uma mudança — um git diff, um branch ou um único nome de função — e ele retorna o pequeno conjunto de funções que o modelo realmente precisa para fazer essa mudança com segurança: os chamadores que quebrarão, as subclasses que a sobrescrevem, os testes que a cobrem. Ele os ajusta a qualquer orçamento de tokens que você tiver e informa ao modelo o que precisou deixar de fora.

Ele é construído para pessoas que integram LLMs a bases de código reais — loops de agentes, bots de revisão de PR, verificações de CI — em qualquer lugar onde você precise decidir o que entra no prompt e o repositório é grande demais para ser enviado por inteiro.

E ele se autoavalia: aponte-o para seu repositório e ele minera seu histórico de git, executa recuperação contra pares reais de co-mudança e imprime NULL RESULT quando não se encaixa — descobrir isso é o recurso.

O problema

Peça a um assistente para alterar uma função em um projeto de 50.000 linhas e você tem três opções ruins: colar o repositório inteiro (não cabe, e os modelos pioram em contextos muito grandes), colar apenas aquela função (o modelo quebra três chamadores que nunca viu) ou buscar pelo nome com grep (o grep não encontra a subclasse que a sobrescreve, nem o handler que a recebe via functools.partial — medimos a recall do grep estagnando não importa quanto orçamento você dê a ele).

DiffContext é a quarta opção. Analise o repositório uma vez em um grafo de dependências real e, para qualquer mudança, selecione as poucas funções que realmente importam e empacote-as no menor prompt útil.

git change ──► changed functions ──► hybrid retrieval ──► token budget ──► LLM-ready context
                                      graph ∪ BM25 ∪ file      top-k + tokens

Instalação

pip install diffcontext

Zero dependências em tempo de execução, Python 3.9+.

Para integração com MCP (Claude Code / Cursor / Windsurf):

pip install "diffcontext[mcp]"

Veja docs/MCP.md para a configuração do servidor.

A partir do código-fonte para desenvolvimento:

git clone https://github.com/trakshan-mishra/Diffcontext.git
cd Diffcontext && pip install -e .

Início rápido

diffcontext index /path/to/project              # cold: seconds; warm: ~0.02s
diffcontext compile --ref HEAD~1 --max-tokens 8000
diffcontext verify --from-history 20 --calibrate

Mais comandos: USAGE.md. Receitas de produção: docs/USE_CASES.md.

Não confie em nossos benchmarks — execute os seus (2 minutos)

diffcontext verify --from-history 20 --calibrate minera casos de teste do histórico de git do seu repositório e avalia a recuperação contra eles — e imprime NULL RESULT em vez de um número decorativo quando a ferramenta não se encaixa no seu repositório. Descobrir isso é o recurso.

Isso torna o modelo melhor?

Sim — medido de ponta a ponta, não por proxy. Em 128 tarefas Python do ContextBench avaliadas pela suíte de testes de cada repositório (sem LLM como juiz), o contexto aproximadamente quadruplica o pass@1: 5,5% → 25,8%, McNemar exato p < 0,0001.

Duas ressalvas, ambas em benchmarks/contextbench/RESULTS.md §6: (a) as funções-semente dadas a cada braço são oráculo — extraídas do patch dourado — então isso mede "dada a localização correta, a qualidade do contexto importa?", não a resolução de problemas de ponta a ponta (a localização é entregue a todos os braços gratuitamente); (b) 121 das 128 tarefas efetivas são django, então isso é em grande parte um resultado de django.

O companheiro honesto: as três variantes de contexto (padrão / lacuna / depboost) são estatisticamente indistinguíveis entre si, p = 0,36–0,81. A vitória é contexto versus sem contexto — não este seletor versus aquele. Resultados completos: benchmarks/contextbench/RESULTS.md.

O que isto não é

  • Não é um gerador de código. Ele seleciona e empacota contexto; o modelo escreve o código.
  • Não é prioridade por precisão. Ele lança uma rede ampla — a precisão média é inferior a 0,1 no top-k padrão. Use --cutoff gap se você paga por token.
  • Ainda não é multilíngue. Python é totalmente suportado. TypeScript/JS (ESM) é um protótipo funcional; CommonJS é um modo de falha medido.
  • Não substitui a leitura do código. A análise estática tem pontos cegos, detalhados abaixo e em docs/BENCHMARKS.md.

Qualidade de recuperação (medida, não afirmada)

A verdade fundamental é minerada do histórico de git — um desenvolvedor alterou essas funções juntas em um único commit; mostrada uma, a ferramenta encontra as outras? Medido em 701 commits reais em 9 repositórios Python e reexecutado como um portão de CI a cada push para que a qualidade não possa regredir silenciosamente.

Hit / recall por commit de parceiros reais de co-mudança, recuperação híbrida:

djangoclickflaskhttpxpydanticblack*requests*
Hit0,8940,8890,8630,9350,7580,8970,953
Recall0,7740,7500,6940,7720,5360,7120,762

* repositórios de validação, nunca usados para ajuste. Tabela completa em todos os 9 repositórios: benchmarks/README.md.

Comparação direta com grep em orçamentos de token idênticos: o grep estagna em 0,215 de recall acima de 4k tokens, enquanto o DiffContext atinge 0,576 em 8k (2,7×). O lado honesto: a precisão média é inferior a 0,1 no top-k padrão — a maioria dos símbolos recuperados é contexto de suporte, não o conjunto exato de co-mudança. --cutoff gap corta na maior queda de pontuação para ~4× de precisão a ~30% de custo de recall (benchmark de co-mudança; 2,2× / ~14% no ContextBench).

Eu auditei meu próprio benchmark, e três das minhas afirmações não sobreviveram

Uma passagem de 2026-07 atacou a avaliação em vez da ferramenta. Três números publicados não sobreviveram:

  • Calibração — o único número citável (r=0,274, n≈25) foi medido em um índice poluído. Remedido limpo em n=1.080, a pontuação legada obtém r=0,016 (p=0,60): nenhuma relação. Corrigido encolhendo em direção a "não sei" → r=0,287 (p=0,0001) — um sinal de classificação, não uma probabilidade.
  • Pesos de mistura — o [0,5, 0,35, 0,15] enviado falhou no leave-one-repo-out; cada dobra escolheu uma mistura menos pesada em grafo. Agora [0,3, 0,5, 0,2].
  • Baseline denso — um substituto de TF-IDF havia superestimado a recuperação densa (0,664, vencendo BM25 5/5). O codificador MiniLM real pontua 0,597 e vence BM25 apenas 2/5. Duas conclusões anteriores corrigidas publicamente.

Relatório completo: docs/auditing-my-own-benchmark.md · passagem bruta: benchmarks/RIGOR_REPORT_2026-07.md.

Uso como biblioteca

from diffcontext.pipeline import index_repository, analyze_impact, compile

idx = index_repository("/path/to/repo")
impact = analyze_impact(idx, ["./src/auth.py:validate_jwt"])
ctx = compile(idx, impact, max_tokens=8000, top_k=20)
print(ctx.text)  # paste-ready, meta-header discloses what was dropped

API incremental (idx.update([...])), saída estruturada, tokenizador plugável: docs/ARCHITECTURE.md.

Suporte a linguagens

LinguagemStatusQualidade de recuperação
PythonCompletoAvaliado: 701 commits, 5 repositórios + 4 repositórios de validação
TypeScript / JS (ESM)ProtótipoRecall médio 0–68% dependendo do estilo de código
JavaScript (CommonJS)Não suportadoMedido 0,0% em express — não use

Limitações conhecidas (medidas, não adivinhadas)

A análise estática tem um teto: irmãos temáticos sem chamada entre eles, links conceituais entre subsistemas (todos os métodos pontuam 0/20) e despacho dinâmico são pontos cegos medidos — detalhados em docs/BENCHMARKS.md. Em caso de dúvida: grep -rn "function_name(" --include="*.py" . antes de confiar totalmente em "nenhum chamador encontrado".

Mais

Licença

MIT