Integrando o Claude ao Apple Foundation Models

 (platform.claude.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Um pacote Swift que conecta o framework Foundation Models da Apple ao Claude como modelo server-side, permitindo que desenvolvedores chamem o Claude pelo mesmo caminho de código usado para o modelo on-device da Apple
  • Graças ao protocolo LanguageModel introduzido pela Apple na WWDC 2026, tornou-se possível usar uma arquitetura híbrida com uma única API padrão: prototipar com o modelo on-device e enviar apenas tarefas complexas para um modelo em nuvem
  • O ponto central é a capacidade de trocar de provedor: sem mexer na lógica da sessão, é possível alternar entre Apple, Claude e Gemini apenas mudando a dependência do Swift Package
  • Esse pacote, publicado pela Anthropic sob Apache 2.0, é o primeiro exemplo funcional na prática daquela ideia de “conectar qualquer backend”
  • As requisições vão direto do app para a API do Claude, e a Apple não fica no caminho, portanto não vê prompts nem respostas; os custos também são cobrados diretamente na conta da Anthropic

Por que isso importa

  • Para conectar modelos de linguagem a apps iOS, até agora era necessário cadastro em APIs de nuvem separadas, gerenciamento de chaves, cobrança por token e envio de todos os prompts para fora do dispositivo; na WWDC 2026, a Apple resolveu esse incômodo de longa data
  • O framework Foundation Models foi expandido para chamar, por meio de uma única API nativa em Swift, tanto os modelos on-device do Apple Intelligence quanto o Private Cloud Compute e nuvens de terceiros como Claude e Gemini
  • A Anthropic publicou um pacote Swift que implementa esse novo protocolo. Ele serve para receber o fluxo vindo do modelo on-device da Apple e acionar o Claude para processar workflows mais complexos

O que muda para desenvolvedores

  • Troca de provedor sem alterar código

    • Depois de prototipar o app com o modelo on-device da Apple, tarefas como rotear consultas complexas para o Google Gemini ou Anthropic Claude, ou alternar entre eles, podem ser feitas apenas atualizando a dependência no Swift Package Manager, sem mudar a lógica da sessão nem o restante do código do app
    • O modelo on-device fica com tarefas rápidas e locais, como resumo e extração; o handoff para o Claude ocorre apenas quando há necessidade de raciocínio em múltiplas etapas, geração de código, busca na web ou execução de código
    • Em ambos os casos, a API é a mesma, LanguageModelSession, então a troca exige apenas substituir o argumento model:

  • Handoff baseado em tipos

    • Após adicionar ao projeto e entrar com a chave de API da Anthropic, é possível passar a saída tipada do modelo on-device da Apple para uma requisição do Claude, e o pacote processa streaming, chamadas de ferramentas e respostas estruturadas de volta para a view em SwiftUI
    • O uso é simples a ponto de, com geração guiada, retornar valores Swift tipados com apenas três linhas de código

Estrutura de privacidade e custos

  • As requisições são enviadas diretamente do app para a API do Claude, então a Apple não participa do caminho da requisição e não vê prompts nem respostas
  • O uso é cobrado diretamente na conta da Anthropic com os preços padrão da API
  • O próprio app decide, a cada sessão, se usará o Claude ou o modelo on-device da Apple

O panorama maior

  • A Apple planeja transformar em open source neste verão o framework Foundation Models, sua API nativa em Swift para modelos on-device lançada em 2025; com o novo protocolo LanguageModel, seja um modelo da própria Apple ou um provedor remoto, quase qualquer modelo pode operar o LanguageModelSession por trás de uma única API Swift
  • Como exemplo concreto dessa ideia de “conectar qualquer backend”, o ClaudeForFoundationModels da Anthropic materializa o padrão adapter
  • Com o sistema Dynamic Profiles, a Apple permite que apps troquem modelo, ferramentas e instruções no meio da sessão, posicionando isso como base para workflows multiagente
  • Ainda assim, essa integração está em beta e exige iOS, iPadOS, macOS, visionOS, watchOS 27 e Xcode 27, então a API ainda pode mudar antes do lançamento oficial

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • A Apple está controlando a experiência do usuário enquanto transforma os LLMs em commodity
    Como uma empresa de hardware, a estratégia parece ser continuar vendendo as melhores máquinas para usar IA, e isso parece uma boa escolha

    • Talvez Benedict Evans tenha acertado no fim das contas. Os modelos de fronteira estão parecendo cada vez mais as operadoras de telecom dos anos 90
      Elas investem bilhões de dólares em infraestrutura, mas o valor acaba ficando com outras empresas nas camadas mais acima
    • Isso é um pouco separado da ideia de controle da experiência do usuário, mas esse é o resultado da IA de que mais gostei. Durante décadas, as empresas cercaram seus serviços por todos os lados e impuseram UIs ruins; de repente, nos últimos 12 meses, tudo ganhou MCP e passou a poder ser usado por interfaces de chat em linha de comando
      As empresas que não se adaptarem vão acabar apanhando de scrapers web caseiros baseados em IA feitos pelas pessoas, até finalmente cederem
    • Não sei se a melhor máquina para usar IA é mesmo a expressão certa aqui. Esses modelos ainda não rodam no lado do servidor?
    • Já estava claro há alguns anos que a IA acabaria sendo incorporada no nível do sistema operacional. A Apple também já reconhecia isso quando apresentou o Apple Intelligence pela primeira vez
      Talvez faça sentido falar em transformar LLM em commodity, mas isso já é uma funcionalidade voltada ao usuário que vem sendo refinada há anos
    • Agora só falta transformar o hardware em commodity

  • Um pacote Swift que permite usar o Claude como modelo de linguagem no servidor dentro do Apple's Foundation Models framework; eu esperava justamente o contrário. Eu queria que os recursos já existentes do Claude Code de algum jeito rodassem localmente no Neural Engine do meu notebook
    Com um M2 e 8GB de RAM isso é um sonho impossível, mas por um instante fiquei esperançoso

    • Vale ver esta sessão da WWDC. Claro que não vai competir com modelos de fronteira, e 8GB também parece pouco demais, mas a Apple de fato demonstrou MLX + OpenCode
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • Se você usar OpenCode ou Pi com streaming por SSD, tecnicamente dá para ter todos os recursos. Só que vai ser insuportavelmente lento
    • A maioria dos modelos de fronteira para código parecia precisar de algo entre 300GB e 1TB para usar todas as capacidades de verdade
    • O Claude Code, via variáveis de ambiente, pode literalmente ser configurado para consultar qualquer endpoint que tenha uma API compatível
    • Se a nuvem fosse de fato o iCloud privado do usuário, isso até poderia ser aceitável. Se o usuário pagasse o custo e isso rodasse perto dos servidores da Apple que já armazenam o iPhotos, poderia ser uma solução bem elegante
      Mas, na prática, você acaba recebendo o Claude hospedado em algum lugar desconhecido. Pode ser em um datacenter da xAI, em algum lugar da Amazon, ninguém sabe

  • Isso não é exclusivo do Claude. Os desenvolvedores também podem criar apps que chamam os modelos Gemini baseados em servidor do Google
    Na WWDC, a Apple anunciou que abriria o Foundation Models framework para provedores terceirizados de modelos em nuvem. A partir do iOS 27, macOS 27, iPadOS 27, visionOS 27 e watchOS 27, os provedores de modelos poderão implementar o novo protocolo público LanguageModel para oferecer uma interface comum para inferência de modelos. O Google disponibilizou os modelos Gemini no Foundation Models framework por meio do Firebase Apple SDK
    Isso permite uma experiência de desenvolvimento totalmente nativa. Modelos Gemini hospedados na nuvem podem se conectar diretamente ao Foundation Models framework pela mesma API, e como os modelos da Apple no dispositivo e os modelos Gemini hospedados na nuvem ficam atrás de uma superfície de API comum, fica fácil alternar entre inferência local e inferência em nuvem conforme o caso de uso
    https://blog.google/innovation-and-ai/technology/developers-...

    • O ponto importante é que a Apple basicamente renomeou a API compatível com OpenAI como language model protocol, e antes que sejamos amaldiçoados por essa expressão terrivelmente longa, todo mundo deveria se unir em torno disso o quanto antes

  • Fico feliz que a Apple tenha introduzido esse tipo de abstração, mas a principal preocupação é com o lado dos modelos locais
    Por exemplo, mesmo que você queira usar o Gemma 4, do ponto de vista do usuário, se 10 apps baixarem o mesmo modelo separadamente, o celular incha sem necessidade
    Ainda não entendi se a Apple forneceu uma forma de vários apps usarem o mesmo modelo no dispositivo. Isso precisa ser possível sem truques complicados de namespace ou permissões
    Não vi nada que sugerisse isso

    • Acho que é exatamente isso que a Apple está tentando evitar. A proposta deles é algo como: se você precisa de inteligência no dispositivo, “o melhor modelo é o que já está no aparelho”, e se precisar de algo mais específico, adaptadores, ou seja, fine-tuning/LoRA, seriam a melhor opção
      Isso estaria errado enquanto os modelos no dispositivo ainda estiverem muito atrás, mas no longo prazo talvez continue fazendo sentido
      Vários apps que eu uso podem precisar do Gemma 4 E4B, mas eu uso dezenas de apps e os desenvolvedores podem escolher entre centenas de modelos. Um cache compartilhado até pode economizar um pouco de espaço quando houver sobreposição, mas o problema central continua. Se cada app escolher seu próprio modelo, disco e swapping de memória explodem
      Há uma boa chance de ser melhor o fabricante do dispositivo embutir um padrão. Não estou dizendo que se deva impedir o uso de outros modelos, mas um padrão compartilhado pode ser a melhor escolha, para a experiência de desenvolvedor e de usuário, em 99% dos apps
      O maior ganho de desempenho é o modelo já estar carregado na memória, e o modelo padrão tem muito mais chance de permanecer aquecido
      O “melhor modelo” normalmente é “o melhor modelo para este dispositivo”, considerando RAM e capacidade de processamento. O desenvolvedor não consegue testar todos os aparelhos, mas a Apple consegue e vai fazer isso
      Cada modelo precisa ser otimizado para o hardware. Importa onde cada parte roda, se no ANE, no Metal ou na CPU, e o modelo padrão será otimizado
      Se você precisa de um modelo personalizado, LoRA provavelmente é o ideal. Tem algo em torno de 30 MB e ainda aproveita todas as vantagens acima
      Dá para argumentar que o padrão deveria ser substituível, mas isso está mais próximo de um ideal estilo Linux do que da Apple, então duvido que veremos isso na prática. E também há desvantagens reais. Querendo ou não, os prompts acabam sendo otimizados para o modelo-alvo do desenvolvimento, então trocar o modelo padrão do sistema pode piorar a qualidade de todos os apps
    • É uma ótima oportunidade para a Apple oferecer um protocolo universal de ID único de modelo e armazenamento compartilhado, para que os desenvolvedores registrem modelos
    • Basta ver “Bring an LLM provider to the Foundation Models framework”
      https://developer.apple.com/videos/play/wwdc2026/339
    • Os apps podem usar o modelo no dispositivo fornecido pelo sistema com o mesmo framework e API. Mas não existe nenhum mecanismo para eliminar duplicação de modelos personalizados entre apps
    • Isso é exatamente o que são os foundation models. O AICore do Android também usa Gemma internamente, e os apps passam a consultar o LLM e receber respostas em vez de embutirem seu próprio modelo

  • Fiquei pensando se a Apple está incentivando os desenvolvedores a usar LLMs por meio da sua própria camada de abstração de API. Pode ser uma forma de facilitar uma transição suave para os desenvolvedores caso ela lance seu próprio LLM no futuro
    Acho que ouvi dizer que a Apple está gastando muito dinheiro em treinamento e que isso pode se conectar de alguma forma com a Siri ou com a Apple AI atual. Ou talvez seja só uma conveniência para desenvolvedores; fico curioso se há alguma outra intenção

    • A Apple tem alguns mecanismos bem inteligentes para proteger dados do usuário. Recentemente precisei trabalhar com rastreamento em apps, e a forma como escondem detalhes do usuário dentro de coortes anonimizadas com SKAN e privacidade diferencial antes de reportar eventos de rastreamento para plataformas de terceiros era melhor projetada do que eu esperava
      Se você valoriza privacidade, faz sentido haver valor na Apple ficar no meio
    • Isso é suporte a um novo framework incluído em reality/mac/iPad/watch/tv/iOS 27. Disseram que vão abrir o código no fim deste ano, então parece que também poderá ser usado quando Swift for implantado no backend
      O ponto central desse framework é permitir mirar, com a mesma API, no modelo embutido no dispositivo, no modelo online hospedado pela Apple chamado Private Cloud Computer, ou em um shim próprio para qualquer modelo online hospedado arbitrariamente
      Assim, em vez de criar sua própria camada de abstração do tipo “isso quero usar com um modelo local, aquilo quero usar com o Claude” ou integrar diretamente APIs da Anthropic/OpenAI, você pode usar a API do sistema para rotear chamadas dinamicamente para diferentes tipos de modelo/provedor
      Há várias conveniências e peculiaridades, como abstrair chamadas de ferramentas em um único lugar e manter o mesmo transcript ao trocar dinamicamente de provedor ou modelo durante uma sessão
    • De forma cínica, ou realista, essa camada de abstração parece ser o jeito da Apple de fazer o usuário dar o crédito dessas funcionalidades à Apple Intelligence, mesmo quando o LLM real é fornecido por outra empresa
    • É uma leitura sombria, mas não totalmente injusta. A Apple passa a ter mais facilidade para cobrar por modelos fornecidos por outras empresas e, se quiser, também pode coletar dados sobre como usuários usam modelos de terceiros para montar um dataset de treinamento para seus próprios modelos
      Como essa API só pode ser usada em dispositivos Apple, isso também fragmenta o mercado e prende mais os usuários, porque para fazer algo funcionar direito no iOS o desenvolvedor acaba sem poder usar o mesmo sistema em outros lugares
    • Já existe um modelo no dispositivo que os desenvolvedores podem usar por meio desse framework. O Claude é apenas mais um modelo adicionado a isso

  • Parece que a Apple está se preparando para o caso de seus modelos no dispositivo melhorarem, o que faz sentido considerando que passou a ter acesso ao Gemini
    Se os desenvolvedores escreverem todo o código de chamadas para LLMs externos usando isso, quando os modelos da Apple ficarem mais competentes e cobrirem mais casos de uso, será fácil trocar em cada ponto de chamada. Isso melhora a experiência do usuário do app e também reduz os custos de cobrança dos desenvolvedores, dos quais a Apple não recebe comissão

    • Em outras palavras, como isso não dá dinheiro, é improvável que aconteça. Seria melhor para a Apple criar novos planos de IA e IA-lite para os quais as pessoas possam assinar
      A Apple é uma empresa, e todos sabemos com o que empresas se importam, então parece improvável um cenário utópico em que modelos locais rodem no celular
    • Não entendo como usar o Gemini faz os modelos no dispositivo melhorarem
    • Experiência do usuário é outra forma de dizer construção de ecossistema, e isso é o que a Apple faz melhor do que os concorrentes. Também não atrapalha ter o hardware adequado para isso
      Não é à toa que Microsoft e Nvidia estão se aliando

  • Fico curioso sobre como isso é realmente usado em software distribuído para usuários. Pedir que o próprio usuário crie e insira uma chave de API é uma barreira alta demais para uma boa experiência de uso

    • Uma barreira ainda maior é fazer usuários comuns, ou seja, não desenvolvedores, aceitarem um modelo de preço por token
      A estrutura de “pagar um valor sem saber quanto vai custar uma pergunta, podendo não receber a resposta desejada, e ter de pagar mais se quiser usar mais” não é atraente para a maioria das pessoas que não são apostadoras. Explicar para o usuário médio que um “obrigado” no fim de uma conversa longa pode sair caro por causa do contexto é ainda mais difícil de engolir
      Também não ajuda que o custo por token oscile feito ioiô. Usuários comuns precisam de custo fixo e não querem gastar energia acompanhando continuamente o ecossistema de IA. Problemas como “no mês passado minha assinatura durava muito mais” também não apontam para uma boa direção
      Na maioria dos casos, acho que a avaliação da Apple de que LLMs locais são o futuro está correta
    • Com certeza. Eu administro o allihat.com, que ainda parece ser a única extensão do Safari que se comunica com o Claude, e a demanda é bem razoável. Mas o usuário precisa inserir pessoalmente a maldita chave de API do Claude
      Ainda não entendo completamente os termos da Anthropic. Dá para inserir algo como setup-token Set up a long-lived authentication token (requires Claude subscription), mas isso parece uma armadilha. Não sei quem usaria isso e fico pensando se usar em qualquer lugar não seria uma violação imediata dos termos
      Hoje, no allihat.com, se a pessoa não quiser usar uma chave do Claude, eu deixo usar o modelo local da Apple, e a taxa de conversão para usuários pagos subiu cerca de 3 vezes. Mas obviamente isso não substitui o Claude. Eu esperava que a Apple criasse algum mecanismo para fazer o papel de proxy do Claude. Assim eu também não precisaria passar pelo meu servidor só para gerenciar o uso da API do Claude
    • Em produção, está indicado usar .proxied para rotear as requisições pelo seu próprio backend
      A Apple está oferecendo modelos de IA gratuitos via seus próprios servidores para desenvolvedores com menos de 2 milhões de downloads https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • Do mesmo jeito de antes: faça proxy das requisições pelo seu próprio backend
    • Não é o usuário que fornece a chave de API. A documentação mostra como configurar um proxy de backend

  • Entendo que a frase “As requisições vão diretamente do app para a API do Claude; a Apple não está no caminho da requisição e não vê os prompts nem as respostas” é do ponto de vista do desenvolvedor
    Mas, do ponto de vista do consumidor, isso é simplesmente engraçado

    • Por quê?

  • A Microsoft começou a bagunçar o jogo primeiro ao colocar nos termos do Copilot que ele é fornecido apenas para fins de entretenimento, e ao incluir no Copilot para Excel o aviso de “evite usar o COPILOT para tarefas que exijam precisão ou reprodutibilidade, ou que tenham impacto legal, regulatório ou de compliance”
    Em seguida, a Apple está recusando discretamente participar, sem investir dezenas ou centenas de bilhões de dólares para criar um LLM concorrente. Claro, ela revende o Claude ou aproveita o Gemini para os ingênuos, mas a Apple sabe como estão as coisas
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • O próprio agente de programação já é uma camada imposta à força, então agora vamos adicionar mais uma camada? Muitas vezes, agentes de programação parecem gerentes de fornecedor de consultorias de terceirização dos anos 90
    Prometem ao cliente tudo o que existe sob o céu e depois pressionam o pobre contratado para entregar. Agentes de programação consomem 10 vezes mais tokens, como a diferença entre o valor que a consultoria cobra do cliente e o que paga ao contratado. Num teste simples, uma mesma tarefa em que o modelo estoura o limite de contexto ao passar pelo agente de programação funciona bem quando se faz o prompt diretamente
    Camadas são um luxo e eliminam controle e transparência

    • Quando eu criar agentes de programação, não vou usar isso