Helmcode

Not every AI task needs the smartest model available. Sometimes you just need to classify a ticket, extract a few fields or summarize a document. Using a frontier model for everything is a bit like hiring your most expensive engineer to rename files all day. We have an extensive guide to open models for every use case (more than 80) you can finde here: helmcode.com/open-model-guid…

🤔 About AI Act: Spain's data protection authority (AEPD) just warned a company that planned to score CVs with AI. The tool wasn't even live yet. The case raises a question many teams building on third-party APIs haven't asked: when does your app make you a high-risk AI provider under the AI Act? You don't need to train a model for that. A system prompt like "score this CV from 1 to 10 and reject anything below 5" is enough to land in Annex III. Put that app into service under your name and you can be its provider. Rodrigo Cilla Ugarte walks through it, using the CV case as an example: → What the AEPD asked for: privacy by design, a DPIA, transparency and human oversight that can actually question the score → Why the CV travelling inside the prompt matters (photo, date of birth, career history) → The three cases in Article 25 → Why "summarise this CV" and "score it and reject below 5" can end up in very different places → Deadlines: Annex III obligations moved to 2 December 2027, but the GDPR and Spain's Royal Decree 723/2026 already apply Plus five things to check before you deploy something like this. Full article here: helmcode.com/posts/high-risk…

When you send a request to an open model on Helmcode, it runs on infrastructure we operate in Europe. We don't forward it to whichever third-party provider happens to be cheapest that day. And we don't store your prompts. It's a fairly simple distinction, but one we think matters a lot when companies start building with real customer data. You should know who's running your AI.

One tweet can start a company. How far can we take it? 🚀 We're launching the Helmcode YouTube channel! And we're kicking things off with this incredible intro created by @Saulgmz_. Absolute cinema. 🚬 Sound on. 🔊 We want to hear what you want to see on the channel. We've prepared a nice form for getting your responses: nan.builders/prompt And if this is just the intro, imagine what's coming next. 😏 youtu.be/c7-QvNDoLvE

This is how our inference architecture works at Helmcode. Serving inference in production is more than hitting the API you use. 🤷‍♂️ You need routing, fallbacks, observability, cost control, and the right deployment model. Here's a closer look at how we approach it at Helmcode: 1/ API Gateway & Routing Every request enters through an OpenAI-compatible API. We handle authentication, rate limits, and routing to the appropriate model and infrastructure. 2/ Model Serving Different models have different requirements. We run inference workloads across GPU infrastructure, managing model replicas, batching, and concurrency to balance throughput and latency. 3/ Scalability & Reliability Traffic isn't constant. The infrastructure needs to handle demand spikes, distribute requests across available capacity, and recover when something fails. 4/ Observability We monitor latency, token throughput, GPU utilization, errors, and request volume to understand how the system is performing and identify bottlenecks. 5/ Cost & Deployment Infrastructure decisions directly affect inference costs. Shared, dedicated, and on-prem deployments have different trade-offs in utilization, isolation, performance, and economics. All of this needs to work together while keeping the API simple for developers. This is how we make open model inference accessible to businesses at Helmcode.

💸 How to fix your AI bill. A comprehensive guide about AI cost optimization explained by our platform team 👇 We've just published a practical guide to reduce your AI cost. 14 chapters covering model selection, routing, caching, agent loops, RAG, GPU economics, and the decisions that actually reduce inference costs. It's free, with three reading depths, real calculations, a capacity calculator, a spreadsheet, SQL templates, and a downloadable PDF. 👉 Read the full guide: helmcode.com/guides/ai-cost-… The quick summary, in 5 points: 1/ Stop optimizing for price per token. A model that's 5x cheaper means little if it needs three attempts to complete the same task. Measure cost per successful task, including retries, tool calls, and failures. 2/ Your best model shouldn't handle every request. Classification, extraction, summarization, coding, and complex reasoning have different requirements. Route tasks to the models that can handle them reliably. Save expensive reasoning for the work that needs it. 3/ You're probably paying for the same work more than once. Repeated context, duplicate tool calls, unnecessary retrieval, and agents that keep searching after finding the answer. Caching, context management, and better stopping rules can make a real difference. 4/ Agents need budgets, not just prompts. An agent can turn a cheap request into an expensive workflow through retries, searches, and tool calls. Set limits on steps, time, and spending. Track the cost of the complete workflow. 5/ Self-hosting isn't automatically cheaper. A GPU sitting idle still costs money. Compare infrastructure, utilization, peak demand, latency, and engineering time against API pricing. Sometimes dedicated infrastructure wins. Sometimes pay-per-use does. Sometimes a flat rate makes more sense. We've also included a fictional company that starts with a $2,600/month AI bill. Across the guide, we walk through the decisions that change that bill, one by one. No magic 90% savings claim. Just the calculations and trade-offs behind each decision. Free guide, available in EN/ES: helmcode.com/guides/ai-cost-…

The @Revolut thing is getting noticed... How their engineering team cut their AI bill by 90%. But a lot of people/ companies are wondering how they moved to open models. Here’s a short video on how they did it and how you can do it too.

A coding agent can send 100,000 tokens in a single request. Conversation history, files, tool outputs… And it keeps sending much of that context with every new request. Cristian Gutiérrez (@crstiax) has been digging into what happens when you serve these workloads with vLLM, using real production traffic at @helmcode . Some of the numbers are pretty interesting. – 81% of incoming tokens were already cached, which gives you an idea of how much context agents repeatedly send. - He also ran 24 agents simultaneously on the same GPU with two different models (Qwen 3.6 and Qwen 3.8). A 35B MoE model delivered 30 tokens/s per user, while a dense 27B model managed just 3 t/s. - One of the more surprising results came from Multi-Token Prediction. It improved performance with a single agent, but latency got significantly worse with 32 agents running at once. Cristian goes through the tests, explains what's happening under the hood and shares the vLLM @vllm_project configurations so you can try them yourself. A really useful read if you're working with agents and open models in production. And some info from @UnslothAI quantization and @ornith_ working on a 16GB GPU. 👉 helmcode.com/posts/serving-a…

We like predictable AI bills. Not because we're obsessed with saving money, but because we've seen how much easier it is to build when you know what something is going to cost. That's why we offer flat-rate access to the open models we operate. Use the models, test your ideas, build your agents. No per-token meter running in the background. There are still rate limits, of course. Infrastructure isn't infinite. But your bill doesn't grow with every token you generate. helmcode.com/pricing

A simple explanation of what we do at Helmcode. Qwen, DeepSeek, GLM, Gemma and other open models, all running on infrastructure we operate and accessible through a single API and API key. We're the layer between those models and your product, your agents or your company. And we take care of the infrastructure behind them. That means your requests aren't being sent to a different third-party provider. They run on infrastructure we operate in the EU, with zero prompt logging. Because we believe you should have control over your data, including where it's processed and who has access to it. And because our API is OpenAI-compatible, you can switch between models without rewriting your integration. Just change the model name. We think knowing who's actually running your models matters just as much as choosing which models to use. Especially when you're building something that needs to work in production. helmcode.com