Armagan Amcalar

OpenAI's new GPT-5.6 $1 model (Luna) just beat the $5 flagship (Sol) on our agentic benchmark. With SERV Reasoning, all three models performed better, while Luna outscored every configuration tested. Thanks to SERV, failure rates dropped by up to 42.7%.* That's the thesis SERV is built on: Reliability in AI is the real product. Large-scale AI adoption is waiting on the layer that makes AI dependable enough for production. Standout findings: - Luna + SERV tops the table at 1/5 of Sol's price. - These tiers behave less like mini/nano distillations and more like independent takes on one architecture with distinct post-training. - Luna behaves like a smaller model RL-trained hard for agentic instruction-following and steerability, which would explain why it takes the biggest lift from SERV. *i.e. the relative drop in failure rate: Luna went from 12.89% failed tasks to 7.39%. More results and insights coming soon.

I spent the entire last week at the AI Engineer World's Fair in SF with where top AI labs, founders, Fortune 500 CTOs & AI Engineers meet. Really perfect timing - having boots on the ground right before we deploy SERV Reasoning v2, because the problems v2 ships against are exactly what i heard in meetings, over and over. To give you a quick recap, it was a fruitful week overall: 60+ new companies from the fair now in our structured pipeline, from two-person agent teams to trillion-dollar clouds (a few that you'd recognize instantly, and at least two are infra your own stack probably touched today). One of the most interesting part was the Startup Battlefield where new startups pitched their projects. After numerous meetings, one thing is clear: everyone in Enterprise AI is doing it backwards. The current flow: 1.) Tune the model 2.) Ship the agent 3.) Debug a black box after it embarrasses you in production A version of the same confession kept surfacing: "we shipped an agent, it did something weird in front of a customer, so we pulled it - cause nobody on the team could explain a single decision it made." Others told me they burn anywhere between $10-$90k (!) a month on inference and can't drive it down. It became "cost of doing business." Now that SERV v2 is here, we are solving both these issues. Two confessions with two direct answers in v2: 1.) The black box: SERV makes agent reasoning traceable - you see how the agent thinks, not just what it outputs. And with Shadow Agents, every output gets reviewed against the original brief by a separate verification agent before anything ships. The "weird decision" gets caught in verification. Trust first, then scale. 2.) The burn rate: the reasoning engine lets you run the same workloads on much smaller models with better outputs. Verification Hints give agents signal on what a correct output looks like before they generate, cutting expensive re-work. And you don't have to take our word for any of it - Benchmark Tooling shipped in v2 shows you the cost savings on your own workloads before you integrate. That's the whole idea behind SERV Reasoning v2. Judging by last week, it's exactly what the room is starving for. Q3 is starting off with a bang.

We have been cooking hard for months, and just like we always are, we are ahead of schedule for SERV Reasoning v2. We have seen strong adoption during our private beta, and experienced first hand how v2 features are an immediate need today. So we decided to ship faster.

Our team has been working around the clock to expand SERV Reasoning into the most comprehensive enterprise-ready agent solution on the market. Big technical upgrades coming this month, stacked summer incoming.

How to keep AI spend flat while token usage grows exponentially: Not with friction and spend alerts. With better defaults, routing, and caching. Better Defaults (not Usage Caps) – Engineers can choose any model they want, but defaults matter. We’re experimenting with defaulting to open weight models like GLM 5.2 and Kimi 2.7 through our LLM gateway, while still encouraging engineers to choose the right model for the task. 91% of our employees were never hitting their usage caps, so instead of lowering caps and driving up alerts, we're moving to cheaper defaults. Note that code reviews use a diversity of models, so they can check each other's work. Better Routing – In our custom harnesses, we preprocess prompts and route to the best model for the job, considering cache hits and model pricing. For instance, you may want a frontier model for planning, but not for execution where they can be overkill. Ultimately, humans shouldn't be choosing models - AI can automate this task. Better Caching – Cache misses are the easiest way to drive your cost up. All of our requests are cache aware, so we’re reusing a warm cache wherever possible. For example, our cache hit rate went from 5% → 60% in LibreChat once properly implemented. Keep Context Lean – Start fresh sessions when switching tasks. Scope file context narrowly. Disconnect unused tools. Don't just compact. The goal isn't fewer tokens used, it's fewer tokens wasted. Better Visibility – Our engineers can use as many tokens as they want, from whatever model they want, but we’ve made usage visible – and the more you spend on AI, the more impact we expect. The goal isn't to suppress usage. It's to build the infrastructure that makes exponential growth sustainable. Putting this into practice has cut our AI spend nearly in half, while our token usage continues to grow.