Thie episode is about Intelligent Terminal 0.2, .NET 11 Preview 7, GitHub updates, Visual Studio 18.9, Visual Studio Code 1.133 and 1.134 and Windows App CLI 0.6.
00:00 Intro 00:15 Intelligent Terminal 01:05 Dotnet 02:27 GitHub 03:10 Visual Studio 03:44 Visual Studio Code 04:30 Windows
Moving live voice agents from demo to production requires rigorous, automated testing to handle the unpredictability of real multi-turn conversations. ADK now provides native live evaluation, allowing developers to test graph-based agent workflows against LLM-driven simulated users that generate actual audio via Gemini TTS. By defining evaluation scenarios and natural-language rubrics, you can automatically score audio responses and tool executions, inspect the resulting transcripts in ADK Web, or run the CLI directly in your CI/CD pipeline.
While most AI coding tools default to cloud-hosted models, local model runtimes have become a viable alternative for developers who want to keep code on their own machines, avoid per-request API costs, or have to work without an internet connection.
Tools such as Cline, Continue, and Aider can already be pointed at runtimes like Ollama or LM Studio. At the same time, GitHub added local-model support to Copilot CLI in April, including an offline mode for fully air-gapped setups.
The catch is that “local” generally still leaves much of the assembly to the developer. You have to choose a model and a suitable quantization for your hardware, configure the runtime and context settings, and work out which combination performs well with the agent.
And that last part really does matter: models small enough to run comfortably on a laptop can still struggle with the tool use, reasoning, and longer-running tasks that coding agents demand.
This is why JetBrains has now built Junie Local, a free version of its coding agent designed to run entirely on the developer’s own machine.
Local market
By way of a brief recap, JetBrains — the developer tools company behind IntelliJ IDEA, PyCharm and WebStorm — launched Junie in January 2025 as an AI coding agent embedded in its IDEs, capable of planning tasks, modifying code, running tests and inspections, and working with the context of a developer’s project. It has since expanded into a standalone CLI.
Junie itself isn’t exactly new to local models. In a blog post published on Monday, JetBrains’ head of marketing Dmitry Savelev notes that developers have been able to connect the agent to runtimes such as Ollama and LM Studio for some time, load whichever model they want, and have Junie run against it locally.
However, with Junie Local, JetBrains has picked the model, quantized it, and tuned its inference engine and agent harness around that specific combination. Setup is handled from inside Junie itself: running /local downloads the model and inference engine, starts a local server, and switches the agent over automatically. There is no separate Ollama or LM Studio installation, endpoint to configure, or model profile to write.
The first step is simply choosing Junie Local from the model selector, where it appears alongside the usual array of cloud-hosted models.
Junie’s model selector offers Junie Local alongside its cloud-hosted models
Once the download and setup are complete, Junie switches to the local Qwen model, which then appears in the CLI like any other model option.
Junie running with Qwen3.6 locally
From that point on, inference happens entirely on the developer’s machine.
Under the hood: Why Qwen3.6 — and why an M5 Mac
It’s worth noting that JetBrains has been very specific about its model choice and hasn’t opted for the latest, shiniest open-weight version. Junie Local uses Qwen3.6-27B, a 27-billion-parameter open-weight model released in April, even though the newer Qwen3.8-27B arrived earlier in August with improvements.
“On today’s Macs, [Qwen] 3.6 wins.”
Savelev notes that the choice came down to how the two models behaved inside Junie on current Macs, with Qwen3.8 requiring its reasoning mode to be enabled to work reliably with the agent; with reasoning switched on, tasks took roughly four times longer. For Junie Local right now, Qwen 3.6 offers the better balance of reliability and speed.
“On today’s Macs, 3.6 wins,” Savelev writes.
JetBrains runs Qwen3.6-27B at 4-bit using an inference engine based on mlx-vlm, which in turn uses MLX, Apple’s machine-learning framework for Apple Silicon. It’s a similar underlying approach to the one Ollama adopted in March, when it moved its Apple Silicon engine onto MLX to take advantage of the chips’ unified-memory architecture.
There is a fairly substantial hardware floor, though: JetBrains confirms that Junie Local involves about 20 GB of downloads, and requires macOS 26, at least 64 GB of unified memory, and an Apple M5 chip or newer. In real terms, that 64 GB requirement puts MacBook Pro users into M5 Pro or M5 Max territory — in other words, this is firmly a high-end Mac proposition.
JetBrains acknowledges that those requirements will put Junie Local beyond the reach of plenty of developers who might otherwise be interested in running it.
“We know that an M5 Mac with 64 GB of RAM is a big ask,” Savelev writes. “We are not going to pretend otherwise. That is simply what it costs to run a 27B model well today, and it is the number we are working hardest to bring down.”
“We know that an M5 Mac with 64 GB of RAM is a big ask. We are not going to pretend otherwise.”
The intention is to reduce memory requirements, support a wider range of hardware, and continue optimizing the underlying stack.
“If the lofty requirements are the reason you cannot try Junie Local, rest assured that we are working to bring them down,” Savelev adds.
Where local pays off
Ultimately, the hardware requirement is closely tied to where JetBrains identifies the real performance bottleneck for a local coding agent. The tokens-per-second metric measures how quickly a model generates output, but an agent can spend much of its time first ingesting source files, prompts and other context — the prefill stage — before it starts producing an answer.
“Everyone benchmarks generation speed,” Savelev writes. “For a coding agent, that turns out to be the wrong number to chase because most of the time is spent on prefill, while the model reads files to work out what is going on. Optimizing for prefill is where the real gains were.”
Being free and unmetered also changes the kinds of jobs developers might be willing to hand over. JetBrains positions Junie Local as particularly well-suited to long, repetitive, and mechanical work — multi-file refactors and renames, filling test-coverage gaps, dependency upgrades, and framework migrations — where the agent can keep working and iterating without the developer having to think about how many tokens it’s burning through.
“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance,” Savelev writes.
“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance.”
For everyday development work, Savelev reckons users are unlikely to notice much of a gap compared with stronger cloud models. However, he does concede that more complex architectural reasoning remains better suited to those models.
And then, of course, there is arguably the biggest reason developers have been interested in local models in the first place: privacy. Running the entire agent locally means that no external model provider sits between the developer and their code, and that no source, prompts, or generated changes need to leave the machine. For developers working on proprietary code, under client NDAs, or in environments where sending source to a third party is simply off the table, that is a substantial part of the appeal.
“Everything after the download happens on your hardware, so your prompts, source, and diffs stay put,” Savelev writes.
At WordCamp US last week, we unveiled a completely reimagined WordPress Studio desktop app, rebuilt from the ground up around Studio Code, our AI WordPress expert.
With this new Studio desktop experience, you can describe what you want to the expert WordPress agent, watch it come together in a live preview, point at anything that’s off, and ship it to production when it’s ready, all in one window.
You’re left with a full WordPress build you own and can maintain, not throwaway code.
Today, it’s available in beta for everyone to try.
And if you’re a brand-new Studio user — welcome! You’ll see the new agentic UI as default, so there’s no need to opt into the beta.
The Studio interface has been reimagined to focus on agentic development, with three panels next to each other in a single window:
Your Sites on the left
A chat with Studio Code in the middle
A live preview of your site on the right
Switch on the new UI without losing a thing
If you’re an existing Studio user, you won’t lose your current sites when you switch the new experience on; every local site from the old experience carries over automatically. Nothing to migrate, re-import, or rebuild.
Pick a site to jump back into it, start or stop it, or open its settings.
Chat with Studio Code to make it happen
The agent in the middle panel is Studio Code, our coding agent built for WordPress that knows blocks, themes, and WP-CLI natively.
In fact, this is what WordPress developer Olivier Gobet said about his experience building with Studio Code:
I’ve been building WordPress sites for almost 20 years, and Studio Code has genuinely changed the way I work. For the first time in a long while, I feel like I’m no longer limited by the technical barriers of implementation. Instead of asking myself, Is this possible?, I can focus on, What do I want to build?
You describe what you want in plain language, and Studio Code builds it on a real local WordPress install where you can build, vibe, and experiment. Chat history is stored so you can easily stop and restart a work in progress, and you can always spin up a new chat for each site when you want to start fresh:
If you want to give Studio Code standing instructions it follows on every task, set them under Settings → AI.
That same screen is where you can also toggle agentic features off entirely if you’d rather build WordPress the classic way.
Watch it build in real time
Changes render live in the in-app preview as Studio Code works. You see the site take shape with every ask, so there’s no switching between browser and UI to check whether an edit landed.
It’s a working preview of your local site, too: click any link to move to other pages, just as a visitor would, and watch them update as Studio Code makes changes. You can even access the admin dashboard to manage posts, pages, products, and everything else you’re used to.
One of your favorite tools is still available, too, just in a different spot. Use the Annotate button to send specific, targeted requests to Studio Code.
Click the elements you want changed, stack up your notes, submit them with one click, and Studio Code makes every edit in one pass. It’s the client-feedback loop, built into the tool, and it’s a natural fit for your workflow of reviewing, marking up, and revising a site fast.
Build locally, ship when you’re ready
The core functionality of Studio remains too: you’re able to spin up a real, local WordPress site in seconds by clicking the + button in the toolbar.
Because everything you build happens locally, you can try things, break things, and start over with zero risk to a live site. Nothing goes live until you say so.
When it’s ready, you ship to fast, managed hosting on a paid WordPress.com or Pressable plan in a few clicks with Studio Sync.
What you build in Studio is real WordPress: portable, dependable and yours to maintain.
Meet the new WordPress Studio
Give the new Studio desktop beta a real workout. Point it at an actual project, a brief, some images, a vibe, and see how far it gets, where it shines, and where it falls short.
During this beta period, you’ll get a one-time credit gift from us to try it out. Once you hit your limit, top-ups are available for just $10.
And we want to know how it goes. Open a GitHub issue with your feedback, bug reports, and ideas. Your input shapes what comes next.
Set it up once, then talk to your site to publish posts, moderate comments, check traffic, update media, and handle the small jobs that start after the writing ends.
After you add the plugin, type @WordPress.com in any chat and hand off those chores to ChatGPT.
Publish your words without the busywork
You wrote the post, maybe in your notes app, maybe in a doc, maybe in a voice note. Getting it live on your blog can be time-consuming, but with the ChatGPT plugin, you just need to ask.
Try running some of these prompts directly in ChatGPT:
Your content stays yours, and ChatGPT helps with the formatting, scheduling, and the clicking around.
Run your site by asking
Once connected, ChatGPT can read your stats, your comments, your media library, and your site’s activity log, so questions about your site get answered where you asked them.
Alt text deserves a special mention here. It’s the accessibility task everyone means to do and almost nobody does, because doing it means setting the alt text one image at a time.
Now you can set alt text through a conversation with ChatGPT, and your readers who use screen readers get a better experience for it.
Change your site, conversationally
The plugin can make changes across your site, from adding pages and updating site settings to working with your existing design.
The WordPress.com ChatGPT plugin is optional and off by default. When it’s enabled, ChatGPT has to ask you before making changes to your site.
If it’s about to publish or edit content, launch your site, change settings, or delete something, you’ll see what it plans to do before anything changes.
New posts and pages start as drafts by default, and for anything that publishes, edits, launches, or trashes something, ChatGPT describes exactly what it’s about to do and waits for your confirmation.
Connect your site to ChatGPT
Getting started only takes a few steps and after that, WordPress.com is available whenever you type @WordPress.com in ChatGPT.
Then, open WordPress.com in ChatGPT, select “Install plugin,” sign in with your WordPress.com account, and approve the connection. Then type @WordPress.com and hand off the first chore.
The full setup guide is in our support docs, and if you’d rather connect Claude or another AI assistant, that works too.
MCP access is included with every paid WordPress.com plan, and Free sites also get this during the first 30 days after creation.
Your writing stays yours, and now you can work with your site without having to go to it. Writing was always the fun part anyway.
If you want to hold costs down, efficient resource management is paramount. One of the critical resources in AI applications is token usage. Tokens are the basic units of text that models process, and managing them effectively can lead to significant cost savings and improved performance. This post explores various techniques for measuring and minimizing token usage within the Microsoft Agent Framework.
Understanding Token Usage
Before diving into the techniques, it’s essential to understand what token usage entails. In the context of AI models, a token can represent a word, part of a word, or even punctuation. Each interaction with the model consumes tokens, both for the input provided and the output generated. Therefore, optimizing token usage is crucial for maintaining efficiency and controlling costs, especially in applications with high interaction volumes, such as chatbots and multi-agent systems.
Key Techniques for Minimizing Token Usage
1. Token Management
One of the most straightforward methods to control token usage is through effective token management. By setting a maximum number of tokens for responses, developers can prevent excessive consumption and ensure that outputs remain concise and relevant.
Example in C#:
var response = await agent.GenerateResponseAsync(input, maxTokens: 100);
In this example, the response is limited to 100 tokens, which helps maintain brevity and relevance.
2. Context Management
Context management is another critical area where developers can minimize token usage. Instead of sending the entire conversation history to the model, it is more efficient to retain only the most relevant exchanges. Typicallly this comes down to retaining only the most recent exchanges. This approach not only reduces the number of tokens sent but also enhances the model’s focus on pertinent information.
Example in Python:
context = [message for message in conversation_history[-5:]] # Keep last 5 messages
response = agent.generate_response(input, context=context)
By limiting the context to the last five messages, developers can significantly reduce token consumption while still providing the model with enough information to generate a relevant response.
3. Efficient History Management
When interacting with the model, it is essential to avoid resending large outputs or logs with every API call. Instead, developers should focus on sending only the essential context. Utilizing new threads for stateless interactions can also help prevent the unnecessary transmission of long histories.
Example in C#:
var newThreadId = Guid.NewGuid().ToString();
var response = await agent.GenerateResponseAsync(input, threadId: newThreadId);
This method ensures that each interaction is treated independently, minimizing the amount of historical data sent with each request.
4. Lightweight Summarization
To maintain continuity in conversations while reducing payload size, developers can implement lightweight summarization techniques. By periodically summarizing previous interactions, the summary can be sent as context, which helps keep the conversation relevant without inflating token usage.
5. Token-Optimized Object Notation (TOON)
Token-Optimized Object Notation (TOON) is a powerful technique for structuring data in a way that achieves high compression ratios. By using TOON, developers can significantly reduce token usage, with some reports indicating reductions of up to 98% for certain payloads. This method is particularly useful for applications that require the transmission of structured data.
6. Server-Side Computation
Another effective strategy for minimizing token usage is to move computation tasks to the server rather than performing them within the context of the model. By offloading these tasks, developers can reduce the amount of data sent to the model, thereby lowering token consumption.
Measuring Token Usage
To effectively manage token usage, developers must also implement robust measurement techniques. Here are some strategies for measuring token usage within the Microsoft Agent Framework:
Metrics Integration
Utilizing built-in metrics from the Microsoft Agent Framework allows developers to monitor input and output tokens, estimated costs, and latency. This data is invaluable for optimizing performance and identifying areas for improvement.
Breakdown Analysis
Conducting a breakdown analysis of token usage across different stages—such as retrieval, planning, and execution—can help developers pinpoint where savings can be made. By understanding which stages consume the most tokens, developers can focus their optimization efforts more effectively.
Real-World Use Cases
The techniques discussed above can be applied across various real-world scenarios, leading to significant improvements in efficiency and cost-effectiveness.
Chatbots
In chatbot applications, implementing these techniques can lead to substantial cost savings and enhanced performance, particularly in high-traffic environments. By managing token usage effectively, chatbots can handle more interactions without incurring excessive costs.
Multi-Agent Systems
In systems with multiple agents, distributing tasks among specialized agents can reduce redundant context passing and lower latency. This approach not only minimizes token usage but also enhances the overall responsiveness of the system.
Conclusion
In conclusion, managing and minimizing token usage in the Microsoft Agent Framework is essential for developing efficient AI applications. By implementing techniques such as token management, context management, efficient history management, lightweight summarization, TOON, and server-side computation, developers can significantly reduce token consumption. Additionally, measuring token usage through metrics integration and breakdown analysis allows for continuous optimization and improvement.
As the demand for AI applications continues to grow, adopting these strategies will not only enhance performance but also lead to substantial cost savings. By prioritizing token efficiency, developers can ensure that their applications remain competitive and effective in an increasingly crowded marketplace.
========== TOKEN USAGE FOR FIRST DRAFT OF THIS BLOG POST ========== Input tokens: 4180 Output tokens: 1838 Reasoning tokens: 0 Total tokens: 6018
Log in
