O preço de um criador de aplicações com IA depende do que conta como trabalho

O plano mais barato para 100 iterações de prompts por semana costuma ser o que contabiliza menos trabalho em torno de cada prompt. O preço mensal anunciado diz-lhe quase nada até saber se uma nova tentativa, uma fase de planeamento, uma execução de testes, uma implementação e um agente a trabalhar em segundo plano acionam o mesmo contador.

Já vi equipas comparar planos dividindo o preço de uma subscrição por 100 prompts. A conta parece simples, mas está errada. Um prompt que altera o texto de um botão e outro que reestrutura uma base de dados contam ambos como uma mensagem para quem escreve, mas podem gerar faturas muito diferentes. Uma comparação honesta começa com um registo da carga de trabalho e aplica depois as regras de faturação de cada fornecedor a esse mesmo registo.

Este artigo usa um catálogo de preços hipotético, não os preços de um fornecedor identificado. O objetivo é dar-lhe um cálculo que possa substituir pelas condições reais de cada plano antes de comprar.

A mesma contagem de prompts pode esconder três faturas diferentes

Uma contagem de mensagens do utilizador mede a conversa, não o processamento nem o trabalho concluído. Os planos por créditos tendem a medir a atividade do modelo, os planos por tarefas medem uma unidade de trabalho definida pelo fornecedor, e os planos fixos vendem acesso dentro de um limite. Esses limites produzem totais diferentes, mesmo quando a aplicação e os 100 pedidos semanais são idênticos.

Imagine que um fundador pede 70 pequenas alterações à interface, 20 alterações que mexem em vários ficheiros e 10 alterações de compilação ou implementação por semana. A contagem visível é 100. Nos bastidores, o criador pode inspecionar o repositório, criar um plano, chamar um modelo várias vezes, executar testes, reparar uma edição falhada, recompilar a aplicação e manter um agente em execução depois de aparecer a resposta no chat. Um plano pode cobrar por cada chamada ao modelo. Outro pode chamar a toda a sequência uma tarefa. Uma subscrição pode incluí-la, limitá-la ou cobrar parte dela como excedente.

Esta é a distinção que os compradores confundem com frequência: uma iteração é um ciclo de decisão do utilizador, enquanto um evento faturável é tudo o que o vendedor decidiu medir. Tratá-los como sinónimos favorece o plano com a página de preços mais vaga. Também pode tornar caro um plano que parecia barato depois de a equipa comprometer a sua aplicação com a plataforma.

Para comparar, use um fator mensal de 4,33 semanas em vez de fingir que todos os meses têm quatro semanas. Cem iterações semanais tornam-se 433 iterações mensais. Esta pequena correção acrescenta 33 iterações, antes de entrar no cálculo uma única nova tentativa ou tarefa em segundo plano.

Um pedido de orçamento útil pede ao fornecedor que classifique o trabalho, não apenas que estime um total. Pergunte: O que inicia o contador? Quando termina? Uma execução falhada conta? Uma nova tentativa automática conta? Que trabalho continua depois de a interface indicar que a resposta está concluída? A capacidade não usada transita? As respostas determinam a fatura.

Defina uma carga de trabalho antes de abrir a calculadora

Crie uma semana representativa com base no trabalho que realmente espera fazer e mantenha-a fixa antes de comparar planos. Se alterar a carga de trabalho para cada modelo de preços, estará a testar texto comercial, não preços.

Para esta comparação, vou usar a seguinte carga semanal:

• 70 pequenas edições, com uma unidade de crédito cada
• 20 alterações em vários ficheiros, com três unidades de crédito cada
• 10 alterações de compilação ou implementação, com cinco unidades de crédito cada
• 25 execuções de nova tentativa, com uma média de duas unidades de crédito
• 35 execuções em segundo plano que consomem 45 unidades de crédito no total

As 100 iterações pedidas consomem 180 unidades de crédito hipotéticas nas primeiras tentativas. As novas tentativas acrescentam 50. O planeamento, a indexação, os testes e o trabalho de implementação acrescentam 45. O total semanal é 275 unidades, ou 1.190,75 unidades num mês médio.

A mesma atividade assume uma segunda forma na faturação por tarefas. Cria 100 inícios de tarefas iniciados pelo utilizador, 25 inícios de novas tentativas e 35 inícios de tarefas em segundo plano por semana. Isso corresponde a 160 eventos semanais e 692,8 eventos mensais. Se todos os 692,8 são faturáveis depende da definição de tarefa no contrato.

Registe o trabalho bem-sucedido e o falhado em separado. Uma taxa de falhas baseada apenas nas mensagens de erro visíveis não inclui reparações silenciosas, recursos automáticos a outros modelos nem novas execuções de testes. A exportação de utilização da plataforma, se existir, é uma prova melhor do que o histórico de chat, porque o chat pode resumir várias execuções de agentes numa só resposta.

Use uma semana que inclua a confusão normal: um prompt pouco claro, um conflito de dependências, um teste que falha por um motivo não relacionado e uma reparação de implementação. Uma semana de demonstração impecável produz um orçamento que só dura até começar o desenvolvimento real.

Não aumente a carga de trabalho para se proteger. Acrescente uma margem de variação separada depois de calcular a base observada. Manter a base e a margem separadas permite ver se um plano é caro por causa do trabalho normal ou porque comprou um seguro para um mês mais intenso.

Os pacotes de créditos cobram pelo movimento dentro do criador

Os pacotes de créditos custam menos quando os preços unitários da plataforma são baixos, os créditos não usados sobrevivem tempo suficiente para serem usados e o criador precisa de poucas passagens de reparação. Custam mais quando um pedido simples se desdobra em várias chamadas ao modelo que o utilizador não vê.

Um crédito não é uma unidade padrão. Pode representar tokens, chamadas ao modelo, passos de agentes, segundos ou uma combinação ponderada. Um fornecedor também pode cobrar quantidades de créditos diferentes por um modelo rápido e por um modelo mais capaz. Comparar a quantidade de créditos de dois pacotes não significa nada, a menos que ambas as plataformas definam o consumo da mesma maneira, o que raramente acontece.

Calcule o preço da carga hipotética com um pacote de 500 unidades a $30. A procura mensal é de 1.190,75 unidades. Como os pacotes não podem ser divididos, o comprador precisa de três pacotes e paga $90. A conta termina o mês com 309,25 unidades restantes se os créditos não expirarem. O custo efetivo do trabalho consumido é cerca de 7,56 cêntimos por unidade, embora o pacote anuncie 6 cêntimos, porque o comprador teve de adquirir capacidade não usada.

A transferência de saldo altera o resultado. Se as 309,25 unidades restantes se mantiverem, a compra do mês seguinte pode ser de dois pacotes em vez de três. Ao longo de vários meses estáveis, o custo médio aproxima-se da tarifa anunciada. Se os créditos expirarem mensalmente, o saldo perdido faz parte do preço. Nunca o omita do modelo.

A seleção do modelo pode alterar o consumo sem mudar a contagem de prompts. Se a plataforma encaminhar edições complexas para um modelo com multiplicador de quatro unidades, os dez pedidos mais difíceis podem dominar a fatura. Pergunte se o encaminhamento é automático, se consegue vê-lo depois e se pode definir um limite. Um modelo mais barato que falha e tenta novamente duas vezes pode custar mais do que um modelo capaz que acerta à primeira.

Os pacotes de créditos funcionam bem para projetos irregulares porque paga quando o trabalho acontece, desde que os créditos tenham uma validade útil. É mais difícil criar orçamento para uma equipa que experimenta livremente. O contador pode mudar comportamentos: as pessoas juntam pedidos sem relação em prompts demasiado grandes, evitam testes ou aceitam resultados fracos para poupar créditos. Essas escolhas reduzem a fatura à custa da aplicação.

A questão incómoda é se o trabalho em segundo plano deve consumir créditos. Consome recursos, por isso é defensável cobrá-lo. O problema surge quando o comprador não consegue prevê-lo nem pará-lo. Uma avaliação justa verifica se a interface mostra cada cobrança em segundo plano e se um limite de gastos impede novo trabalho antes de o saldo chegar a zero.

A faturação por tarefas depende de onde a tarefa começa e termina

A faturação baseada em tarefas pode ser o modelo mais barato quando um preço cobre toda a tentativa, incluindo planeamento, chamadas ao modelo, testes e reparações. Torna-se o mais caro quando cada ação interna se transforma numa nova tarefa.

Aplique uma tarifa hipotética de $0.14 a cada evento iniciado no registo. Com 692,8 eventos mensais, o custo é $96.99 depois de arredondar aos cêntimos. É mais do que os $90 dos pacotes de créditos, embora catorze cêntimos pareça pouco numa página de preços.

Agora altere uma frase do contrato: cobre apenas as 433 iterações pedidas pelo utilizador, incluindo novas tentativas e trabalho em segundo plano dentro de cada tarefa. O custo mensal cai para $60.62. Nada mudou na aplicação. Mudou o limite da tarefa, e esse limite deslocou $36.37.

A faturação por tarefa concluída precisa de outra definição. Se uma execução altera ficheiros, mas falha na implementação, a plataforma concluiu a tarefa? Se o utilizador rejeita o resultado e pede uma correção, isso é uma nova tarefa ou uma continuação? Os fornecedores precisam de regras para evitar trabalho ilimitado por uma taxa única, mas os compradores precisam de regras que consigam reproduzir a partir de um registo de atividade.

A recomendação popular de comparar o custo por prompt bem-sucedido está errada quando o sucesso é declarado pelo próprio utilizador. Os utilizadores aceitam resultados parciais, dividem pedidos grandes e corrigem manualmente o resultado. Um baixo custo por sucesso registado pode esconder horas de limpeza. Compare antes o custo por alteração aceite, usando o momento em que a equipa faria merge, implementaria ou manteria o resultado de outra forma.

O preço por tarefa tem uma vantagem de orçamento quando a unidade corresponde a algo que uma pessoa reconhece. Uma equipa consegue estimar 400 alterações aceites com mais confiança do que milhões de tokens. Esta vantagem desaparece se o produto chamar tarefas separadas à indexação, ao planeamento, aos testes e à implementação. Leia os nomes dos eventos numa fatura real ou exportação de utilização antes de tratar a unidade como estável.

Pergunte também como funciona a simultaneidade. Dois agentes a correr ao mesmo tempo podem reduzir o tempo decorrido e duplicar os inícios de tarefas. Uma reparação em segundo plano que inicia um agente de testes pode contar uma vez, duas vezes ou não contar. A fatura segue o contador, não o relógio.

As subscrições fixas só vencem dentro do limite incluído

Uma subscrição fixa é a opção mais barata para esta carga de trabalho quando a taxa mensal inclui todas as 433 iterações do utilizador, 108,25 inícios de novas tentativas e 151,55 inícios em segundo plano. Se alguma categoria ficar fora da subscrição, acrescente-a antes de declarar o plano fixo mais barato.

Use um plano mensal hipotético de $79 que inclui até 600 execuções interativas e de novas tentativas, além de 200 execuções em segundo plano. O exemplo cria 541,25 execuções interativas e de novas tentativas, e 151,55 execuções em segundo plano por mês. Ambos os totais cabem nos limites, por isso o custo mantém-se em $79. Com estas premissas, o preço fixo vence os $90 dos pacotes de créditos e os $96.99 do plano por tarefas iniciadas.

A palavra «ilimitado» não merece valor numa folha de cálculo. Substitua-a pelo limite real de utilização razoável, limite de simultaneidade, restrição de modelo ou regra de abrandamento. Se o fornecedor não indicar um limite, modele um cenário baixo e outro alto. Um plano que só parece barato numa interpretação sem limites não lhe deu um preço fiável.

Os planos fixos também criam custos por degrau. Com 599 execuções incluídas, mais uma pode não custar nada. Com 600, a próxima pode gerar um excedente ou obrigar a um nível superior. Trace pelo menos três níveis de carga: um mês tranquilo, o mês esperado e um mês de lançamento. Só o cenário esperado esconde o ponto em que a subscrição aumenta.

Os lugares importam quando a faturação segue os utilizadores em vez do trabalho. Um plano de $79 para uma pessoa custa $316 para quatro lugares obrigatórios, mesmo que a equipa partilhe as mesmas 433 iterações. Não assuma que é permitido partilhar contas. Calcule o preço das pessoas que precisam de rever prompts, aprovar implementações ou consultar a utilização.

Uma taxa fixa pode incentivar experiências saudáveis porque cada ideia falhada não cria uma microcobrança visível. Também pode esconder desperdício até a plataforma limitar a conta. A visibilidade de utilização continua a importar. Precisa de saber se os agentes estão em ciclo e se um mês de lançamento ultrapassará o limite incluído.

Os descontos anuais devem entrar no cálculo no fim. Primeiro encontre o modelo mais barato em condições mensais. Depois aplique o desconto e o custo do compromisso. Pagar dez meses por uma ferramenta abandonada após três meses não é poupança.

As novas tentativas pertencem à base, não a uma nota de rodapé

As novas tentativas são trabalho normal de desenvolvimento, por isso uma comparação de preços que assume resultados perfeitos à primeira não serve para comprar. O número útil é a amplificação de tentativas: total de tentativas dividido pelas iterações pedidas.

O exemplo tem 125 tentativas interativas para 100 iterações pedidas, o que dá uma amplificação de tentativas de 1,25. Isso não significa que 25 por cento dos prompts falham simplesmente. Alguns pedidos precisam de esclarecimento, algumas edições passam nas verificações de código mas não cumprem a intenção, e algumas falhas vêm de ferramentas ou dependências. O efeito na faturação é o mesmo quando o plano mede outra tentativa.

Meça as novas tentativas com uma regra que duas pessoas possam aplicar de forma consistente. Conte uma nova tentativa quando o utilizador repete o mesmo resultado pretendido depois de rejeitar ou reparar o resultado anterior. Não conte um requisito realmente novo como nova tentativa. Etiquete as tentativas automáticas em separado, porque o utilizador pode nunca as ver.

Um pequeno piloto deve incluir as tarefas que espera serem difíceis. Se testar apenas texto e alterações de cores numa página de destino, a taxa de novas tentativas diz pouco sobre migrações de bases de dados, autenticação, gestão de estado ou compilações móveis. Faça pelo menos uma alteração arriscada em cada candidato e examine o registo de atividade.

As novas tentativas afetam os modelos de formas diferentes:

• A faturação por créditos costuma cobrar os recursos consumidos em cada tentativa.
• A faturação por tarefas iniciadas costuma cobrar cada tentativa se a repetição criar um evento.
• A faturação por conclusão pode absorver tentativas falhadas, consoante a regra de conclusão.
• A faturação fixa absorve novas tentativas até atingirem um limite incluído ou controlo de utilização razoável.

Não aceite novas tentativas gratuitas como resposta completa. Pergunte se a repetição usa o mesmo modelo, se a alternativa automática consome uma franquia separada e durante quanto tempo a janela de repetição gratuita fica aberta. Uma correção enviada na manhã seguinte pode tornar-se uma nova tarefa, mesmo que o trabalho seja claramente o mesmo.

Há também um custo humano nas novas tentativas. Um plano pode ser barato em dinheiro e caro em atenção se os utilizadores tiverem de supervisionar cada reparação. Durante o piloto, acompanhe os minutos de revisão por alteração aceite. Não force esse tempo para dentro da fatura da plataforma, mas mostre-o ao lado para que um preço baixo não esconda um mau fluxo de trabalho.

Os agentes em segundo plano são o multiplicador invisível

O trabalho de agentes em segundo plano deve ter a sua própria linha porque pode continuar depois de o utilizador ver uma resposta. A indexação do repositório, planeamento, verificações de dependências, testes, monitorização de compilações, implementação e agentes de reparação podem consumir orçamento sem acrescentar outra mensagem de chat.

O nosso exemplo atribui 35 execuções em segundo plano e 45 unidades de crédito por semana. Estes valores são pressupostos deliberadamente visíveis. Substitua-os por registos de utilização de um piloto. Se um fornecedor mostrar apenas um total combinado, execute o mesmo prompt uma vez com a automação opcional desativada e outra com ela ativada. A diferença é uma estimativa, não uma prova, mas é melhor do que tratar o trabalho como gratuito.

O modo de planeamento merece atenção especial. Um plano pode reduzir implementações falhadas e caras ao detetar conflitos cedo, ou pode acrescentar uma etapa paga antes de cada edição trivial. Teste-o em alterações pequenas e grandes separadamente. A política certa pode ser usar planeamento para alterações de esquema e trabalho em vários ficheiros, omitindo-o para edições de texto.

A indexação tem uma curva de custos diferente. A primeira passagem por um repositório pode ser cara, enquanto atualizações incrementais posteriores custam pouco. Um piloto de uma semana pode exagerar o custo em estado estável se incluir a indexação inicial, ou subestimá-lo se o repositório de produção for muito maior. Separe o consumo de configuração do consumo recorrente.

Os testes e a implementação não são desperdício opcional. Desativá-los para caber numa franquia de créditos transfere a deteção de falhas para os utilizadores. Calcule o preço do fluxo de trabalho seguro que pretende executar, incluindo as verificações que o protegem. Uma comparação baseada em testes desativados responde à pergunta de negócio errada.

O Koder.ai suporta modo de planeamento, implementação e alojamento, instantâneos e reversão, além de exportação do código-fonte, por isso um piloto pode observar estas partes do fluxo de trabalho em vez de calcular apenas mensagens de chat. Os nomes e preços dos planos ainda precisam de ser confirmados na interface atual do produto, porque o contexto do site aqui estabelece níveis, não as suas franquias atuais.

Defina um orçamento para trabalho em segundo plano, se o produto o permitir, mas não confunda um limite com previsibilidade. Um limite evita gastos excessivos ao interromper o trabalho. A aplicação pode ainda falhar um lançamento enquanto um agente espera por mais capacidade. Registe tanto o limite financeiro como a consequência operacional.

Passe todos os candidatos pelo mesmo registo

Um registo torna a comparação reproduzível e expõe ambiguidades contratuais antes de se transformarem numa disputa sobre a fatura. Cada linha deve descrever um evento medido, com contexto suficiente para o mapear para créditos, tarefas e franquias de subscrição.

Copie este cabeçalho CSV e use-o durante um piloto:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Mantenha o tipo de evento e o resultado separados. Um teste em segundo plano pode terminar com sucesso enquanto a alteração pedida continua a não ser aceite. Se juntar esses factos num único estado, não conseguirá testar a regra de tarefa concluída de um fornecedor.

No fim da semana, calcule quatro valores:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Depois aplique as condições do plano sem alterar as linhas. Para o catálogo hipotético, o cálculo é:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Uma folha de cálculo também deve mostrar créditos perdidos, capacidade incluída restante e o próximo limite de preço. O plano vencedor no exemplo tem 58,75 execuções interativas e 48,45 execuções em segundo plano restantes. Esta margem não é suficiente para uma semana de lançamento que duplique o trabalho de implementação, por isso a equipa deve calcular esse cenário antes de se comprometer.

Peça ao fornecedor que reveja uma página anonimizada do registo. Não pergunte qual plano é mais barato, pergunte como cada linha seria classificada. Uma classificação por escrito é mais útil do que uma estimativa comercial porque pode compará-la com a primeira fatura.

A variação importa mais do que o preço anunciado

O resultado do exemplo é uma subscrição fixa a $79, pacotes de créditos a $90 e faturação por tarefas iniciadas a $96.99. Esta classificação aplica-se apenas ao catálogo e à carga de trabalho indicados. Uma pequena alteração no tratamento das novas tentativas ou do trabalho em segundo plano incluído pode invertê-la.

Calcule um ponto de equilíbrio para cada par. O plano fixo de $79 vence os pacotes de créditos de $30 sempre que a procura mensal exigir três ou mais pacotes, assumindo que os créditos não usados não têm valor futuro. Se a transferência de saldo permitir ao comprador usar todas as unidades, $79 equivalem a cerca de 1.316,7 unidades de crédito a seis cêntimos cada. Abaixo dessa utilização, créditos totalmente usados custam menos.

Face a tarefas iniciadas a $0.14, $79 equivalem a cerca de 564,3 eventos. Os 692,8 eventos esperados ultrapassam esse ponto. No entanto, se o plano por tarefas cobrar apenas as 433 iterações pedidas, custa $60.62 e vence. Mais uma vez, uma definição importa mais do que a tarifa principal.

Execute cenários de sensibilidade em vez de fingir que a estimativa é exata. Para esta carga de trabalho, altere a amplificação de tentativas entre 1,10 e 1,50, o trabalho em segundo plano entre 20 e 60 eventos semanais e o consumo das edições complexas com um multiplicador razoável divulgado pelo fornecedor. Não precisa de dezenas de cenários. Precisa das poucas variáveis que podem mudar a decisão.

Considere o fluxo de caixa e o compromisso separadamente do custo unitário. Os pacotes podem preservar flexibilidade. Uma subscrição mensal cria um teto previsível enquanto se mantiver dentro do seu limite. Uma subscrição anual troca flexibilidade por desconto. A exportação do código-fonte e os instantâneos podem reduzir o custo de abandonar um criador, mas não tornam a migração gratuita: a aplicação exportada continua a precisar de uma compilação funcional, infraestrutura e alguém capaz de a manter.

Um fundador com utilização incerta deve preferir o modelo cuja desvantagem é visível. Isso pode significar pacotes com transferência de saldo longa, mesmo quando o total mensal esperado é ligeiramente superior. Uma equipa com trabalho constante e medido pode comprar um plano fixo perto do meio da sua franquia incluída. Um plano por tarefas é adequado para trabalho que corresponde claramente a resultados aceites e inclui o trabalho de reparação na própria tarefa.

Não escolha com base no vencedor do exemplo. Escolha depois de substituir cada tarifa e franquia hipotéticas por condições que consiga consultar, e cada pressuposto de carga de trabalho por uma observação do piloto.

Submeta o modelo de faturação a um teste de aceitação

Um modelo de preços está pronto para uma decisão quando outra pessoa consegue reproduzir o total mensal a partir do registo e das condições do plano. Se o cálculo depender de um vendedor interpretar uma tarefa interna depois do sucedido, o modelo falhou no teste.

Use esta lista de aceitação compacta:

1. Registe 100 iterações pedidas representativas, ou uma amostra menor que inclua cada tipo principal de trabalho.
2. Etiquete novas tentativas, tentativas automáticas, planos, testes, compilações, implementações e outras execuções em segundo plano.
3. Associe cada evento à regra de créditos, tarefas ou franquia incluída do fornecedor.
4. Calcule os totais de mês esperado, tranquilo e de lançamento com o mesmo fator de 4,33.
5. Guarde as condições do plano e compare a primeira fatura real com a previsão.

Defina uma tolerância antes do piloto. Por exemplo, pode investigar qualquer total mais de 10 por cento acima da previsão. A percentagem é uma escolha de gestão, não uma norma do setor. O objetivo é obrigar a uma revisão enquanto o histórico de eventos ainda existe.

Se a utilização real exceder a previsão, encontre a categoria de linhas responsável. Mais trabalho aceite é diferente de mais novas tentativas. Mais execuções de implementação planeadas são diferentes de um ciclo de agente. A solução pode ser um plano maior, uma política de agentes mais restrita, prompts mais claros ou uma correção de faturação. Um total único não lhe diz qual.

Mantenha o registo ao lado da fatura durante os três primeiros ciclos de faturação, porque um piloto tranquilo pode não incluir tarefas em lote, trabalho de lançamento e reparações automáticas. O modelo mais barato para 100 iterações semanais é, portanto, condicionado, mas a decisão não precisa de ser vaga. No exemplo explícito, a subscrição fixa de $79 vence. Com faturação por tarefas limitada ao sucesso, o mesmo trabalho custa $60.62 e a faturação por tarefas vence. Os pacotes de créditos vencem com consumo mais baixo ou irregular quando a transferência de saldo evita desperdício. Registe o que conta, meça o trabalho oculto e faça a fatura provar a promessa.