Pare de racionar tokens: deixe o harness escolher o modelo — Kimchi, da Cast AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Stop Rationing Tokens: Let the Harness Pick the Model — Kimchi by Cast AI · Canal: AI Engineer · 17:48 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Inferência e otimização de modelos, Modelos locais e open source

Resumo

Laura, cofundadora da Cast AI, apresenta o Kimchi, um coding agent com um harness que escolhe modelos conforme a tarefa e busca reduzir custos sem limitar o uso de tokens pelos desenvolvedores. A equipe relata ter economizado 2,5 vezes em comparação com o custo que teria com modelos na nuvem, apesar do aumento no uso de tokens, mantendo resultados equivalentes. Zilvinas explica o processo autônomo de execução e avaliação de tarefas, além das ferramentas Kimchi Teleport e Kimchi Studio para manter sessões em execução e colaborar em equipe. O fluxo atual leva as mudanças até um ambiente de staging, com revisão humana antes da produção.

Pontos-chave

O Kimchi usa um harness para selecionar o modelo mais adequado à tarefa, considerando o custo e a qualidade do resultado.
A equipe relata uma economia de 2,5 vezes em relação ao custo que teria com modelos na nuvem, enquanto o uso de tokens aumentou.
A seleção de modelos pode mudar ao longo do tempo conforme o harness identifica opções mais adequadas.
O processo chamado ferment divide tarefas longas em etapas, executa mudanças, verifica o resultado e pode repetir o trabalho quando necessário.
A conclusão de uma tarefa depende de uma pontuação mínima; a equipe ainda mantém uma etapa de revisão humana antes da produção.
Kimchi Teleport mantém sessões de coding agent em sandboxes remotos, mesmo quando o usuário fecha o laptop.
Kimchi Studio permite que equipes acompanhem planos e tarefas em andamento e assumam itens que precisam de revisão.
A equipe apresenta o harness como open source e diz que Teleport e Studio exigem uma conta Google.

Capítulos

Início	Capítulo	Resumo
00:13	O custo dos tokens e a proposta do Kimchi	Laura apresenta o problema dos gastos com tokens e defende que o harness escolha modelos para reduzir custos sem limitar os desenvolvedores.
04:20	Seleção de modelos e economia relatada	A apresentação descreve a escolha automatizada de modelos e relata economia de custos com resultados equivalentes.
07:24	Execução autônoma e avaliação das tarefas	Zilvinas explica o processo ferment, que divide tarefas em etapas, verifica a qualidade e, no fluxo atual, encaminha mudanças concluídas para staging.
11:03	Kimchi Teleport: sessões remotas persistentes	A equipe apresenta o Teleport, que mantém ambientes de coding agent em execução em sandboxes remotos, mesmo com o laptop fechado.
14:09	Kimchi Studio e colaboração em equipe	A equipe mostra como o Studio organiza sessões e revisões colaborativas e encerra explicando a disponibilidade do harness e das ferramentas.

Citações

Nosso trabalho como gestores é fazer o oposto: garantir que os tokens sejam ilimitados. — 01:45

Um harness automatizado que selecione o modelo certo para a tarefa, na hora certa, com base no resultado. — 04:20

Um artefato só é considerado completo quando a pontuação do resultado é pelo menos B. — 10:00

Você inicia o processo, leva-o para o ambiente remoto e ele continua rodando em segundo plano. — 12:36

Conceitos e entidades

Kimchi (ferramenta): Plataforma de coding agent da Cast AI que seleciona modelos e automatiza partes do desenvolvimento de software.
Cast AI (empresa): Empresa apresentada como criadora do Kimchi.
Laura (pessoa): Cofundadora e presidente da Cast AI que apresenta o Kimchi na palestra.
Zilvinas (pessoa): Líder de engenharia da plataforma de coding agent Kimchi.
Kimchi harness (ferramenta): Harness do Kimchi que escolhe modelos para tarefas de programação e coordena sua execução.
ferment (conceito): Processo do Kimchi para executar tarefas longas em etapas, avaliar resultados e repetir mudanças quando necessário.
Kimchi Teleport (ferramenta): Recurso que executa sessões em sandboxes remotos para que continuem rodando fora do laptop do usuário.
Kimchi Studio (ferramenta): Interface para equipes visualizarem sessões, planos e tarefas do Kimchi e colaborarem na revisão.

Tradução completa (pt-BR)

00:13 Certo, pessoal. É muito bom conhecer todos vocês. Meu nome é Laura. Sou cofundadora e presidente da Cast AI, a criadora do Kimchi, que vou mostrar a vocês em alguns segundos. A palestra será sobre modelos preparatórios para casos extremos, mas usando open source no restante. E vocês vão ver algo ótimo que temos com isso, com o coding agent chamado Kimchi. Tenho o prazer de estar aqui com Zilvinas. >> Oi, pessoal, sou Zilvinas. Lidero a engenharia da plataforma de coding do Kimchi. >> Então, vocês têm aqui Zilvinas, que lidera toda a

00:44 equipe de engenharia do Kimchi. Estou muito animada por estar aqui com vocês. Certo, vamos lá. Talvez vocês tenham visto isso nas notícias. Duas informações que surgiram nas últimas semanas. A primeira é que uma empresa na Índia gastou US$ 500 milhões apenas com a Anthropic em um mês. Isso é mais um bom exemplo de tokens completamente fora de controle. O outro exemplo é um tuíte famoso do CTO do Uber, que disse que, nos últimos quatro meses, ele

01:14 na verdade usou o orçamento inteiro da Anthropic para o ano todo. E é assim que o token, a maximização do uso de tokens ou o custo dos tokens se tornou um problema para as empresas. E vocês vão ver como resolvemos isso. As empresas responderam a isso limitando o uso de tokens. Talvez vocês já tenham ouvido isso muitas, muitas vezes dos nossos amigos desenvolvedores. E, como desenvolvedor, quando limitam a quantidade de tokens, a sensação é esta.

01:45 É como se alguém dissesse: “Ei, você pode usar seu laptop. A bateria dura uma hora e você só pode carregá-lo uma vez por dia.” É assim que os desenvolvedores se sentem quando limitam a quantidade de tokens. Nós, do Kimchi, achamos que isso está errado. Nosso trabalho como gestores é fazer o oposto. É garantir que os tokens sejam ilimitados.

02:16 E baratos. Nosso trabalho não é impedir os desenvolvedores de usar um coding agent. Nosso trabalho é garantir que eles possam usá-lo o quanto quiserem e pelo tempo que quiserem, de forma completamente ilimitada. Foi por isso que começamos o Kimchi. No Kimchi, temos 300 desenvolvedores. Ah, desculpem. 300 funcionários. Dois terços são desenvolvedores. Zivinas lidera essa equipe. E estamos usando esse coding agent há três meses. Vou mostrar a vocês o que construímos, como

02:49 construímos e os resultados. Depois, Zivinas vai mostrar mais algumas coisas que tornam o coding agent muito, muito legal. Está chegando. Construímos uma solução completa de otimização de tokens com base nessa ideia. O que vocês veem na tela é o custo real de modelos de LLM para a mesma tarefa. Isso foi apresentado em um famoso white paper de uma universidade. E

03:19 aqui está o que eles dizem. De um lado, vocês veem o custo por token. Do outro, o custo por tarefa, para a mesma tarefa e com a mesma qualidade. Isso é importante; caso contrário, não dá para comparar coisas equivalentes. E aqui está o que está escrito. Primeiro, todos são diferentes. Mas olhem também para o Gemini 3 Plus, nossos amigos do Google. Bem, parece ser um modelo relativamente barato, a US$ 3,50 por

03:50 milhão de tokens. Essa é uma média ponderada calculada na época em que o estudo foi feito. Mas, na verdade, a tarefa concluída com o Gemini 3 custou US$ 305. Desculpem, US$ 705. E olhem para os outros. O Minimax 2.7 é um dos meus favoritos. O custo por token é 1,5, e o custo da tarefa é US$ 148. Isso significa que os modelos não são iguais. Eles não custam o mesmo, mas

04:20 também não têm o mesmo custo por tarefa. E foi por isso que construímos nosso coding agent. Não seria ótimo ter um mecanismo automatizado, um harness automatizado que selecionasse o modelo certo para a tarefa, no momento certo, com base no resultado da tarefa? Foi isso que fizemos com o Kimchi Coding. Foi isso que Zilvinas fez com a equipe dele. E aqui está o resultado. Estamos usando

04:50 há três meses. Economizamos 2,5 vezes em relação à nuvem nesse período. Este gráfico mostra quanto teria sido nossa conta da nuvem por dia. A linha roxa, na parte de cima, representa o custo que teríamos tido com a nuvem ao longo do tempo. A linha azul é o que pagamos. O resultado é o mesmo. Mas olhem para isto. A quantidade de tokens

05:22 aumentou 1,5 vez. Certo, todos nós já passamos por isso. O custo da nuvem diminuiu 1,5 vez. Esse é o nosso trabalho como gestores. Oferecemos à nossa equipe um coding agent que é essencialmente ilimitado, porque o custo desse coding agent cresce três vezes menos, 2,5 vezes menos, do que o aumento do uso de tokens por tarefa.

05:52 Há outro resultado. O uso de vários modelos que mostrei antes. Vou mostrar a evolução da seleção de modelos feita pelo harness ao longo do tempo. Aqui, parece que vocês veem muito laranja no início de junho e muito amarelo no fim de junho. Há uma mudança completa, o que significa que o harness está selecionando um modelo bem diferente. Isso aconteceu em 12 de junho.

06:23 E foi isto que aconteceu em 12 de junho. Em 3 de junho, o Kimi Kimi 2.6 era, de longe, o modelo mais popular escolhido pelo harness. Em 21 de junho, quem estava vencendo era o Minimax 3. Nós, como humanos, provavelmente conseguimos encontrar, entender e testar um modelo novo que aparece, e nos sentir à vontade com ele. Vocês acham que nós, humanos, percebemos isso? De jeito nenhum. Mas um harness autônomo, um

06:54 coding agent obcecado pelo custo dos tokens vai fazer exatamente isso. É isso que quero dizer quando afirmo que nossa responsabilidade é pensar em oferecer aos desenvolvedores o custo por token adequado para obter o mesmo resultado. É nossa responsabilidade fazer isso. Ziminus vai explicar um pouco mais como funciona, porque o que vocês vão ver

07:24 é open source. Pode falar, Ziminus. >> Certo, mais uma coisa a mencionar. Como eu disse, maximizar o uso de tokens não é mais uma opção para todos e, como gestor da empresa, como vocês provavelmente já ouviram, ter tokens ilimitados para gastar já não parece ser uma realidade. Então, tivemos que construir esse harness para nós mesmos. Ou seja, acabamos gastando demais com o Claude Code há cerca de meio ano. Vimos as contas da nuvem dispararem e começamos a trabalhar no nosso próprio harness.

07:56 Por trás disso, usamos o SDK PyMon OS, mas o objetivo é aproveitar a experiência open source e continuar contribuindo com open source, oferecendo nosso próprio harness. Criamos estruturas como ferment, que se encaixam no tema do Kimchi e são destinadas a tarefas de longa duração. Estimamos que, em média, a participação humana nessas tarefas costuma ser necessária apenas a cada duas ou três horas, e assim por diante. Então, o objetivo é

08:26 usar o harness do Kimchi, iniciar um processo ferment, responder a algumas perguntas e deixar que ele execute a tarefa de programação de forma autônoma por mais de duas horas. O objetivo é que, como ele divide a tarefa em marcos, sabe como implementá-la e, no fim do ciclo, você recebe uma pontuação para o resultado, para saber o que está acontecendo. Voltando à quantidade de modelos usados com o harness do Kimchi, a pontuação serve para provar que, seja qual for o modelo que escolhermos para você, você sempre terá uma pontuação suficientemente boa para o resultado da tarefa que está implementando.

08:57 O objetivo do funcionamento de toda a plataforma Kimchi é não oferecer apenas o coding harness; queremos oferecer uma solução para todo o ciclo de vida do desenvolvimento de software. Então, você faz uma alteração, ele executa um build para você e verifica se algo deu errado. Se algo deu errado, ele volta, faz a alteração de novo, executa outro build, e é assim que funciona esse processo de fermentação. Se tudo estiver concluído e não for necessário fazer mais nenhuma correção, as alterações serão implantadas no ambiente de staging

09:29 ambiente. >> O que eu gosto na forma como vocês explicam é que o harness seleciona o modelo, e o harness está constantemente verificando a qualidade do código e voltando, ou seja, há um modelo de nível superior que verifica a qualidade e conclui que ela não é boa o suficiente: “Faça de novo.” Era isso que eu dizia antes, que ele olha para o resultado. E otimiza os tokens com base

10:00 na qualidade do resultado. Isso é muito legal no harness. >> Isso mesmo. E um artefato só é considerado concluído quando a pontuação da saída é pelo menos B. E, mesmo nesse caso, se você não gostar da pontuação, pode pedir ao agent para voltar e corrigir, e ele vai tentar alcançar uma nota A. A decisão de parar no staging é intencional, por enquanto. Ainda acreditamos que é preciso ter um pouco de envolvimento humano antes de ir para produção, pelo menos neste momento.

10:31 Todos sabemos que, no futuro, o objetivo é evitar isso. Você vai para produção, olha as métricas, os dados de observabilidade e as métricas de SLO do seu ambiente. Se estiver usando Kubernetes, vai querer verificar se os pods não estão falhando e se as verificações de integridade da aplicação estão passando. Então, tudo isso precisa ser feito antes de enviar automaticamente para produção. Essa é uma das coisas que estão por vir. Por enquanto, a limitação é que paramos no staging, mas depois vamos avançar para produção e além. O que acreditamos é que ler código

11:03 já não é suficiente. Então, como provavelmente muitos de vocês sabem, ao longo deste ano, quanto mais engenharia ao vivo ou engenharia com agents fazemos nos nossos ambientes de programação, mais alterações de código recebemos nos nossos conjuntos de mudanças, e isso começa a ficar insustentável de ler, especialmente à medida que mais pessoas com menos conhecimento técnico passam a participar dos seus pipelines. Imagine, por exemplo, um gerente de produto programando, ou minha querida colega Laura começando a programar e, de repente, ela aparece com um PR de 2.000 linhas, e você precisa

11:34 realmente revisar não só as diferenças, mas também a intenção que ela queria alcançar e as especificações que forneceu ao agent de programação. Então, é isso. Seguindo em frente. Uma coisa que criamos em cima disso é o que chamamos de Kimchi Teleport. O Kimchi Teleport permite que você feche o laptop. Ele inicia um sandbox em um ambiente remoto. É um sandbox seguro, com o qual você não precisa se preocupar. Podemos fazer isso tanto na nossa plataforma SaaS quanto disponibilizá-lo na sua instalação on-premises, caso você seja

12:05 uma empresa de tecnologia financeira, por exemplo. Então, vamos gerenciar essas sessões de agents para você. Vamos garantir que elas estejam funcionando e sejam acessíveis tanto pelo seu laptop quanto por dispositivos móveis. Elas ficam rodando em segundo plano. Isso retoma a história que mencionei sobre o envolvimento humano acontecer só a cada duas ou três horas. O Teleport reforça essa ideia. Você inicia o processo e o transfere para o ambiente remoto. O agent é iniciado em segundo plano. Você não precisa se preocupar com isso. Vamos garantir que ele tenha o tamanho certo, os requisitos de segurança adequados

12:36 e tudo mais, e ele continuará rodando até a tarefa ser concluída ou até que seja necessário o envolvimento humano, quando você receberá notificações pedindo esclarecimentos sobre as especificações e coisas assim. >> Pessoal, gosto muito dessa ideia. Olhem só. Esta é uma captura de tela do Teleport. Fico intrigado com o fato de que, às vezes, as inovações mais simples são sempre as melhores. A ideia surgiu quando um de nós estava no avião programando

13:06 e o Wi-Fi caiu. E o que você faz quando o Wi-Fi cai? A programação para, porque ela está acontecendo no seu dispositivo. Acho que não foi o Wi-Fi. Foi a bateria que acabou. Não foi o Wi-Fi. Então, você perdeu… Então, ele… Pronto. O cara ficou parado ali. O que o Teleport faz é pegar todo o seu ambiente e sincronizá-lo com um contêiner que fica em um dos hyperscalers. Agora podemos usar o Google. E, no seu laptop, tudo parece

13:38 exatamente igual. Só que não roda no seu laptop. Parece que roda nele, mas roda em outro lugar do seu ambiente, em um contêiner, em um cluster Kubernetes, dentro da infraestrutura do Google, e continua funcionando mesmo se você fechar o laptop. Que simples. E, ainda assim, esta é a nossa ferramenta favorita. Acho que, da última vez que verifiquei, 62% dos nossos engenheiros só usam

14:09 o Teleport para programar agora. Se estão lidando com aquele problema, vão para casa e ele continua. Estão em trânsito, continua. Estão de férias, nem olham mais para ele. Continua. Muito legal, né? >> Isso mesmo. E há mais. Criamos outra ferramenta chamada Kimchi Studio. Se o Teleport é algo que normalmente uma pessoa usa individualmente, o Studio é como um Teleport para equipes e empresas. O objetivo do Studio é que você tenha um quadro parecido com o Kanban no seu

14:40 ambiente. Ele também roda nos sandboxes do Teleport, em um ambiente seguro. A ideia é que você compartilhe com suas equipes as tarefas em andamento e os planos criados pelo harness de código Kimchi, usando modelos open source ou proprietários. Por exemplo, imagine que você, como engenheiro, está trabalhando em uma tarefa. Começou a implementação e pediu um plano. Seus colegas podem revisar esse plano facilmente, seja um colega engenheiro, seu gerente de produto ou outra pessoa interessada no que está acontecendo. É assim que você trabalha com toda a sua

15:10 equipe nessa jornada de engenharia com agents, em vez de dizer: “Vou digitar este prompt. Vou tentar executá-lo em produção.” Só depois descobrir que as especificações e os requisitos estavam incorretos, que a saída não era o que a tarefa realmente pedia e coisas assim. >> E essa é mais uma coisa que criamos para nós mesmos. Achamos tão legal que decidimos transformá-la em um produto. Como você trabalha com seus colegas se tudo o que tem é um terminal, uma CLI? Como compartilha isso com os outros? Bem, primeiro, ele precisa ficar em algum outro lugar. Então, o Teleport é a base do que chamamos de Studio. E o Studio é uma ótima maneira de visualizar todas as sessões em andamento, incluindo aquelas que estão pedindo uma revisão. Aí, alguém da equipe pode dizer: “Eu cuido disso.” E eu respondo à pergunta que está aguardando revisão.

15:43 Depois que você responde, ela volta para “em andamento” até que a próxima entre em revisão. E você pode ter muitas, muitas dessas sessões em uma equipe, em uma equipe pizza, uma equipe de cinco a dez pessoas. Pense nisso. Mais uma inovação muito simples, mas essencial para a forma como nossos engenheiros programam. Agora eles podem compartilhar de um jeito muito simples, certo? É um navegador. É visual. Eles podem compartilhar e assumir a tarefa de acordo com o estilo Kanban,

16:14 com as colunas “em revisão” e “em andamento”. Podem começar novas tarefas a partir do backlog. E sabe de uma coisa? Se fecharem o laptop, >> Continua funcionando. >> Também é legal. >> Isso mesmo. >> Isso é muito legal. >> Obrigado. >> E… >> É, esquecemos de mostrar a captura de tela. >> Esta é a que assumimos, certo? É essa. Pessoal, vocês podem ver isso no nosso estande, se quiserem saber mais. Estamos no UG4, bem ali, atravessando algumas ruas. Mas deem uma olhada.

16:46 É muito bom. É open source, em grande parte, pelo menos. O harness é totalmente open source. Para usar o Studio e o Teleport, vocês precisam de uma conta do Google. Então, é um pouco mais complicado, mas a instalação leva cinco minutos. Depois, você configura o Teleport e pode ter quantas sessões quiser na sua conta do Google. Aí, pode compartilhar com seus colegas usando o Kimchi Studio. Então, venham falar com a gente. Será um prazer conversar com vocês. Obrigado, pessoal.

17:18 >> Obrigado, pessoal.

17:48 >> Obrigado, pessoal.

Transcrição original

[00:13] All right, guys. Very nice to meet you all. My name is Laura. I’m the co-founder and president of Cast AI, who is the inventor of Kimchi, which I’m going to show you in a few seconds. Um, the talk is going to be about preparatory models for edge case, but use open source for the rest. And you’re going to see some great we have with that with the coding agent called Kimchi. I have the pleasure to be here with Zilvinas. >> Hey guys, I’m Zilvinas. I’m leading engineering for a Kimchi coding platform. >> So, you have Zilvinas who run the entire

[00:44] engineering team for Kimchi. I’m so excited to be here with you. All right, let’s go. So, um, you have you may have seen this in the news. Uh, two two piece of information that came up in the last few weeks. The first one is there’s a company in India that spent $500 million on Anthropic alone in one month. Which is again of a good example of tokens that are completely out of control. The other example is a famous tweet from Uber, the city of Uber, who say that in the last four months he

[01:14] actually used the entire budget of Anthropic for the entire year. And this is how much the token, um, the token maxing or the token cost is a thing for the enterprises. And you’re going to see how we fix this. Companies responded this by limiting the use of token. You may have heard this many, many times with our friends developers. And as a developer, when you limit the amount of token, it feels like this.

[01:45] It’s like, “Hey, you can use your laptop. You have an hour battery and you can only charge once once once a day.” That’s how it feels to limit the amount of token for developer. We at Kimchi think this is wrong. Our jobs as manager is to do the opposite. It’s to ensure that we want to make the tokens unlimited.

[02:16] And inexpensive. Our job is not to prevent the developer to use coding agent. Our job is to make sure they can use it as much as they want for as long as they want in a completely unlimited fashion. This is why we started Kimchi. At Kimchi, we have 300 developers. Oh, sorry. 300 employees. 2/3 of those are developers. The Zivinas run that. And we’ve been using this coding agent for the last 3 months. I’m going to show you what we built, how

[02:49] we built it, and the result of it. And then Zivinas will show you a few more things that make the coding agent really, really cool. It’s coming now. We built an entire token optimization based on this idea. What you see on screen is the true cost of LLM model for the same task. It was made by the famous white paper in a university. And

[03:19] here’s what they say. On one side, you see the cost per token. On the other side, you see the cost per task for the same task with the same quality. That’s is the important, otherwise you cannot compare apple with apple. And here’s what is written here. First, they are all different. But also, look at Gemini 3 Plus. Our our friends at Google. Well, it seems to be a relatively inexpensive model at $3.5 per

[03:50] million token. This is a blended average at the time this study was made. But actually the task to complete with Gemini 3 was $305. Sorry, $705. And look at the others. Minimax 2.7 is one of my favorite. The cost per token is 1.5 and the task the the cost for the task is $148. It means the models are not the same. They don’t cost the same, but

[04:20] also not the same per task. And that’s why we built our coding agent. Wouldn’t it be nice that you have an automated fashion, automated engine, automated harness that will select the right model for the task at the right time based on the outcome of the task? That is what we did with Kimchi Coding. That is what Zilvinas did with his team. And here’s the result. We’ve been using

[04:50] it for 3 months. 2.5 times is the amount of savings we have over cloud for the period. This is a graph of what would have been our cloud bill by day. The purple one on top is what would have been cloud cost over time. The blue line is what we paid. Same outcome. But look at this. The number of tokens

[05:22] increased by 1.5 times. Okay, we all experienced that. The cost to cloud decreased by 1.5 times. This is our job as managers. We provide to our team a coding agent that is essentially unlimited because of that coding agent is growing 3x less, 2.5 times less than the gross of token for the task.

[05:52] There’s another result. The multi-model I showed you before. I’m going to show you the evolution of the selection of the model over time by the harness. And here it looks like you see there is a lot of orange early June and there is a lot of yellow late June. There’s a complete shift, meaning the harness is selecting a very different model. It happened the 12th of June.

[06:23] And this is what happened the 12th of June. The 3rd of June, Kimi Kimi 2.6 is winning by far the most popular of the harness. 21st of June, the one winning is Minimax 3. Also as human, probably we can find and understand and test and be comfortable with a new model coming in. Do you think we look at this as human? Absolutely not. But an autonomous harness, an automated

[06:54] coding agent that is obsessed with token cost is going to do just that. That is what I mean when I say our responsibility is to think about providing our developers with a right cost per token for the same outcome. It is our responsibility to do it. Ziminus is going to tell you a little bit more of how it works because whatever you’re going to see,

[07:24] it’s open source. Go, Ziminus. >> Okay, so one more thing to mention. So, while I mentioned that token maximum is no longer an option for everyone and uh as a manager at the company as the of you guys probably heard, the having unlimited amount of tokens to spend is no longer looking to be like a case and we had to build this harness for ourselves. So, meaning like we ended up spending too much on cloud code like half a year ago. We saw this

[07:56] cloud bills skyrocketing and we started working on our own harness. Behind this is using like PyMon OS SDK, but the goal of that is like to take the open source experience, still contribute back to open source by providing our own harness to open source. Building constructs like ferment which fits into the kimchi theme which is meant for long running tasks where on average we estimate the human in the loop for these tasks is uh typically happening only like every 2 hours, every 3 hours and etc. So, the goal is uh

[08:26] use kimchi harness, you run a ferment process, it asks you a bunch of questions and autonomously runs the coding task for like more than 2 hours. The goal of that is that because it breaks it into milestones, it knows how to implement it and at the end of the cycle you would get scoring for your output so you would actually know what’s happening. And going back to previously discussed like the amount of models used with uh kimchi harness, the scoring is there to prove you that whatever model we will pick for you, you will always have like

[08:57] good enough scoring for the output on the task you’re implementing. The way whole kimchi platform works, the goal is like uh we are not just providing you the coding harness, we want to provide you the full software development life cycle solution. So, you do a change, it runs a build for you, it checks if something broke, if something broke, it will go back, do the change again, rebuild again and that’s how this fermentation process looks. If everything is complete, there is no extra remediation needs to be done, the changes will be deployed to the staging

[09:29] environment. >> You see what what I like with the way you guys explain it is the harness select the model, ferment is constantly checking the quality of the code and going back, meaning there is a a higher order model that is checking the quality and thinking that quality is not good enough, please do it again. This is what I was saying earlier by it looks at the outcome. And it’s optimizing the token based on

[10:00] the quality of the outcome. That is what is super cool with ferment. >> Yep. And artifact is only considered complete once like the output of the scoring is like at least a B as a score. And even for that, like if you don’t like the score, you can ask agent to go back, fix it up and like it will try to achieve a A as a scoring. The intention of stopping at the staging is currently by design. We still believe there’s like some little human that needs to be in the loop before going to the production at least at this point.

[10:31] We all know that the ultimate future is to avoid that. You go to production, you look at the metrics, you look at the observability data, the SLO metrics you have in your environment. If you’re running on Kubernetes, you want to check if the pods are not crashing, if application health checks are passing. So, all of these things need to be done before it ship it ship to production automatically. So, this is like one of the things that are coming. So, the current limitation we stop at staging, but they’ll go to production and and further on that. What we believe is that reading code is

[11:03] not enough anymore. So, like probably most of you know this like across this year like the more live engineering or agentic engineering we do in our coding environments, the more code changes we get in our change sets and it kind of becomes unbearable to read, especially as you keep bringing like a little bit of a less technical personnel into your pipelines. So, imagine like product manager doing the coding or my dear colleague Laura starting to do some coding and suddenly he comes up with a PR which is like 2,000 lines long and you need to

[11:34] actually review not just the differences but the actual intent which he wanted to achieve and the specifications which he provided to the coding agent. So, yeah. Moving on. One thing we built more on top of that is the thing we called Kimchi Teleport. So, Kimchi Teleport allows you to close your laptop. It spins up sandbox in the remote environment. It’s a secure sandbox where you don’t need to care about anything. We can do that both on our SaaS platform. We can ship it to your on-premise deployment if you’re

[12:05] like a financial technology company and things like that. So, we will manage these agent sessions for you. We will make sure they are running. They are accessible both from your laptop, from mobile devices. They are running in the background. So, it goes back and ties to the story that I mentioned about the human in the loop is only appearing like every 2 or 3 hours. So, Teleport emphasizes that. You run your process. You teleport it to the remote environment. The young spins up in the background. You don’t need to care about it. We will make sure it’s the right size, it’s the right security

[12:36] requirements and everything else and that will keep on running until the task is done or until the human in the loop needs to be involved, get notifications for some clarification of specs and things like that. >> Guys, I really like this idea. Look at the this This is a screenshot of Teleport. I am puzzled that sometimes innovations are always the simplest one. Like this was born out of the idea that one of us was in the plane coding

[13:06] and then Wi-Fi breaks. And what do you do when Wi-Fi breaks? It breaks the coding because it lives inside your thing. I think it was not the Wi-Fi. It was the battery that broke. Not the Wi-Fi. So, you lost So, he That’s it. The guy was stopped there. What Teleport does it it takes all your environment, it synchronizes with a container that live inside one of the hyperscaler. Now we can use Google. And locally on your laptop, it feels

[13:38] exactly the same. It just doesn’t run inside your laptop. It feels like it. It runs somewhere else in your environment in a container in a Kubernetes cluster inside the place at Google that will continue running even if you close your laptop. How simple that is. And yet our favorite tool is this one. I think the the last one I I I looked at it, 62% of our engineers are only using

[14:09] Teleport when they are coding now. For that problem, they go home and continues. They’re in transit, it continues. They’re on holiday, they don’t look at it anymore. It continues. That’s so cool, huh? >> Yep. So, there is more to that. So, we built another tool called Kimchi Studio. If that Teleport is something typically individual uses, Studio is kind of like a Teleport for teams and enterprises. The goal behind the Studio is that you have a camera like board on your

[14:40] environment. It again runs in the Teleport sandboxes in the secure environment. The thing here is like you are supposed to share your tasks on work in progress and plans which are made by the Kimchi code harness with open source or proprietary models with your teams. So, for example, imagine you as an engineer you are like working on a task. You started implementing asking for a plan. The plan can be easily reviewed by your colleagues like by your peer engineer, by your product manager or someone else who cares what’s happening and this is how you kind of work with your

[15:10] whole team on collaborating on this agentic engineering journey instead of like saying, “Oh, I’m going to type this prompt. I’m going to try to execute it to the production.” Only later on to learn that the specification and requirements were incorrect, uh the output is not what was actually wanted by the task and things like that. >> And this is yet another thing we built for ourself. We found it so cool, we decided to make it a product. How do you work with your colleague if what you have is a is a is a terminal, a

[15:43] CLI? How do you share that with the others? Well, first he has to live somewhere else. So, Teleport is the base of what we call studio. And studio is a very nice way to visualize all the sessions that are running, including those that are asking for a review. And then someone in the teams can say, “I take it.” And I answer the I I answer the question that is for review. Then you answer it, it goes back to in progress

[16:14] until the next one goes into review. And you can have many, many of those in a team in a pizza team, a team of five to 10 guys. Think about it. A yet yet a very simple innovation that is so essential in how our engineers are coding. They can now share in a very simple way, right? It’s a It’s a browser. It’s graphical. They can share and they can take over the task according to the Kanban style

[16:46] of what is in review, what is in progress. They can start new ones with backlog. And you know what? If they close the laptop, >> It still works. >> It’s also cool. >> Yep. >> This is really cool. >> Thank you. >> And >> Yeah. We forgot to show the screenshot. >> This is the one that we took over, right? That’s the one. Guys, you can see this at our booth if you want to uh to see more of it. We are in UG4, it’s exactly this way across a few streets. But, have a look at it.

[17:18] It’s really good. It is open source, most of it, at least. The harness is entirely open source. Studio and Teleport, you need a Google account. So, it’s a little bit more more complicated, but it’s a a 5-minute install. And then you get your Teleport set up, as many sessions as you want inside your Google account. And then you can share with share it with your colleagues with Kimchi Studio. So, come see us. We’ll be delighted to speak to you. Thank you, guys.

[17:48] >> Thank you, guys.