Skip to main content
Seu prompt passa por nós a caminho do provedor. Quatro campos decidem o que fazemos com ele. Removemos todos os quatro do corpo da requisição antes de chamar o provedor, para que o provedor nunca os veja. Os três primeiros só funcionam em Managed Keys. Em suas próprias chaves, encaminhamos sua requisição intocada. A mascaramento e a moderação leem sua requisição primeiro, depois o padrão da sua organização, e então são desativados. O armazenamento de rastreamento lê a requisição e nada mais.

​
PII masking

Podemos mascarar dados pessoais em seu prompt antes que ele chegue ao provedor. Cada correspondência se torna um marcador estável, como [EMAIL_1], para que o modelo ainda possa distinguir as pessoas. Abrange e-mails, números de telefone e outros padrões, como números de cartão.
Envie false em uma requisição para pular o mascaramento que sua organização ativou. Se o mascaramento estiver ativado e falhar, interrompemos a requisição com 500 pii_masking_failed em vez de enviá-la sem mascaramento.

​
Moderation

Podemos verificar um prompt em busca de conteúdo prejudicial antes de enviá-lo. Um prompt bloqueado retorna 403 moderation_blocked e não chega a nenhum provedor.

​
Trace storage

Podemos armazenar seus prompts e respostas, criptografados, para que a página de Logs possa exibi-los. Somente sua requisição ativa isso. Uma requisição gerenciada, caso contrário, mantém o que uma requisição BYOK mantém, que são dados de faturamento e nada mais.
Uma requisição posterior sem o campo não armazena nada de novo. O que você já armazenou permanece até que você o exclua na página de Logs.

​
Prompt caching

Armazenamos em cache cada requisição Claude na rota direta da Anthropic. Um prefixo repetido é então cobrado a um décimo do preço normal de entrada. Escrever no cache custa 1,25 vezes o preço de entrada. Um prefixo que você nunca reutiliza custa 25% a mais. É por isso que você pode desativar o cache.
Seus próprios marcadores sempre prevalecem. Se sua requisição tiver qualquer cache_control, nós a encaminhamos e não adicionamos nada nosso. Uma requisição muito curta para ser armazenada em cache simplesmente é executada sem cache. A resposta informa cached_tokens e cache_write_tokens em seu bloco de uso.

​
Identity fields on managed keys

Em Managed Keys, substituímos quatro campos de identidade por um hash estável do ID da sua organização antes de chamar o provedor. A identidade que um provedor vê em nossa credencial deve vir de nós, então estes são os únicos campos que alteramos em vez de encaminhar.
  • user
  • safety_identifier
  • prompt_cache_key
  • metadata.user_id
Em sua própria chave, encaminhamos todos os quatro como você os enviou. Deixamos todas as outras chaves em metadata intocadas. O Workers AI não aceita nenhum campo de identidade no corpo, então anexamos o hash à própria requisição. Gemini, Vertex e Bedrock não aceitam nenhum campo de identidade que possamos definir. Nessas três rotas, removemos o seu e não enviamos nada em seu lugar.

​
One reserved marker in tool call ids

O Gemini precisa de uma assinatura reproduzida a cada chamada de ferramenta, então a carregamos dentro do ID da chamada de ferramenta. O ID que entregamos a você se parece com <id>::gsig::<signature>, e removemos a assinatura antes que qualquer outro provedor a veja. Seus próprios IDs passam intocados, mesmo quando contêm ::. A única coisa a evitar é o texto literal ::gsig:: dentro de um ID que você inventa, porque o leríamos como nosso e encurtaríamos o ID.

​
File names on Gemini models

Você pode enviar um documento inline, como bytes base64 ou como uma URL data:. Em um modelo Gemini, enviamos ao Google o tipo de mídia e os bytes, e omitimos filename e file_id. O formato de documento do Google não possui campos para eles e rejeita uma requisição que contenha um. O modelo lê os bytes e nunca vê um nome, então nada do que você enviou é perdido. Todos os outros provedores ainda recebem o nome.