In this blog, let us see about Harness, DeepSeek Harness, and how to create our own plugin for DeepSeek Harness.

What is Harness

The LLM API call is a part of an agent. We still need to provide context, expose tools, maintain memory, manage permissions, plan the steps, write retry loops, error handling, and output validation. All of them together is called a Harness.

So, a good harness makes a good agent.

I have read some articles about Harness Engineering. Attaching a few of them here for more details.

• Learn Harness Engineering

• Harness Design of Claude Code and Codex

• Harness Engineering: A Design Guide to Claude Code

Here is a video explaining what Harness is.

Now, let us see about DeepSeek Harness.

DeepSeek Harness

DeepSeek AI has released DeepSeek Harness, an open-source agent harness. The interesting part is its architecture. It treats everything as a plugin. Those plugins can be loaded, unloaded dynamically. Let us see how it works, how to set it up, and how to create our own plugin.

1. Why Everything is a Plugin

2. How DeepSeek Harness Works

3. How to Set Up and Use DeepSeek Harness

4. How to Create Our Own Plugin

1. Why Everything is a Plugin

DeepSeek Harness uses Cordis as the underlying framework. Cordis manages plugins, their dependencies, and the changes they make to the application.

Cordis provides a shared context for all the plugins. A plugin can add a service, listen to an event, or add some behaviour to the agent. When we remove the plugin, the changes added by that plugin are also removed. This is how DeepSeek Harness can load, unload, and replace plugins dynamically.

For example - Even the Web UI is built as a plugin. For example, the sidebar is a plugin. We can disable it from the configuration, reload the Web UI, and the sidebar will be removed. We can enable it again without making any changes to the core application.

Lets now see how it works

2. How DeepSeek Harness works

When we start DeepSeek Harness, it loads a profile. The profile decides which bundles and plugins should be loaded.

DeepSeek Harness has two main profiles:

• web profile starts with the Web UI.

• The headless profile runs it from the terminal without the Web UI.

Each profile brings a set of related plugins. For example, the Web one loads the plugins needed for the Web UI. This way, DeepSeek Harness loads only the parts required for the selected profile.

Once the profile is loaded, we can start a session and send a message.

Here is how the message flows inside harness.

We can see all these details inside the Trajectory tab. It shows steps, tool calls, and results returned to the model.

3. How to Set Up and use DeepSeek Harness

We need Node.js to run DeepSeek Harness. Once Node.js is installed, run this command

npx @deepseek-ai/dsh web

But above command did not work properly for me. So, I cloned the repository and ran it from the source.

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

pnpm dsh web - will open the web UI in the browser at http://localhost:3080

Now we can plugin the model we want. Go to settings and change the model.

Check Plugins tab, and you can see loaded plugins.

4. How to Create Our Own Plugin

We can create plugins in two ways.

1. Create plugin Manually ( by writing plugin code )

2. Use Creator Mode in the Web UI and ask the agent to create it for us.

Creator Mode will create the plugin and load it into the current session. We do not need to do any coding.

Creating voice mode as a plugin- Creator Mode

For example, there is no voice input option in the DeepSeek Harness Web UI. So, let us ask Creator Mode to add a microphone button near the prompt field. The voice should be converted into text and added to the prompt field. We should also be able to edit the text before sending it.

Step 1: Open a Web session and select Creator Mode. I gave this prompt.

There is no voice input in the Web UI. Can you add it as a plugin?

Add a microphone icon near the prompt box. When I click it and speak, the voice should come as text in the prompt box. Do not send it directly. Let me check and edit the text before sending.

It started creating the plugin. Once done, it loaded the plugin into the session. You can check the video below to see how the plugin was created and loaded.

Creating voice mode as a plugin- Manual Mode

Now, we will create the same Voice Input plugin by writing the code. You can refer docs for creating your own plugin.

Inside the cloned DeepSeek Harness repository, I created a folder named voice-input-plugin. It contains four files. The folder structure is,

deepseek-harness
├── apps
├── packages
├── voice-input-plugin
│   ├── package.json
│   ├── index.js
│   ├── client.js
│   └── cordis.patch.yml
└── package.json

We can store a plugin anywhere, but i just keep it inside the repository.

In DeepSeek Harness, a plugin is a module with an apply function. Cordis calls this function while loading the plugin and provides the ctx context object.

For our Voice Input plugin, the core part looks like this. Its in client.js

function apply(ctx) {
  ctx.slots.inject('conversation.input.right', () =>
    ctx.slots.register(
      {
        name: 'conversation.input.right',
        id: 'voice-input',
      },
      VoiceInputButton,
    ),
  )
}

module.exports.name = 'voice-input-plugin'
module.exports.inject = ['slots', 'sessions']
module.exports.apply = apply

Here, the plugin uses the conversation.input.right slot to add the microphone button near the prompt field. The VoiceInputButton handles microphone access and converts the voice into text using the browser Speech Recognition API.

The index.js file is only the main plugin entry:

export const name = 'voice-input-plugin'

export function apply() {}

Next, we need to tell DeepSeek Harness to load this plugin. For that, create a cordis.patch.yml file inside the voice-input-plugin folder.

- insert:
    - id: manual-voice-input
      name: dsh-manual-voice-input-plugin

dsh plugin --profile web add /absolute/path/to/voice-input-plugin

And you can see the cordis.patch.yml under web now has the plugin entry.

Now run,

pnpm dsh web

See the voice mode plugin created , using creator mode as well as manual mode.

We can enable or disable any plugin from the Cordis configuration by setting disabled: true or false, like below.

- insert:
    - id: manual-voice-input
      name: dsh-manual-voice-input-plugin
      disabled: true

Conclusion:

That is what I explored about DeepSeek Harness.

Voice Mode plugin creation was interesting. We created it using Creator Mode and also tried the manual way.

There will be many more use cases like this.

Let us try to build more plugins and contribute to the community.

Now, Kimi K3 is getting similar attention.

The model is competing with some of the best models from OpenAI and Anthropic, especially in coding and long-running agentic tasks.

One reason could be its size. Kimi K3 has 2.8T params, so it has a lot of capacity. But the main thing is that it is an MoE model. It doesn’t activate all its parameters for every token. During inference, it uses only a small part of the model.

This is what makes Kimi K3 interesting. It is a bigger model, but it uses sparse activation. It also comes with a 1M token context window.

In this blog, let us see how Kimi K3 is built, how it is different from other MoE models, and how it performs compared to other frontier models.

1. Kimi K3 - Technical Details

2. Kimi K3 - A Large Model with a Small Expert Selection

3. The Three Main Components Behind Kimi K3

4. What the Kimi K3 Benchmarks Show

5. How to Use Kimi K3 in Claude Code and Codex

6. Kimi K3 vs Opus 5 and GPT-5.6: Quality, Speed, and Cost

1. Kimi K3 - Technical Details

Before we get into the architecture, let us first compare Kimi K2 and Kimi K3.

As you can see, Kimi K2 has 1T params, while Kimi K3 has 2.8T params. Moonshot also increased the number of experts and layers. It changed the attention system and extended the context window.

Here is a quick technical overview of Kimi K3.

Kimi K3 supports a 1M token context window. It uses Kimi Delta Attention and Gated MLA layers to handle such a long context. Let us see how these attention layers work in the next section.

Kimi K3 is also a native multimodal model. It can take text, images, and video as input. For visual inputs, it uses MoonViT V2, a vision encoder with 401M params. This encoder converts the visual content into a format that the main model can understand.

Kimi K3 uses MXFP4 for its weights and MXFP8 for its activations. Both are lower-precision formats. So, they help reduce the memory and compute needed during training and inference.

Moonshot started quantization-aware training from the supervised fine-tuning stage itself. So, the model was trained to work with these lower-precision formats.

2. Kimi K3 - A Large Model with a Small Expert Selection

Kimi K3 is an MoE model. So, it doesn’t use all its 2.8T params for every token. It has a large pool of experts, and a router decides which experts need to handle the token.

Kimi K3 has 896 routed experts. The router selects 16 of them for each token. Apart from this, two shared experts are always active.

So, Kimi K3 selects only around 1.8% of its routed expert pool for every token.

Here, the 1.8% can be a little confusing. It is the percentage of routed experts selected. It doesn’t mean that only 1.8% of the model’s total params are active.

In terms of parameters, Kimi K3 activates around 104B out of its total 2.8T params for every token.

The comparison below will make this easier to understand.

Kimi K2 selected 8 out of 384 routed experts, which is around 2.1%. Kimi K3 selects 16 experts from a much bigger pool of 896. So, even though K3 selects more experts, the percentage is lower at around 1.8%.

Since these experts are spread across many GPUs, there are two problems to handle. First, the data needs to move between the GPUs. Second, some experts may get more work than others. Moonshot uses Stable LatentMoE and Quantile Balancing to handle these problems. Let us see how they work in the next section.

3. The Three Main Components Behind Kimi K3

Kimi K3’s architecture has three main components. Let us start with Stable LatentMoE.

1. Stable LatentMoE

As we saw earlier, Kimi K3’s experts are spread across many GPUs. Whenever a token is sent to an expert, the data also needs to move between the GPUs. This adds extra communication cost.

Stable LatentMoE helps to reduce this data movement. It compresses the token data into a smaller size before sending it to the selected experts. After the experts process the data, the result is expanded back to the model’s original size.

There is also one more thing to handle. Some experts may get selected too often, while others may get less work. Kimi K3 uses Quantile Balancing to spread the tokens across its expert pool.

2. Kimi Delta Attention

The second component is Kimi Delta Attention. Kimi K3 supports a 1M token context window. If it used full attention in every layer, it would need a lot of memory and compute.

KDA avoids this by keeping earlier information in a fixed-size memory. When a new token comes in, it updates the memory. The Model decides what to keep and what to forget.

Kimi K3 doesn’t use KDA in every layer. It has 69 KDA layers and 24 Gated MLA layers. KDA handles most of the long context, while the Gated MLA layers use full attention at regular intervals. This allows the model to look across the complete context when needed.

3. Attention Residuals

Kimi Delta Attention handles the context length. Attention Residuals works on a different problem. It handles the model’s depth.

Kimi K3 has 93 layers. Usually, each layer gets the output from the layer before it. When information moves through many layers, some details from the earlier layers may become weak.

Attention Residuals allows each layer to look back at the earlier layer outputs and pick the information it needs. So, it doesn’t depend only on the information passed from one layer to the next.

The diagram below shows how these three components fit into the input-output flow.

In simple terms, Stable LatentMoE reduces the amount of data moved between GPUs. Kimi Delta Attention handles the long context. Attention Residuals helps each layer retrieve useful information from earlier layers.

Moonshot says these changes made Kimi K3 - 2.5 times more efficient at scaling than Kimi K2. This refers to the overall improvement across the architecture and training.

4. What the Kimi K3 Benchmarks Show

When I checked the Arena rankings, Kimi K3 Max was among the top models.

In the WebDev leaderboard, it ranked second. It was just behind Claude Opus 5 Max and ahead of several models from OpenAI, Anthropic, and Alibaba.

In Agent Arena, Kimi K3 Max ranked fifth. This leaderboard looks at how well models complete real-world agentic tasks.

These rankings may change when more models and results are added. But at the time I checked, Kimi K3 was near the top in both web development and agentic tasks.

5. How to Use Kimi K3 in Claude Code and Codex

I am using Kimi K3 through Fireworks. I used Fireconnect to connect it with Claude Code and Codex.

First, we need to install Fireconnect and login.

curl -fsSL https://raw.githubusercontent.com/fw-ai/fireconnect/main/install.sh | bash

fireconnect login

If you want to check all the available models in Fireworks then run,

fireconnect model list

Use Kimi K3 in Claude Code

You can run this command to connect Kimi K3 from fireworks to Claude Code.

fireconnect claude on --model kimi-k3

Now open Claude Code and use /model and check whether Kimi K3 is selected.

Use Kimi K3 in Codex

For Codex, run:

fireconnect codex on --model kimi-k3

Open Codex and check the model selection. You should see Kimi K3 as the active model.

That’s it. Claude Code and Codex work as the coding harness, while Kimi K3 runs through Fireworks.

6. Kimi K3 vs Opus 5 and GPT-5.6: Quality, Speed, and Cost

Now let us see how Kimi K3 performs in a real web development task.

For this test, I gave the same web development prompt to Kimi K3, Claude Opus 5, and GPT-5.6 Sol.

I asked each model to build a web app called Skywatch. We can select a date in the app and see the sky events happening on that day.

The app should have an animated landing page, date navigation, and details about each event. For now, I asked the models to use mock data. Later, it can be replaced with a real API.

Kimi K3

Kimi K3 built the app with HTML, CSS, and JavaScript. It didn’t use any external dependencies.

The UI came out clean and animated. It was also easy to use. Kimi opened the app in the browser and tested the UI visually.

Kimi K3 took 16 minutes and 45 seconds to complete the task. The usage page showed a cost of around $2.49.

Claude Opus 5

I then gave the same prompt to Opus. It built the app with React, TypeScript and Vite. It added more features like an interactive calendar, event filters, and a separate section for moon-phase details. It also added accessibility support and handled different UI states.

I checked the usage and it had used more tokens and cache reads. It worked around 24 mins and the cost was around $13.38.

GPT-5.6 Sol

GPT-5.6 Sol produced the strongest visual design in this test. The cinematic hero section, animation, spacing, and overall visual hierarchy made the app feel more polished.

It also finished the fastest, taking 11 minutes and 42 seconds. The estimated cost was around $3.67.

Here is the complete comparison.

As you see in the table above, Kimi finished the task faster and the cost was very lower when compared to Opus.

Opus built the app in a more detailed and interactive way. I would say it built a complete app. But cost was higher.

Among the three GPT 5.6 Sol was faster and lower cost. And the UI built by GPT-5.6 Sol was really amazing when compared to other two.

Conclusion

Hope you now got a good idea about Kimi K3 and how it works.

Kimi K3 is a big model. But size is not the only interesting part here. Moonshot built a 2.8T model and still kept the inference cost lower.

In my coding test also, Kimi performed well. Almost equal to Opus, but faster and much cheaper.

So yes, Kimi K3 is worth trying.

Happy Building!

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• DevShorts Conversations - The Goal Was Never CI - With Rob Zuber

• How to Run Custom Models in Codex

• GLM 5.2 vs Opus 4.8 in Claude Code

• Claude Certified Architect Foundations: The Complete Guide

• OpenClaw Workflow and Automation

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Meta has released Muse Code and Muse Spark 1.2. Muse Code is a terminal coding agent powered by Muse Spark 1.2. Meta co-trained the model and agent for long coding tasks. Muse Code includes skills for planning, testing, and completing the task. If it crashes, it can resume exactly where it stopped. Check Meta’s post for more details.

• Qwen has released Qwen3.8-Max. It is a 2.4T-parameter MoE model. It supports text, images, video, and a 1M-token context window. Qwen says it can work autonomously on coding projects for more than 10 days. Its open weights will be released next week. Check Qwen’s post for more details.

• Prime Intellect has introduced Prime Agent, a self-improving harness for coding and long-running tasks. It is designed to use tokens efficiently. It supports tool calls and communication between agents. It can also update its harness state while working. Check Prime Intellect’s post for more details.

• Pokee AI has released Pokee-Isaac 28B, an agentic model with a 10M-token context window. Pokee AI says it performed well on benchmarks for tool use, agentic tasks, and security. Check Pokee AI’s post for more details

OSS Highlight of the Week

This week, we are featuring QM. It is an open source agent harness designed for startups. Each employee gets an isolated workspace with their own memory, files, and permissions. Employees can work independently without affecting others. They can also collaborate with the agent in Slack channels and projects. QM supports Pi, OpenCode, Codex, and Claude Code. Check the GitHub repo for setup details.

Share

Good to Know

• Anthropic plans to offer in-country inference for Claude in India, according to ETtech. Claude requests will be processed on servers in India. This will allow the data to stay within the country. ETtech says this will be available in the coming weeks. Check ETtech’s post for more details.

• OpenAI has reduced the API prices for GPT-5.6 Luna and Terra. Luna is now 80% cheaper, while Terra is 20% cheaper. In ChatGPT, Luna is becoming the default for Free and Go users, while Plus and Pro users get the updated Sol. Check OpenAI’s posts for more details.

• Cloudflare has open sourced Cloudflare OS. It was originally built for its own employees to use AI at work. It is not a traditional computer OS. It includes an agent chat interface, sandboxes for building apps, and a security framework for controlling access. Check the GitHub repo for setup details.

• Mistral AI has released Shieldstral 1.0 3B, an open-weight model for content moderation. Developers can describe a safety policy in natural language. The model then checks text and images against that policy. You can change the policy without retraining the model. Check the Mistral’s post for more details.

• Firecrawl has released AnyDoc, an open source Rust library that converts documents into Markdown. It supports Word, PowerPoint, Excel, and text-based PDF files. It also ships as a skill for coding agents. Check the GitHub repo for setup details.

Notable FYIs

• Gemma Translator is an open source voice translator built by Google. It listens to speech, translates it using Gemma 4, and speaks the result in another language. It runs fully offline after setup. It is designed for a Raspberry Pi 5 with 8 GB of RAM. Check the GitHub repo for setup details.

• Thinking Machines Lab has released Inkling-Small, a smaller open-weights version of Inkling. The MoE model has 276B total parameters and 12B active parameters. It supports text, images, audio, and a 1M-token context window. Thinking Machines says it offers similar performance to Inkling with less compute. Check Thinking Machines’s post for more details.

• Black Forest Labs has released FLUX 3 Video. It can create videos from text or images. It generates clips up to 20 seconds with dialogue, sound effects, and ambient sounds. It also supports keyframes and can continue an existing video. Check Black Forest Labs’s post for more details.

• SpaceXAI has released Grok Voice Think Fast 2.0, its latest speech-to-speech voice model. It improves transcription, conversations, and tool use. SpaceXAI says it starts responding in about 0.7 seconds. It is also built to handle background noise and phone audio. Check SpaceXAI’s post for more details.

• Google has released Lyria 3.5, its latest music generation model. It improves melodies, lyrics, vocals, and pronunciation. Users can also control the tempo and duration of generated tracks. It is available in Google Flow Music. Check Google’s post for more details.

• Cloudflare has introduced @cloudflare/computer, an open source runtime for AI agents. It gives filesystem and tools to agents to work with its files. Simple tasks run in a Worker. Complex tasks run in a container. Both environments use the same files, so the agent can switch between them without losing its work. Check Cloudflare’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

Now code can be generated faster, but CI, PR review, testing and approvals are still catching up. This became the central theme of my conversation with Rob Zuber.

Rob has led engineering at CircleCI for more than a decade. In that time, he has helped rebuild the platform through major shifts in software development, including Rails monoliths on Heroku, mobile-first development, Docker, Kubernetes, and now AI agents.

CircleCI is seeing this shift from close range. Teams are generating more code and running more builds, but that does not always mean more software is getting merged into the main branch. Engineering teams are also burning CI cycles discovering broken builds from agent-generated code.

But I did not want this conversation to be only about a report or a product update. I wanted to understand how software engineering itself changes. What happens to CI as a category? What happens to the pull request as an artifact? And what happens to the role of the engineer?

Key points from Rob

Rob joined from San Francisco, and the conversation went in many directions.

A few things he said kept coming back to me after the call.

• Engineering leaders are seeing their hard-earned credibility get “rapidly devalued.” For Rob, staying close to the code is how that credibility stays real. That is why he still contributes to core codebases and was on call the week we spoke.

• CI should move from catching failures first to confirming that the code is ready. By the time code reaches the pipeline, it should be expected to pass.

• Many of our processes exist because we are still afraid to write code. When the cost of writing code changes, the process built around that old cost should change too.

• Sandbox companies are “a dime a dozen,” but just having a new compute layer does not replace the full CI business.

• Directed feedback to agents can reduce token spend by 60 to 80 percent. Sometimes, even stripping junk out of test output makes a big difference.

• Two-person review is just one way we chose to manage risk. It is not the only possible way. We can build better controls for the new workflow.

This is the first in a new Dev Shorts series of conversations with people building developer tools. The transcript below is edited for length and clarity.

1. “I’m on call this week”

Aravind: You run engineering at a company whose customers are engineers. AI is also changing how engineering teams work. How has your own job changed?

Rob:

There are two parts to it.

One part is product. Our customers are very technical, so our product strategy is deeply informed by how our own engineers work.

The other part is leadership. I am leading engineers who are working very differently from how I worked as an IC.

I think a lot of engineering leaders are reaching a point where the expertise and credibility they built over many years is being devalued very quickly. The way I have done this work over the years is changing.

For me, I cannot think about engineering work without doing some engineering work myself. I cannot just say, “I bet it works like this” and be credible. So I have had to sit down and do proper work. Not the kind of work where I build a side project over the weekend and then ask, “Why can’t everyone get this done?”

I mean actually contributing to core codebases within the platform, so I can understand the challenges our customers and our engineers face. I am not putting myself in the blocking path, but I am trying to stay close to the experience.

I’m on call this week, actually.

Aravind: And what has that hands-on time changed about how you see the tools?

Rob:

We went through a transition. Early on, people said these tools were great for prototyping, but we would still do the serious work ourselves. That view matched what the models could do at the time. It also made engineers feel better. But that changed really quickly.

Now the question is different. Production work has more risk than prototype work. It needs more stability, better design, and stronger checks. So yes, I am still going to use generative AI. For production work, I will use it inside a harness that helps keep the quality high.

For low-risk prototypes, I can use it in the most “YOLO, who cares” way. I just want a functioning prototype as fast as possible, and I do not care if it scales. Risk management is the big thing right now. You need to know which activity is low risk and which activity is high risk, and choose how to work accordingly.

Honestly, the models are overqualified for some of this at this point. The bigger conversation everyone is having is how to drive down token cost, because all my engineers are using Fable to write hello-world apps.

We are industrializing. That is the process we always go through. Things start extremely expensive, hard, out of reach, but motivating. Then, if they are valuable enough, we learn how to optimize them. We are in that optimization phase right now.

2. The goal was never CI

Aravind: CircleCI has been the leader in this category for a long time. I do not want to ask what is new in agentic CI, because everyone is already discussing that. I want the strategic view. How is your thinking about the company itself changing, even if it changes every three months?

Rob:

Three months is a lifetime in this space. But strategically, I am a fan of Simon Sinek’s “start with why.” Continuous integration is the category name. We can debate whether using “CI” in the name in 2011 was a great idea or a terrible idea. But the important point is that the goal was never just to build CI. The goal is to help our customers get their software into the hands of their customers as quickly as possible, with high confidence.

We used to think speed and quality were a tradeoff. Then we learned that moving faster, when done right, makes you better. If you tune your process for speed with proper checks, you get quality too. If you tune it for quality with fast feedback, you get speed too.

If that is the goal, CircleCI has already been through many versions of it. We started in 2011 with Rails monoliths deployed on Heroku. The typical customers then were startup teams building from garages around Palo Alto. Then came mobile-first around 2013. Then Docker shipped. Everyone started containerizing. Microservices became popular. Everyone started building on Kubernetes. Then came Rust, Go, TypeScript everywhere, and Next.js. The way people build and ship software has changed many times. We have kept rebuilding the platform to serve the same goal.

Now take that pattern into the AI SDLC, or whatever we end up calling it. The question becomes this. If people are primarily building with agents, how are they going to build with high confidence and ship quickly? A core part of our thesis is that we need to get feedback directly to the agent. The agent needs to know what it is building and whether it is on the right track, because everything else is too late.

What we see today is a lot of branch builds. Teams are using CI to validate their agent-generated code. But more branch builds do not always mean more code reaches the main branch. There is a lot of activity. Maybe not the same amount of productivity.

Aravind: So where does the pipeline itself end up?

Rob:

I think there is still a final gate before things go to production. Otherwise, we will all be in a very dark place. But by the time something gets to CI, you should assume it is going to pass. All of that feedback can be given much earlier. We already know how to validate software. We should just do that in a very different place.

Is that still CI, capital C, capital I, Martin Fowler-approved, the one true way to build software? I doubt it. Everything we have built over the last 25-plus years has evolved around how humans think and work. If that is not who is driving the process anymore, we have to fundamentally rethink it.

3. Software Process Assumes Code Is Expensive

Rob:

Rethinking the software process is hard because we are not good at big leaps. As an industry, and honestly as a society, we usually move in small steps. I believe in process engineering. I believe in the theory of constraints. But if you look at the software engineering process, we have built many assumptions over the years around the cost of creating software.

The time we spend on user research, planning, breaking epics into stories, and breaking stories into tickets all comes from one assumption. Writing software is expensive. We invented Agile around 25 years ago, and the first thing we did after that was create rigid processes and call them Agile. That meant sprint planning on Monday morning, daily stand-ups, and story-point poker. If you do not do those things, people say you are not Agile. That created a way for people to write books, run workshops, and build consulting businesses around “how to do Agile.” But they were not the real spirit of Agile.

Part of the reason we created those processes is that we were still afraid to write code, because writing code was expensive. If that cost changes, and generative AI has changed it, then the process built around the old cost is probably not the right process anymore.

Yes, we are still concerned about tokens, but open-weight models are already good enough for a lot of this work. So the cost of creating software has still shifted. This is not just about PRs becoming a little more expensive, or merging becoming a little more expensive. The real question is different. What process should we design when software is much easier to build?

The Agile Manifesto is four lines. One of them is working software over comprehensive documentation.

We may finally be at a point where I can say, “Build me a thing that does this,” and get something working. It may not be production-ready. It may just be a high-fidelity prototype. But that is enough to start a real conversation about what we are actually building.

That changes how a lot of engineers think about their role. Many of us have been oriented around being the implementer. Someone else figures out the business requirements, and the engineer implements them. But when implementation becomes as easy as typing a couple of sentences, the value shifts. Engineers are moving more and more toward product and strategy. That is what we promised ourselves out of Agile and then fought against by burying it in process.

4. Sandboxes are a primitive, not a business

Aravind: Validation is clearly moving into the inner loop, and that is where the sandbox companies live. I never imagined a Docker container becoming a category, but here we are. MicroVM sandboxes are becoming the new substrate for agent execution. Do sandboxes eat CI?

Rob:

CI has always been a layer of value built on top of commodity infrastructure. You could buy some EC2 VMs and run your own CI on top of them. I can assure you, I have a business. The numbers say we have a business, because people do not want to run CI infrastructure themselves.

Sandboxes are a slightly different primitive. Many of them are Firecracker microVMs running on someone’s infrastructure. But my customers do not care whether I run their workloads in a microVM, an EC2 VM, or a Docker container. What they care about is how much that environment looks like their production environment, and how fast we execute.

New technologies like microVMs can help us run things faster and cheaper, with better margins, at the same or better quality of service. But does a different compute primitive destroy the CI business? I do not think it does.

Where sandboxes are getting most of their value right now is in constraining agents. I have an untrusted entity, and I do not want to approve every action manually. I want an environment where the default is yes, and I know that environment is safe. That is real.

On the other hand, sandbox companies are a dime a dozen. I could name 25 of them right away. Running Firecracker on someone else’s box is not a defensible moat. It is a piece of technology anyone could spin up in an afternoon.

So what we will probably see is a split, with some companies moving beyond basic infrastructure and focusing on specific problems. Fly.io, for example, is offering infrastructure to run production-like environments. I think of them as competing more with Vercel than with CircleCI. Daytona is doing more in agent execution.

Will people try to build CI solutions with sandboxes? Maybe. But they will not become much better or meaningfully different just because they use sandboxes underneath. The value will come from what problem the product solves on top of it.

We use similar technology under Chunk Sidecars. Sidecars are an attempt to solve a specific problem for a specific user, not to provide an infrastructure primitive.

5. The Token Bill Comes Due

Aravind: Here is the pressure I keep hearing about. CI used to stop. There were nightly builds. Now teams ship 500 PRs a week, the pipeline never sleeps, and nobody is sure the checks are even meaningful. What happens to the cost model?

Rob:

CI performance and CI cost are absolutely becoming more important as people build more. There are two parts to it. One option is to run less CI, but that usually means batching changes and slowing down. So the better answer is to run faster CI, and do less compute for each result.

Running faster CI means continuing to invest in wall-clock time and parallelization. Using less compute is the more interesting part. Chunk Sidecars run the smallest possible piece of work next to the agent, so by the time the full CI job runs, it is probably going to pass. Fewer failed builds means teams spend less for each shipped change.

Inside the CI job, Smarter Testing looks at the change and picks the most useful tests to run first. That way, teams can build confidence with smaller pre-checks instead of running the full test suite every time. Then, at the final gate before production, run all the tests and security scans. We believe in the value of spending money on CI. I just want people spending it on the high-value parts.

On tokens specifically, if your costs are climbing but your productivity and delivered value are climbing more, you are fine. You are making more money as a business. If that is not true, that is the thing to fix.

There are also practical ways to reduce token spend. When we give the agent, directed and specific feedback early in the cycle, about whether it is on the right path, we sometimes see a 60 to 80 percent reduction in token spend. The agent is not waiting for a human to say, “No, try again, maybe try this.” It gets to the right outcome faster.

There is also a very tactical piece. When you run tests, you get back a giant pile of output. Whitespace, control characters, and junk all get consumed as tokens. We know what an error message looks like. We know what the agent is actually looking for. We have been reading this output for fifteen years. So we compress the output and send back only the useful part. The agent does not have to burn tokens scanning through noise to find what matters.

6. Convince Me With Your Tests

Aravind: Let us talk about the human role. The contract used to be like, Everything is green, then a peer checks the business logic. In a world where agents write first and merge fast, what is the artifact a human actually verifies? Model companies, agent companies, everyone is arguing for something different.

Rob:

We are very motivated by this question right now, internally and for customers. Start with how I read a PR today. The PR interface gives me a list of changed files in alphabetical order. I go through them in order, and halfway through I realize the change is too big to hold in my head.

So I look for the key changes. I try to understand their context. And then, because I am a human and not a computer, I ask, where is the test that proves this does what the author intended?

That is my mental model of the artifact, even without AI. What gives me confidence, today and in the future, that this change does what the author intended?

So often, there are no tests. Or there is one test proving the most obvious case, while complex logic is not really tested. My review feedback becomes, convince me with your tests that this works the way you expect.

The problem is that we have had a basic understanding of test quality. Code coverage is better than nothing, but it can also be a distraction. It can tell you the wrong things. I have spent days writing bad code just to hit a coverage number.

Test quality is the more interesting pursuit. We have done some work around mutation testing, which is a very old and very simple idea. Take the code and make a small change that should break it. Flip a sign. Then see whether the tests catch it. If I modify the code in a way that should break it and everything still stays green, then I do not have real coverage.

We built something to try this because we happen to have arbitrary fast compute. Take a small codebase, run a mutation analyzer across it, and you get 2,500 mutations. Now you need to run the test suite 2,500 times to find the gaps. That is suddenly feasible.

It is algorithmic and it sits below intent, but it is a start. It gives me a real measure of how good my validation is, so I can actually trust the green checkmark.

Aravind: And beyond the checkmark? PRs are getting bigger, not smaller.

Rob:

Right. We can now do so much work very quickly. But if we try to keep every PR to ten lines, we may end up shipping thousands of PRs a day. That breaks the rest of the system.

So within a larger change, there are logical components. Code is often written chronologically, through many iterations. But the change can be repartitioned into sensible slices. These components feed this function. That function provides this capability. I do not need your false starts in the Git history.

Once you have slices, you can identify which ones are low risk and which ones are high risk. A structural component that follows all our standard patterns, has no security surface, and has no embedded tokens can flow through. Another slice probably needs human review.

If you reject every fifth PR for human review, and that PR is 10,000 lines, the human is back to reading files in alphabetical order. They are hunting for a needle in a haystack that algorithms already found. Just show me the risk.

One part I do not have a great answer to yet is semantic understanding of the change. When we talk about systems, we draw diagrams. But when we talk about changes to systems, the only tool we usually have is reading lines of code. For a five-line change, that is fine. Show me the code. But for a large change, can you show me the difference semantically? Can you help me understand what is evolving, and where the risk is concentrated?

Then you still need the audit trail, because someone in compliance will ask who the second person to sign off was. But here is the thing. The requirement to have two humans read every piece of code does not exist anywhere. It is just the control we chose to reduce risk. Then auditors copied it across organizations. We can build new controls. We just have to build them.

7. Finally doing the original Agile

Aravind: Parting thought. People will keep planning and keep validating, but the day-to-day of writing and reading code is dissolving. If we had to write the manifesto for this era, what does it say?

Rob:

The really interesting thing is that I think we might finally do the original Agile. I have had this conversation a few times recently.

Working software over comprehensive documentation. Functioning code is now cheap enough that it makes sense to build the system and evolve it. We do not have to itemize every requirement upfront before we start.

Some of the original Agile Manifesto authors recently did a 25th-anniversary revisit of the manifesto in Utah. And going back to “start with why,” the intent was there. The intent was good. The intent was right.

I do not know that I would rewrite the intent. But I would certainly question many of the actions we have taken as a result of it.

8. What AI companies get wrong

Aravind: Last one. What is one thing AI companies are doing terribly wrong, on both sides: the foundation labs and the AI-forward builders?

Rob:

I will take the builders first. When we have a new thing, we often think everything has to be new. Software development is fundamentally changing, but we have already solved a lot of problems in software development. Mutation testing is from the 1970s. A lot of useful ideas already exist. But because things look different on the surface, we reinvent them and later realize the problem was already solved. That gets expensive. Absolutely innovate. Absolutely bring those ideas into the current context. But do not assume everything has to be net new.

Interestingly, it goes both ways. In the early 2010s, there was a big wave of reinventing organizational structure in software companies. Most of it eventually got thrown out. Everyone eventually said, Peter Drucker solved this 50 years ago. Let us have normal management. But now the leverage from agents really is forcing us to rethink team shapes. Smaller teams can be more productive, and the communication cost of adding nodes is high. Back then, people were doing it because someone wrote a blog post and it seemed fun. Now the underlying constraint has actually moved.

On the foundation labs, it is easy to make lofty statements, so I will not. But here is what I am genuinely curious about. The major model companies ended up targeting software engineering as the vertical. That is the classic Crossing the Chasm move. Own one vertical completely, then replicate. Developers, or at least their bosses, were willing to pay to optimize an expensive manual process. I understand why Claude Code wins and why Codex wins. They control the fundamental component at the heart of the system. The most important thing a coding agent can do is have a great model interaction.

But now they are pursuing the rest of the SDLC. Cursor has pre-announced that they are building their own version control and moving off GitHub. Obviously, I have a dog in this fight, and so do you. I do not know that they have unique value to bring to those pieces of the puzzle once the model is not the key ingredient. I also question whether it takes attention away from where their value is highest.

If I remember Crossing the Chasm correctly, and I read it 23 years ago, the play is to own the vertical and then replicate into other verticals, like design, legal or whatever. Going deeper into software development instead risks exposing you to someone succeeding closer to your core. Then again, they are making hundreds of billions, so they are doing something right that I am not. And I am totally fine with that.

9. Do human things

Near the end, we talked about what all of this means for people who are just starting out.

Rob has two sons, one in college and one about to be.

Rob: They ask me, what is the future? And I say, I have no idea, man. But do human things. Be graceful. Think deeply about problems. Learn to problem-solve. Be a good human being. Build relationships. That stuff is never going away. I think there is a future where our craving for human interaction gets stronger as our days become more artificial.

Conclusion

The conversation was about how software process changes when code becomes cheaper to write. CI, tests, and human judgment still matter. But feedback has to move earlier, review has to become more focused, and the green checkmark has to mean real confidence, not just that the pipeline finished.

Thanks to Rob Zuber for the conversation, and to the CircleCI team for making it happen.

You can find Rob’s team’s work at circleci.com, including Chunk Sidecars and the State of Software Delivery research we touched on.

This is the first in a series of Dev Shorts conversations with technical leaders shaping how software gets built. If there’s a leader you want me to sit down with next, reply to this email. I read everything.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• How to Run Custom Models in Codex

• GLM 5.2 vs Opus 4.8 in Claude Code

• Claude Certified Architect Foundations: The Complete Guide

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Last week, Hugging Face disclosed a security incident. An AI agent had compromised its infrastructure. OpenAI later found that its models were behind the incident. It happened during an internal cybersecurity test. The models found a way to access the internet from the isolated environment. They then accessed Hugging Face’s systems to get benchmark answers. Check OpenAI’s post for more details.

• Google has released three new Gemini models. Gemini 3.6 Flash is built for coding, knowledge work, and multimodal tasks. It uses fewer output tokens than previous model. Gemini 3.5 Flash-Lite is built for fast, high-volume tasks. Gemini 3.5 Flash Cyber works with CodeMender to find and fix security vulnerabilities. Check Google’s post for more details.

• Qwen has announced Qwen3.8, an upcoming 2.4T-parameter model. Qwen says the model will be released with open weights soon. Qwen3.8-Max-Preview is already available through selected Qwen platforms. Check Qwen’s post for more details.

• Anthropic has added an interesting feature to Claude Cowork. There is a feature named Record a Skill. You can now record your screen while completing a task and explain the steps. Claude turns the recording into a reusable skill. It can use the skill to repeat the task later. Check Claude’s post for more details.

OSS Highlight of the Week

This week, we are featuring Openship. It is an open source, self-hosted platform for deploying apps. You point it to a repository, and it detects the stack, builds the app, and deploys it. You do not need to prepare configuration files, pipelines, or YAML files. It also manages databases, domains, SSL, and backups. Check the GitHub repo for setup details.

Share

Good to Know

• Sakana AI has released Fugu-Ultra v1.1 and Fugu-Cyber. Fugu-Ultra v1.1 is built for coding, agentic tasks, and advanced reasoning. Fugu-Cyber is a multi-agent system that can analyze vulnerabilities and create detection rules. Access to Fugu-Cyber requires approval. Check Sakana AI’s posts for more details.

• NVIDIA has released Cosmos 3 Edge, a 4B-parameter model for robots and vision AI agents. It can understand scenes and generate robot actions on edge devices. Developers can adapt it for their own robot policies. Check NVIDIA’s post for more details.

• Cisco has released Antares-350M and Antares-1B. These open-weight models can find files that may contain vulnerabilities. They run locally, so sensitive code stays within the environment. Check Cisco’s post for more details.

• Poolside has released Laguna S 2.1, an open-weight coding model. It has 118B total parameters, 8B active parameters, and a 1M-token context window. It is built for long coding and agentic tasks. Check Poolside’s post for more details.

Notable FYIs

• XAI has released Grok for Excel, an AI assistant that works inside Excel. You can now complete Excel tasks using simple prompts. It can write formulas, answer questions about selected data, create charts, and rerun scenarios. Check SpaceXAI’s post for more details.

• Andrew Ng has released OpenWorker, an open source AI coworker that runs on your desktop. You can give it a task, and it completes the work for you. You can connect it to models from different providers or run local models with Ollama. Check the GitHub repo for setup details.

• Cursor has launched Cursor Router. It routes each coding request to the right model. Simple tasks go to lower-cost models, while harder tasks go to stronger reasoning models. This helps teams reduce token costs. Check Cursor’s post for more details.

• Unsloth now supports AMD hardware. Developers can train and run more than 500 AI models on AMD GPUs. It works on Windows, WSL, and Linux. Some Qwen and Gemma models can be trained with 3 GB of VRAM. Check Unsloth’s post for more details.

• Qwen has released Qwen-Image 3.0, its latest image generation model. It can create detailed layouts such as newspapers, storyboards, and UI designs. It can generate small readable text and supports 12 languages. Check Qwen’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• How to Run Custom Models in Codex

• GLM 5.2 vs Opus 4.8 in Claude Code

• Claude Certified Architect Foundations: The Complete Guide

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Moonshot AI has released Kimi K3, a 2.8T-parameter model. It is built for coding and agentic tasks. It supports native vision and a 1M-token context window. The full model weights will be released by July 27, 2026. Check Kimi’s post for more details.

• Thinking Machines Lab has released Inkling, a new open-weights model. The MoE Model has 975B total params, 41B active params. It can work with text, images, and audio. It supports 1M-token context window. The weights are on Hugging Face. Check Thinking Machines Lab’s post for more details.

• SpaceXAI has launched Grok 4.5. SpaceXAI says this is its strongest model so far. It was trained alongside Cursor. It is built for coding, agentic tasks, and real engineering tasks. The model is good at creating well-designed, end-to-end apps. Check SpaceXAI’s post for more details.

• PrismML has released Bonsai 27B, a compressed multimodal model based on Qwen3.6. Its 3.9 GB 1-bit version can run on an iPhone 17 Pro, while the 5.9 GB version targets laptops. Both versions support reasoning, vision, and tool calls on local devices. Check PrismML’s post for more details.

OSS Highlight of the Week

This week, we are featuring Clawk. It is an open source tool that gives coding agents a disposable Linux VM. It works with Claude Code, Codex, and shell sessions. The agent gets root access inside the VM. Your keychain and unmounted files stay outside it. Network access is controlled through an allow-list. Check the GitHub repo for setup details.

Share

Good to Know

• Google Antigravity has added Agent Teams as a research preview. The /teamwork-preview command starts a team of specialized subagents. They work together to plan, build, and verify coding tasks in parallel. This feature is limited to Google AI Ultra users. Check Antigravity’s post for more details.

• Parallel has launched Search Turbo, a new fast mode for its web search API. It returns web results that AI models can use directly. This can be useful for applications that need fast web search. Check Parallel’s post for more details.

• Meta has launched Muse Image and Muse Video. Muse Image can edit images and combine elements from multiple references. It can search the web for current information and improve its own output. Muse Video can generate videos with native audio. Check Meta’s post for more details.

• Passmark is an opensource Playwright library. It covers end-to-end browser testing. You can write browser test steps in natural language. It uses AI models to execute those steps through Playwright. Check the GitHub repo for setup details.

• Reve has launched the Reve 2.1 API. It can create and edit native 4K images. It also includes experimental APIs for working with layouts. A layout splits an image into editable regions. Developers can change one region without changing the rest of the image. Check Reve’s post for more details.

• We are covering more resources on harness engineering. Here is another one on harness engineering by Lilian Weng. The guide covers workflow automation, file-based memory, subagents, and self-improving harnesses. Read the full post for more details.

Notable FYIs

• OpenAI has launched GPT-Live, a new voice model for natural conversations. It can listen and speak at the same time. For harder questions, it can send search and reasoning tasks to GPT-5.5 while the conversation continues. The API is planned for a later release. Check OpenAI’s post for more details.

• Cognition has released SWE-1.7, its most capable coding model so far. It is built for long-running software engineering tasks. When the model approaches its context limit, it summarizes its current work and continues from that summary. Check Cognition’s post for more details.

• SpaceXAI has open sourced Grok Build, its coding agent harness and terminal UI. It shows how it assembles context, handles model responses, and runs tool calls. It also includes support for skills, plugins, hooks, MCP servers, and subagents. Check the GitHub repo for more details.

• Meta has released Muse Spark 1.1, a multimodal reasoning model for agentic tasks. It has a 1M-token context window. It can compact older work while keeping important steps. It also supports planning and parallel subagents. Check Meta’s post for more details.

• Mellea is an open source Python library for building structured LLM workflows. It turns Python functions into LLM calls. Docstrings become prompts, and type hints define the output format. It checks the result and retries if the requirements are not met. Check the GitHub repo for setup details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

Nowadays, most coding agents like Claude Code and Codex support custom models. That opens up options. You could choose a model based on cost, privacy, or just wanting to try something new.

In this guide, we will cover:

1. Codex App and CLI

2. Connect Local Models in Codex through Ollama, LM Studio, Unsloth, and llama.cpp

3. Connect Custom Models in Codex through OpenRouter

4. Four points to remember while integrating custom models

1. Codex App and CLI

OpenAI ships Codex as a desktop app and a CLI. Both let you bring your own model. The desktop app gives you a full interface, multi-agent runs, worktrees, and an in-app browser. The CLI runs right in your terminal.

2. Connect Local Models in Codex through Ollama, LM Studio, Unsloth, and llama.cpp

There are a few ways to run a model on your own machine and connect it to Codex.

Ollama is the easiest place to start, so we will begin there.

Codex App with Ollama:

Ollama can connect with the Codex Mac app, as well as the Codex terminal.

1. Install Ollama, then pull a model.

   brew install ollama          # macOS
   curl -fsSL https://ollama.com/install.sh | sh   # Linux
   
   # pull the model
   
   ollama pull qwen3.5:4b

2. Once you’ve pulled the model, start the Codex app with,

   ollama launch codex-app
   
   # If you have more than one model pulled locally, point it at the one you want
   ollama launch codex-app --model qwen3.5:4b

3. This opens the Codex app already pointed at your local model.

   

4. To switch back to your previous codex setup, run,

   ollama launch codex-app --restore

5. Ollama restores your old settings, and saves a backup under ~/.ollama/backup/codex-app/ before it changes anything.

Note: Use a model that supports tool calling, since Codex depends on tool calling for everything it does. For example, gemma3:4b does not support tools at all, and it will fail the moment Codex tries to use one.

Codex CLI with Ollama

1. Ollama connects to the Codex CLI too. Once you have pulled the model, you can launch codex cli with below commands.

   ollama launch codex
   
   # If you have more than one model pulled locally, point it at the one you want
   ollama launch codex --model qwen3.5:4b
   
   # You can also skip the launcher and use the --oss flag directly,
   codex --oss -m qwen3.5:4b
   

   

Profile based setup

You can also do a profile based setup to connect ollama with codex cli.

1. Create ~/.codex/ollama-launch.config.toml.

   model = "gpt-oss:120b"
   model_provider = "ollama-launch"
   model_catalog_json = "/Users/you/.codex/model.json"
   
   [model_providers.ollama-launch]
   name = "Ollama"
   base_url = "http://localhost:11434/v1/"
   wire_api = "responses"

2. Then run this,

   codex --profile ollama-launch

Codex CLI with LM Studio:

LM Studio gives you a simple interface for downloading and running models.

1. Install LM Studio.

2. Once installed, you will be asked to download a model. Choose the one you want.

3. Go to the Developer tab. Before loading the model, check the context length. LM Studio often sets this low by default, sometimes 8192. Increase it to 32k or higher, if your machine can handle it. Codex adds tool definitions and instructions to every message behind the scenes, on top of what you actually type, so a small context window fills up fast.

4. Load the model, and turn the server on. Confirm the status shows as running.

   

5. Before touching Codex, check what actually loaded:

   curl http://localhost:1234/v1/models

   

6. Now connect Codex. It connects a local model with the --oss flag, and use -m to pick a specific model.

   codex --oss -m google/gemma-4-e4b

   

7. If you have more than one local server running at the same time, running codex --oss shows a picker, asking which one to use. Select the one you want, and it connects to that.

   

Profile based setup

1. If you want this LM Studio setup saved as a profile, add this to ~/.codex/config.toml. Name the provider lmstudio_local. If you name it just lmstudio, Codex will reject it, that name is already reserved for its own internal use.

   [model_providers.lmstudio_local]
   name = "LM Studio"
   base_url = "http://localhost:1234/v1"
   wire_api = "responses"

2. Profiles live in their own file. Create ~/.codex/lmstudio.config.toml:

   model_provider = "lmstudio_local"
   model = "google/gemma-4-e4b"
   

3. Launch it with,

   codex --profile lmstudio

   /status

   

Codex CLI with Unsloth

Unsloth is another local option. It has a web interface and some automatic tool-calling fixes built in.

1. Install Unsloth

   curl -fsSL https://unsloth.ai/install.sh | sh

2. This starts Studio on port 8888. Open http://127.0.0.1:8888 in your browser and set a password.

3. Load a model from the dropdown, for example unsloth/gemma-4-26B-A4B-it-GGUF, and test the model is working.

   

4. Once you test the model inference in unsloth studio, you can start the codex,

   unsloth start codex

   

Profile based setup

You can also set profile like below.

1. Add this to ~/.codex/config.toml.

   oss_provider = "unsloth_api"
   
   [model_providers.unsloth_api]
   name = "Unsloth Studio"
   base_url = "http://localhost:8888/v1"
   env_key = "UNSLOTH_STUDIO_AUTH_TOKEN"
   wire_api = "responses"

2. Then create ~/.codex/unsloth_api.config.toml.

   model_provider = "unsloth_api"
   model = "unsloth/gemma-4-26B-A4B-it-GGUF"

3. Grab your API key from Settings→API, inside Unsloth Studio. Set it.

   export UNSLOTH_STUDIO_AUTH_TOKEN=your_key_here

4. Launch Codex with unsloth api,

   codex --oss --profile unsloth_api

Codex CLI with llama.cpp

llama.cpp is another way of connecting Local LLMs to the codex.

1. Install it:

   brew install llama.cpp

   If you want to build it from source instead, check llama.cpp build page.

2. Download a model. hf is the command Hugging Face's tools use now, the older huggingface-cli name was retired.

   pip install -U huggingface_hub hf_transfer
   hf download unsloth/gemma-4-e4b-it-GGUF --include "*Q4_K_M*"

   Some models use chat templates with rules that llama.cpp doesn’t fully support, and the server will reject every message when that happens. Check this before committing to a model, so you don’t spend time debugging something that was never going to work.

3. Find the actual file path once the download finishes.

   ls -lh ~/.cache/huggingface/hub/models--unsloth--gemma-4-e4b-it-GGUF/snapshots/*/

4. Start the server. --jinja matters here, it's what turns on tool calling, and Codex needs that to work at all.

   ./llama-server -m <paste the .gguf path here> -c 32768 --jinja --port 8090

5. Add this to your Codex config.toml

   [model_providers.llama_cpp]
   name = "llama.cpp"
   base_url = "http://localhost:8090/v1"
   wire_api = "responses"

6. Create ~/.codex/llamacpp.config.toml.

   model_provider = "llama_cpp"
   model = "gemma-4-E4B-it-Q4_K_M"

7. Now start the codex

   codex --profile llamacpp

   

3. Connect Custom Models in Codex through OpenRouter

Everything so far runs on your own machine. You can also point Codex to a custom model from different provider.

OpenRouter is one example, an inference provider that gives you access to models like GLM-5.2 through APIs.

1. Add this to ~/.codex/config.toml

   [model_providers.openrouter]
   name = "OpenRouter"
   base_url = "https://openrouter.ai/api/v1"
   env_key = "OPENROUTER_API_KEY"
   wire_api = "responses"

2. Then create ~/.codex/openrouter.config.toml.

   model_provider = "openrouter"
   model = "z-ai/glm-5.2"

3. Set your API key, then run Codex.

   export OPENROUTER_API_KEY="your_key_here"

4. Run Codex with this profile.

   codex --profile openrouter

5. Check with /status, you should see openrouter listed as the model provider.

   

4. Four points to remember while integrating custom models

1. Only wire_api = "responses" works now. Codex removed wire_api = "chat" support in February 2026. If an old tutorial has you set wire_api = "chat", Codex won't start.

2. Three provider names are reserved: openai, ollama, and lmstudio. You can't use these under [model_providers.x], even for your own custom setup. Use something else, like lmstudio_local.

3. Always set your provider and API keys in ~/.codex/config.toml, your personal config file. Never in a .codex/config.toml sitting inside a project folder, Codex won’t use them from there anyway.

4. The model name has to match your server exactly, same spelling, same case. Check it with curl http://localhost:PORT/v1/models, and copy the name from there instead of typing it from memory.

Conclusion

We covered how to connect local models and custom models to Codex.

Now you have the option of running local models in your coding agents. If you have enough system requirements, try different models for different tasks. Open source models hold up well for everyday coding work. Running them yourself means you control the cost, and your code stays right there on your machine.

Try Codex with custom models! Happy building!

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• GLM 5.2 vs Opus 4.8 in Claude Code

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• Claude Certified Architect Foundations: The Complete Guide - Part 2

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Anthropic is restoring access to Claude Fable 5 after export controls were lifted. Fable 5 is now available globally across Claude Platform. Anthropic has also restored Mythos 5 access for some US organizations. Check Anthropic’s post for more details.

• OpenAI has released the GPT 5.6 series. It has three models. Sol as the flagship model, Terra for balanced everyday use, and Luna as the faster and cheaper model. Sol is positioned for harder coding workflows and complex agent tasks. Check OpenAI’s post for more details.

• Anthropic has released Claude Sonnet 5. It is built for longer agentic tasks, coding, and tool based workflows. Anthropic says it brings more Opus style agent behavior into the Sonnet tier at a lower price. Check Anthropic’s post for more details.

• Google has released Nano Banana 2 Lite and Gemini Omni Flash. Nano Banana 2 Lite is for fast and low cost image generation. Gemini Omni Flash is for video generation and editing. Developers can use both models together to turn images into short videos. Check Google’s post for more details.

OSS Highlight of the Week

This week we are featuring Lore, an open source version control system. It is built for large projects that mix code with large files, like games and entertainment projects. Lore supports lightweight workspaces, fast branching, and file downloads only when needed. Check the GitHub repo for more details.

Good to know

• xAI has launched Voice Agent Builder. It is a no code platform for building voice agents on Grok Voice. It is used to build voice agents without setting up the full voice stack from scratch. It also supports telephony, knowledge retrieval, tools, guardrails, MCPs, and observability in one place. Check xAI’s post for more details.

• Anthropic has launched Claude Science. Its an AI workbench for scientists. Claude Science is an app that integrates the tools and packages researchers commonly use. It helps with literature review, data analysis, figures, and manuscripts. Check Anthropic’s post for more details.

• NotebookLM has added Short Video Overviews. It turns uploaded sources into 60 second mobile videos. This gives users another way to understand the material, apart from text and audio overviews. Check NotebookLM’s post for more details.

• Meta has released Brain2Qwerty v2. It turns brain activity into text using non invasive brain recordings. This means the system does not need surgery. Meta is also releasing the training code and the v1 dataset. Check Meta’s post for more details.

Notable FYIs

• XAI has announced Hosted X MCP. It is a Streamable HTTP MCP server that lets MCP clients talk to the X API. Developers can use it with their own X account permissions. Check the X Developer Community post for more details.

• Claude Code has added an experimental advisor tool. When Claude is unsure or gets stuck during a coding task, it can ask a stronger model for help. It can also use the advisor to review its approach before finishing the task. Check Claude Code docs for more details.

• NVIDIA Research has released Nemotron-Labs-TwoTower. It is a diffusion language model built from Nemotron 3 Nano 30B. One part keeps the context, and the other generates tokens in parallel. NVIDIA says this keeps most of the original model quality while making generation faster. Check NVIDIA’s post for more details.

• LongCat has released LongCat 2.0, an open source model. It is built for agentic coding. It supports long context work and coding tasks across larger codebases. LongCat says the model was trained and served on Chinese chips. Check LongCat’s post for more details.

• Google has open sourced Copybara. The tool is used by Google internally. It transforms and moves source code between repositories. This is useful when teams need to keep private and public repositories synced. Check the GitHub repo for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

Simon Willison and Patrick Toulme were also talking about it.

People are already comparing it directly with Opus 4.8 on quality. The interesting part is the price. GLM 5.2 is much cheaper per token, so I wanted to test how close it really gets.

I ran GLM 5.2 and Opus 4.8 inside Claude Code across five real developer tasks. I found some interesting insights in each test. Here is what this post covers.

1. GLM 5.2 and Opus 4.8: An Overview

2. Setting up GLM 5.2 inside Claude Code

3. GLM 5.2 vs Opus 4.8 in Claude Code

   1. Test 1: One-shot UI build

   2. Test 2: Debug a failing test

   3. Test 3: Fixing a performance bottleneck

   4. Test 4: Refactoring codebase

   5. Test 5: A multi-step research task, with sub-agents

4. Key Insights from Tests

1. GLM 5.2 and Opus 4.8: An Overview

Knowing the difference, let’s do the real tests and see how both perform.

2. Setting up GLM 5.2 inside Claude Code

Claude Code is a harness, and any custom model can be set up inside it.

You can use GLM 5.2 from any inference provider. If you are using Z.ai, here is how to set it up in Claude Code. Get an API key from Z.ai's platform. Then edit ~/.claude/settings.json and add this. (Full docs here)

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "your_zai_api_key",
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "API_TIMEOUT_MS": "3000000"
  }
}

This gets GLM running inside Claude Code. But by default it maps to GLM-4.7, not 5.2. To actually run GLM 5.2, with the full 1M context window, add this too.

{
    "env": {
      "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
      "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-5.2[1m]",
      "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]",
      "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]"
    }
}

A few things to note.

• The [1m] suffix enables the full 1M context. Without it, you get the default context window, not 1M.

• GLM 5.2 uses 3x your quota during peak hours, 2x during off-peak.

• Run /status in Claude Code to confirm which model you are on.

This setup is for Z.ai. If you are using a different provider, the config will be different.

If you are using GLM model from Fireworks AI, they have their own way of integrating it, check their documentation. Same goes for OpenRouter, the steps are different, so follow what your provider docs say.

For Fireworks AI - GLM 5.2 integration, run below commands.

curl -fsSL https://raw.githubusercontent.com/fw-ai/fireconnect/main/install.sh | FIREWORKS_API_KEY="fw_xy”z bash

fireconnect claude on --api-key fw_xyz

3. GLM 5.2 vs Opus 4.8 in Claude Code

Now let us get into the tests. I ran both models on the same tasks, same prompt, same codebase.

Test-1: One-shot UI build

The first test is a one-shot UI build. I gave the same prompt to both models to see what they build, without any follow-ups.

Prompt Given:

Build a Northern Lights tracker. Purely frontend, mock data is fine. 

It should show the best viewing locations for tonight, visibility forecast by hour, and a KP index indicator. When visibility is high, the interface should feel like it.

The design is the real test here. Auroras are one of the most visually stunning things on the planet. The UI should reflect that. Animations, atmospheric gradients, a dark sky feel. Not a weather app with a green badge. Something that actually makes you want to look up.

Use whatever stack and libraries make sense. Install what you need.

Build it end to end and verify it runs in the browser before stopping. No clarifying questions.

Both built something impressive in one shot.

What GLM 5.2 Built

GLM built the visually stronger UI. Full-screen aurora waves, bold hero text, rich location cards. It feels alive as you scroll.

The only thing it needs is a small fix on the hero animation speed. The waves move too fast and the text gets buried. One prompt, and it is right there with Opus.

What Opus 4.8 Built

Opus built a clean, functional dashboard. Structured layout, clear hierarchy, each section separated and easy to scan. Complete UI, up and running in one shot.

What I noticed:

• Both delivered impressive UIs in one shot.

• Opus was clean and complete with no issues out of the box.

• GLM was visually stronger but needed one small fix on the animation speed.

• One thing worth noting. GLM does not support image input, so it could not verify the UI in the browser the way Opus did. Opus used the browser tool to check its own output. GLM had to skip that step.

  

• On the numbers, GLM used more tokens and took a bit longer than Opus. But the token cost is lower, so the final bill was still significantly cheaper. Almost equal quality to Opus, at a fraction of the price.

Now, here is the remaining details

Test 2: Debug a failing Test

npm test was failing. That was the whole prompt. No hints, no file names, no description of what is wrong.

Prompt Given:

npm test is failing. fix it

The real question here is whether the model can identify the root cause correctly. One failure was a real bug in the implementation. The other was a wrong assertion in the test. Each needed a different kind of fix.

What Opus 4.8 did

Opus went straight to it. Ran the tests, read the files, fixed both issues correctly. Knew exactly where to look and what to change. Clean and done.

What GLM 5.2 did

GLM took a more thorough approach. It read more context before acting and ran a shell command to verify the fix before wrapping up. Same correct fixes as Opus, but more steps and time to get there.

What I noticed:

• Opus got there faster and with fewer tokens, clean and direct.

• GLM found failing tests and fixed them correctly, same as Opus. Same diagnosis, same fixes.

• GLM read significantly more context, 35.5k input tokens vs Opus 6.5k. It took a more thorough path before committing the fix.

Test 3: Fixing performance bottleneck

I gave both models a user complaint and a file path.

Prompt Given:

Users are reporting that the issues list loads slowly when a project has a lot of data. 

The backend entry point is src/services/issueService.ts. 
Find the bottleneck and fix it.

The actual issue was a query doing redundant work for every row it processed, with no indexes to speed it up. Fine on small data, but slow on large ones. Exactly what users were reporting.

Both models proposed the same two-layer fix. Rewrite the query, add indexes.

The difference was execution.

What GLM 5.2 did

GLM diagnosed it correctly and went deep into benchmarking. It even caught that its own rewrite was slower than expected and re-evaluated. But the investigation loops kept going, so I stepped in and asked it to wrap up. It gave the right fix, but burnt more tokens and time.

Here is where it caught its own mistake.

What Opus 4.8 did

Opus read the files, wrote the fix, verified it, and wrapped up in 5 minutes. Clean, done.

What I noticed:

• Both models proposed the same fix. Rewrite the query and add indexes. Same diagnosis, same solution.

• GLM went deeper than needed. It caught that its own rewrite was slower than expected and kept re-evaluating. Good reasoning, but the investigation loops ran too long. I had to step in and ask it to wrap up. Finally it gave the right answer.

• Opus read the files, wrote the fix, verified it with the sqlite3 CLI, and wrapped up in under 5 minutes.

• GLM burned significantly more tokens to reach the same conclusion.

Test 4: Refactoring Codebase

This test is about giving both models a messy file and seeing how they clean it up, without telling them what is wrong.

Prompt given:

file issueService.ts is getting messy. Clean it up.

Both models read the file, identified the same problems and refactored the same way.

The difference was execution speed.

What Opus 4.8 did

Opus read the file, made the changes, ran the compiler to verify, and wrapped up in 3 minutes 32 seconds. Clean and done.

What GLM 5.2 did

GLM also cleaned in the same way. But it took more steps and time to get there.

What I noticed

• GLM 5.2 reasoning is as high as Opus 4.8. Just like every other test, it consumed more token and time.

• Opus flagged two edge cases it changed that were not part of the original request and asked if you want to keep them. That kind of communication is useful in a real codebase.

Test 5: A multi-step research task, with sub-agents

Both models performed really well on this research task.

Prompt given:

Research the latest agentic frameworks that support multi-agent orchestration.

Find:
- Which ones are actively maintained
- What the developer community thinks of each one
- How they compare on ease of use, flexibility, and production readiness

Give me a comparison table and a recommendation on which one to start with.

What Opus 4.8 did

Opus ran 46 web searches, used sub-agents, and came back with a structured comparison table, community sentiment per framework, version numbers, enterprise users, and a clear recommendation with reasoning.

What GLM 5.2 did

GLM went deeper than Opus. It used more iterations, more tool calls, more web searches, and spawned more sub agents. It consumed significantly more tokens,

But the final result was at Opus level.

What I noticed

• Both reached the same findings, same reasoning, same recommendation.

• Opus stayed focused and got there efficiently. GLM went wider but arrived at the same place.

• The cost difference comes down to how each model works, not the quality of the output.

• For deep research tasks, GLM’s cheaper token cost is an advantage. It can afford to go wider without the bill getting out of hand.

4. Key Insights from Tests

GLM 5.2 is genuinely good. The reasoning is there. The quality is there. In most tests it reached the same answer as Opus. It is really great to see an open weight model performing at this level, matching Opus on quality.

But it consumes more token, and takes more time for many tasks. It goes wider and deeper than needed. In Test 3, it went so deep into benchmarking its own fix that it took longer than expected.

Opus, just like always more focused. It builds efficiently and moves on.

Across five tests, here is how they compare overall.

These results are based on my own tests, not any official claims or vendor comparisons. Your results may vary depending on the task and provider.

One thing worth noting. Every test here was run on high effort. At that level, GLM matched Opus consistently. Whether it holds up the same way on medium effort is still untested.

GLM 5.2 is closer to Opus 4.8 than most people think. And significantly cheaper.

I hope this blog gives you a clear picture of where GLM 5.2 stands and whether it is worth adding to your workflow. If you are already on a Claude subscription, setting up GLM alongside it takes five minutes. Start with one task and see how it feels.

Happy building.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• Claude Certified Architect Foundations: The Complete Guide - Part 2

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Z.AI has released GLM 5.2, its new open weight coding model. It is built for long coding tasks and supports 1M context. It has two thinking effort levels, High and Max. For coding, Z.AI recommends Max for better reasoning. Check Z.AI’s post for more details.

• Moonshot AI has released Kimi K2.7 Code. It improves coding and agent performance compared to K2.6. It also uses fewer reasoning tokens, which means less overthinking during coding tasks. The model is available through Kimi API and Kimi Code. Check Kimi’s post for more details.

• SpaceX has decided to acquire Cursor. The goal is to build more useful AI models. A new model is already being trained, and SpaceX says it will be available in Cursor and Grok Build soon. Check SpaceX’s post for more details.

• Cartesia has launched Sonic 3.5 and Ink 2 for voice AI. Sonic 3.5 is for text to speech, and Ink 2 is for speech to text. Both are built for real time voice agent use cases. Sonic 3.5 also supports more than 40 languages. Check Cartesia’s launch post for more details.

OSS Highlight of the Week

This week we are featuring Eve, Vercel’s framework for building AI agents. Eve lets developers build agents using normal project files and folders. The agent’s instructions, tools, skills, and schedules are kept in standard folders, so it is easier to understand and update the agent. Check the Vercel Eve page for more details.

Share

Good to know

• Anthropic is suspending access to Fable 5 and Mythos 5 after a US government directive. The directive blocks access for foreign nationals, and Anthropic says it is removing access for all users to comply. Other Anthropic models are not affected. Check Anthropic’s post for more details.

• Midjourney has launched Midjourney Medical. This is not about image generation. They are working on Ultrasonic CT, a full body ultrasound scan using sound and water. Midjourney says the scan can take as little as 60 seconds. The first location is planned in San Francisco by the end of 2027. Check Midjourney Medical’s page for more details.

• Many AI products and features get launched, changed, deprecated, or shut down over time. Killed by OpenAI is a site that tracks OpenAI products, features, and APIs that were shut down, deprecated, or inactive. It also shows the status and shutdown date for each item. Check the site if you want to track OpenAI product changes.

• OpenAI has added Library for files in ChatGPT. Files you upload or create in ChatGPT are saved in Library, so you can find and reuse them later. Library storage is separate from daily chat attachment limits. Check OpenAI’s help page for more details.

Notable FYIs

• Zed has opened early access for DeltaDB, a version control system built for agentic coding. It records every small code change between commits, so developers can rewind to any point. It also links each code change with the agent conversation that created it. Check Zed’s DeltaDB page for more details.

• OpenRouter has introduced Fusion, a tool to combine outputs from multiple models. It sends the prompt to a group of models and then uses another model to merge the useful responses. OpenRouter says this works better for deep research tasks than calling one model alone. Check OpenRouter’s post for more details.

• Cursor has introduced Origin, a new code hosting and collaboration platform. It is built for teams using AI agents to code faster. The waitlist is open now. Check Cursor Origin for more details.

• Exa has launched Exa Agent, an API for web research. It can search the web deeply and collect detailed information for a given task. For large tasks, it splits the work into smaller parts and runs subagents in parallel. Check Exa’s post for more details.

• Kage is a tool for saving websites as offline copies. It renders the site and saves the final page with CSS, images, and fonts. It removes JavaScript, so the saved site can be opened later without scripts or network calls. Check the GitHub repo for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• Claude Certified Architect Foundations: The Complete Guide - Part 2

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Anthropic has released Claude Fable 5 and Mythos 5. Fable 5 brings the Mythos model family to general users, but with stricter safeguards. For safety, some sensitive requests are routed to Claude Opus 4.8 instead. Mythos 5 is for trusted users who need more flexibility in areas like cybersecurity. Check Anthropic’s post for more details.

• Google has released Gemini 3.5 Live Translate. It is a new audio model for live speech to speech translation. It can detect more than 70 languages and translate speech while keeping the speaker’s tone, pace, and pitch. Check Google’s post for more details.

• Kimi has launched Kimi Work, a local desktop AI agent for everyday work. It can connect to your local files and use the browser for tasks. It can also run scheduled tasks and coordinate multiple agents for larger work. Check Kimi’s page for more details.

• Google has released DiffusionGemma. It is an experimental open model built for faster text generation. It uses diffusion method, which creates blocks of content at once instead of going token by token. Google says it can run up to 4x faster on dedicated GPUs. Check Google’s post for more details.

OSS Highlight of the Week

This week we are featuring Herdr. It is a terminal based agent multiplexer for running multiple coding agents. You can organize agents in workspaces, tabs, and panes. It also shows whether agents are blocked, working, or done. It supports detach and reattach, so agents can keep running in the background. Check the GitHub repo for more details.

Share

Good to know

• Anthropic has changed how Claude Code billing works after June 15. If you are not sure whether to use Pro, Max, API credits, or Codex, this pricing breakdown is useful. It explains what is still covered by your Claude plan and what now needs separate credits. Check FindSkill’s post for more details.

• ChatGPT can now generate charts directly inside the chat. You can ask it to turn data or comparisons into simple visuals. The feature is available now on mobile and web. Check ChatGPT’s post for more details.

• If you are trying to learn Agent Harness, this course is a good starting point. It explains why AI coding agents fail and how harnesses make them more reliable. It covers rules, state management, testing, observability, and clean handoffs. Check the Harness Engineering course for more details.

• Loop Engineering is becoming popular for AI coding agents. Instead of prompting agents step by step, the idea is to design loops that guide the work for them. These loops can use automations, worktrees, skills, connectors, subagents, and memory. Check Addy’s post for more details.

Notable FYIs

• Xiaomi has released MiMoCode, an open source AI coding agent for the terminal. It can read and write code, run commands, manage Git, and keep project memory across sessions. It also supports multiple agents, subagents, MCP, and custom model providers. Check the GitHub repo for more details.

• Cohere has released North Mini Code. It is Cohere’s first model built for developers. The open source MoE coding model has 30B total parameters, with 3B active. It is built for agentic software engineering. Check Cohere’s post for more details.

• We all use AI tools and know they can consume a lot of tokens. Headroom is a context compression layer for AI agents. It compresses tool outputs, logs, files, and RAG chunks before they reach the LLM. The repo says it can reduce tokens by 60 to 95 percent. Check the GitHub repo for more details.

• Cognition has introduced FrontierCode, a new benchmark for coding agents. It checks whether AI generated code is good enough to merge into real production codebases. The benchmark looks beyond correctness and checks tests, scope, style, maintainability, and code quality. Check Cognition’s post for more details.

• Apple has introduced Core AI for developers. It lets developers run AI models on Apple silicon. It also includes tools for model preparation, debugging, and inference performance. Check Apple’s documentation for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• Claude Certified Architect Foundations: The Complete Guide - Part 2

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

Join 8900+ developers to hear stories from Open source and technology.

Must Read

• Microsoft AI has launched seven models. The new family covers reasoning, code, image, transcription, and voice. Among them, MAI Thinking 1 is a reasoning model trained from scratch for STEM reasoning and coding tasks. Check Microsoft’s post for more details.

• Hermes Agent now has a native desktop app. It brings Hermes Agent to a simple desktop app, without needing the terminal. Users still get the same agent, memory, and skills. Check the Hermes Desktop page for download details.

• Google has released Gemma 4 12B. It is an open weight model built for agentic workflows. It supports text, vision, and native audio inputs. It is laptop ready and can run locally with 16GB memory. Check Google’s post for more details.

• NVIDIA has released Nemotron 3 Ultra. It is their most capable Nemotron model so far. It supports up to 1M context and gives better control over reasoning during inference. NVIDIA is also releasing the model checkpoints, training datasets, and recipes. Check NVIDIA’s post for more details.

OSS Highlight of the Week

This week we are featuring Cate. It is an infinite zoomable canvas for coding. You can keep your editor, terminal, browser, docs, and AI agents in one workspace. It helps you work on a project without switching between too many windows. Check the GitHub repo for more details.

Good to know

• OpenAI is taking Codex beyond coding. Sites are a new canvas where Codex can turn ideas into dashboards. They also shipped plugins for areas like sales, product design, analytics, and finance. Each plugin brings the needed apps, skills, instructions, and workflows together. Check OpenAI’s Codex post for more details.

• Anthropic released Claude Opus 4.8 last week. Whenever an Opus model gets released, expectations are usually high. Opus 4.8 brings better coding performance, effort control, cheaper Fast mode, and parallel subagents in Claude Code. Check Anthropic’s announcement for more details.

• Meta has introduced Meta Business Agent. It helps businesses handle customer conversations on WhatsApp, Messenger, and Instagram. It can answer questions, suggest products, and book appointments. It uses AI to give more personalized support to customers. Check Meta’s post for more details.

• Cloudflare cofounder Matthew Prince says bot traffic has now crossed human traffic on the internet. He says this happened faster than he expected because agentic traffic is growing quickly. This shows how AI agents are starting to change web traffic. Check the post for more details.

• xAI has rolled out Grok Imagine 1.5 Preview. It is the latest image and video generation model from xAI. It supports up to 2K image output, 10 images per request, and videos up to 15 seconds. Check xAI’s Imagine API page for more details.

Notable FYIs

• Anthropic released dynamic workflows in Claude Code. Claude can now write its own harness on the fly for complex tasks. Since dynamic workflows may use more tokens, it is better to use them only when needed. Check Anthropic’s blog for example prompts and more details.

• Qwen has released Qwen3.7 Plus. It is their latest multimodal agentic model. It is built for agentic tasks like screen understanding, GUI tasks, and browser workflows. It can also navigate mobile apps and complete tasks. Check Qwen’s post for more details.

• MiniMax has released MiniMax M3. It is an open weight model built for coding and agentic tasks. It supports image and video input, computer use, and 1M context. MiniMax says it is the first open weight model to bring all these together. Check MiniMax’s M3 post for more details.

• NVIDIA has released the open weight Cosmos3 model. It is a collection of world models built for Physical AI. It can be used for robotics, autonomous vehicles, and smart spaces. Check the Hugging Face model card for more details.

• Hugging Face has open sourced Trackio. It is a simple alternative to Weights and Biases. You can run it locally and track your experiments without setting up a hosted tool. Check the GitHub repo for more details.

• OpenAI models, Codex, and Managed Agents are now available on AWS. AWS customers can use OpenAI models through Amazon Bedrock. This makes it easier for enterprises to use OpenAI inside their existing AWS setup. Check OpenAI’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

This part covers the remaining domains and how to register for the exam. Here is what we will cover.

1. Prompt Engineering & Structured Output

2. Context Management & Reliability

3. How to register for the exam

I have also added more practice questions to the CCAF GitHub repo. Six sets now, covering all domains.

1. Prompt Engineering & Structured Output

• Explicit Criteria

• Few-shot Prompting

• Structured Output

• Validation-Retry Loops

• Multi-pass Review

• Schema Design

Explicit Criteria

We have to give exact instructions to Claude instead of vague conditions. This is called explicit criteria. Telling Claude like “be careful” or “report high security issues” does not work. Claude does not know what that means in practice.

Tell Claude exactly what to do and what not to do. When you are more specific, Claude makes fewer mistakes.

# Bad — vague, 
system_prompt = """
Review this code and flag any security issues.
Only report high confidence findings.
"""

# Good — categorical, Claude knows exactly what to flag
system_prompt = """
Review this code for security issues.
Flag a finding ONLY when:
- User input is passed directly to a SQL query without parameterization
- A secret or API key is hardcoded as a string literal
- User-supplied data is rendered in HTML without escaping

Do not flag theoretical risks or best practice suggestions.
"""

Few-shot Prompting

Give Claude examples before asking it to do the task. This is called few-shot prompting. Two to four examples is enough. More than that wastes tokens.

One thing to keep in mind. Few-shot prompting is probabilistic. Claude will follow the examples most of the time but not always. If you want something to run without fail, put it in a hook.

system_prompt = """
Extract the customer name and order ID from the message below.

Example 1:
Message: "Hi, I am John and my order 1234 has not arrived."
Output: {"name": "John", "order_id": "1234"}

Example 2:
Message: "This is Sarah. Order #5678 is damaged."
Output: {"name": "Sarah", "order_id": "5678"}

Now extract from this message:
"""

Structured Output

If you ask Claude to “output as JSON” in the prompt, it will try. But it is not guaranteed. The reliable way is to use structured outputs.

Method 1 — JSON outputs

• Define the schema in output_config of the client.messages.create() call.

• Claude returns the answer as JSON text in response.content[0].text.

• Parse it with json.loads() to get the data.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Extract order details from: John's order 1234 is missing"}],
    output_config={ # tells Claude to return structured JSON
        "format": {
            "type": "json_schema",
            "schema": {
                "type": "object",
                "properties": {
                    "customer_name": {"type": "string"},
                    "order_id": {"type": "string"},
                    "issue": {"type": "string"}
                },
                "required": ["customer_name", "order_id", "issue"]
            }
        }
    }
)
# Claude returns guaranteed JSON in content[0].text
result = json.loads(response.content[0].text)
# {"customer_name": "John", "order_id": "1234", "issue": "missing"}

Method 2 — Strict tool use

This method is used to pass structured input to your tools with guaranteed schema compliance.

When Claude calls a tool in an agentic workflow, it passes parameters to that tool. Without strict mode, those parameters may not match your schema exactly. With strict: True on the tool definition, Claude is forced to pass parameters that exactly match your input_schema. The structured data Claude fills in is available in block.input on the tool call response.

tools = [{
    "name": "extract_order",
    "description": "Extract order details",
    "strict": True,          # Claude must fill in all fields exactly as defined
    "input_schema": {
        "type": "object",
        "properties": {
            "customer_name": {"type": "string"},
            "order_id": {"type": "string"},
            "issue": {"type": "string"}
        },
        "required": ["customer_name", "order_id", "issue"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    tool_choice={"type": "tool", "name": "extract_order"},  # force Claude to call this tool
    messages=[{"role": "user", "content": "John's order 1234 is missing"}]
)

for block in response.content:
    if block.type == "tool_use":
        print(block.input)   # structured data Claude filled in
        # {"customer_name": "John", "order_id": "1234", "issue": "missing"}

Validation-Retry Loops

Structured output guarantees the structure. It does not guarantee the values are correct. This is where the validation-retry loop comes in. When Claude returns wrong values, you send the error back with specific details about what went wrong. Claude fixes it and tries again.

MAX_RETRIES = 3
for attempt in range(MAX_RETRIES):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        tools=tools,
        tool_choice={"type": "tool", "name": "extract_order"},
        messages=messages
    )

    for block in response.content:
        if block.type == "tool_use":
            result = block.input

            # Validate the result
            if not result.get("order_id").startswith("ORD-"):
                # Send specific error back — not a generic "try again"
                messages.append({"role": "assistant", "content": response.content})
                messages.append({"role": "user", "content": [{
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": "order_id must start with ORD-. You returned: " + result["order_id"]
                }]})
                break  # go to next attempt

            return result  # valid — done

raise RuntimeError("Failed to get valid output after max retries")

Always send specific error details. Tell Claude which field failed and what you expected. A generic "try again" does not give Claude enough context to fix the issue.

Retry loops fix format errors. But if the data is simply not there in the source, retrying will not help. Claude cannot return something that does not exist.

Multi-pass Review

When Claude generates something and then reviews it in the same session, it already knows how it was built. It will miss its own mistakes. That is the problem with self-review.

Multi-pass review fixes this. You use a separate Claude session to review the output. The reviewer session has no memory of how the output was generated. It looks at the result with fresh eyes.

# Pass 1 — generate the code
generation_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    messages=[{"role": "user", "content": "Write a FastAPI endpoint for processing refunds"}]
)
generated_code = generation_response.content[0].text

# Pass 2 — review in a separate session
review_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": f"Review this code for security vulnerabilities:\n\n{generated_code}"}]
)

Never use the same session for generation and review. Always use a separate session.

Schema Design

When you define a JSON schema for structured output, each field tells Claude what to extract and in what format. One of those fields can be an enum. It is a fixed list of allowed values. For example, if you have an issue field you can restrict it to "missing", "damaged", or "wrong_item", you define it as an enum. Claude can only pick from that list.

Three things to know in Schema Design:

Enums - always add "other" to the list. If Claude sees something that does not fit any of the defined values, it will pick the closest one instead of telling you it does not know. With "other" in the list, Claude has a safe option to fall back to.

Nullable fields — if a field may not always be present, use ["string", "null"] instead of "string". Never mark optional fields as required. Claude will make up a value just to fill it.

Flat structures — avoid deeply nested objects in your schema. Deep nesting makes it harder for Claude to fill the schema accurately. Keep your schema flat. If the data is complex, split it across multiple tool calls.

tools = [{
    "name": "extract_order",
    "description": """Extract order details. Issue must be one of: missing, damaged, wrong_item, other.
    Use other when the issue does not fit the above categories.""",
    "strict": True,  # Claude must follow the schema exactly
    "input_schema": {
        "type": "object",
        "additionalProperties": False,  # no extra fields allowed
        "properties": {
            "customer_name": {"type": "string"},
            "order_id": {"type": "string"},
            # issue must be a string 
            # issue can only be one of these four values — always include "other" in enum.
            "issue": {
                "type": "string",
                "enum": ["missing", "damaged", "wrong_item", "other"]
            },
            # fill this when issue is "other" — gives Claude somewhere to put unexpected values
            "issue_detail": {"type": "string"},
            # nullable — Claude returns null when delivery date is not mentioned in the source
            "delivery_date": {"type": ["string", "null"]}
        },
        # only these fields are required — issue_detail and delivery_date are optional
        "required": ["customer_name", "order_id", "issue"]
    }
}]

2. Context Management & Reliability

This domain carries 15% of your exam score. It is the smallest domain. But it matters. If you do not manage context well, your agents become unreliable in production.

Below are the key concepts.

• Lost-in-the-Middle Effect

• Progressive Summarization

• Tool Result Trimming

• Escalation and Ambiguity

• Error Propagation

• Prompt Caching

• Message Batches API

Lost-in-the-Middle Effect

Claude can process up to 1 million tokens in a single request. But more context does not always mean better results.

When you pass a long input, Claude processes the beginning and end reliably. What is in the middle often gets missed. This is called the lost-in-the-middle effect.

Two things to know

• Place critical information at the beginning or end. Never place it in the middle.

• For large context tasks, delegate to subagents. Each subagent starts fresh with only what it needs.

Progressive Summarization

As an agent runs through multiple turns, the conversation history keeps growing. At some point it gets too large to pass in full on every API call.

Progressive summarization solves this. Instead of passing everything, you summarize the older turns and keep only the recent ones in full. The summary replaces the old turns in the messages array.

# When history gets too long, summarize older turns
summary_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{
        "role": "user",
        "content": f"Summarize this conversation history into key facts only:\n\n{old_turns}"
    }]
)

summary = summary_response.content[0].text

# Replace old turns with the summary
messages = [
    {"role": "user", "content": f"Previous context: {summary}"},
    *recent_turns  # keep the last few turns in full
]

When we summarize, we may lose details. Dates, percentages, and numeric values often become vague. If you want anything to stay precise, extract it into a structured state object before summarizing.

Tool Result Trimming

Every tool call adds output to the context. If a tool returns 40 fields but you only need 5, the remaining 35 are wasting tokens. Over multiple turns this adds up fast and fills your context with noise.

Trim tool results before appending them to the next API messages array. Always keep your context clean. Pass only what Claude needs. Learn more about managing tool context here.

# Bad — full tool result, 40+ fields appended to messages
result = get_customer(customer_id="C-42")
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": block.id,
        "content": json.dumps(result)
    }]
})

# Good — trim before appending, only what Claude needs
result = get_customer(customer_id="C-42")
trimmed = {
    "id": result["id"],
    "name": result["name"],
    "status": result["status"]
}
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": block.id,
        "content": json.dumps(trimmed)
    }]
})

Escalation and Ambiguity

Not every task should be handled autonomously. Knowing when to escalate to a human is just as important as knowing how to complete a task.

Three valid reasons to escalate:

• When the user explicitly requests a human, escalate immediately. Do not attempt to investigate first.

• When the agent does not have clear instructions for the situation, escalate. Do not guess.

• When the agent cannot make meaningful progress, escalate.

When a tool returns multiple matching results, ask the user for more details to narrow it down. Never pick one based on a guess.

# Tool returns escalation signal
@mcp.tool()
def process_refund(order_id: str, amount: float) -> dict:
    if amount > 500:
        return {"requires_human": True, "reason": "Refund above $500 needs approval"}
    return {"success": True, "refund_id": "REF-001"}

# Agent loop checks for it
result = tool_map[block.name](**block.input)

if result.get("requires_human"):
    escalate_to_human(result)
    return

Two common mistakes to avoid.

Do not escalate just because the user seems frustrated. Frustration does not mean the task needs human intervention. Acknowledge it, try to resolve it, and only escalate if the user explicitly asks for a human.

Do not use the agent’s own confidence score as an escalation signal. Models tend to be overconfident even when they are wrong. It is not reliable.

Error Propagation

In a multi-agent system, when a subagent fails, the coordinator needs to know what went wrong. If the subagent returns a generic error, the coordinator cannot decide what to do next.

Subagents should always return structured error context. Not a generic failure status.

# Bad — coordinator has no idea what went wrong
return {"error": True}

# Good — coordinator knows what failed and what to do next
return {
    "error": True,
    "type": "tool_failure",
    "tool": "lookup_order",
    "reason": "Order not found in database",
    "retryable": False
}

Never suppress errors silently. If a subagent fails without sending a signal, the coordinator assumes success and moves on. That produces wrong results in the next steps.

Not all errors are the same. A timeout can be retried. A missing record cannot be retried. Tell the coordinator what went wrong so it can decide what to do.

Also remember, subagents do not share context automatically. If one fails, the coordinator has to pass that information forward explicitly.

Prompt Caching

Every time you call the Claude API, you send the full context. You send system prompt, conversation history, tool definitions. Claude processes all of it from scratch on every single call. That adds up fast. It becomes more tokens with higher cost.

With prompt caching we can reduce the cost. You mark the static parts of your prompt with cache_control. Claude caches them on the first call. Instead of paying full price on every call, you pay only 10% for the tokens that are already cached.

There are two ways to enable it.

Automatic caching - You just add cache_control at the top level of your request. Claude scans your prompt from top to bottom and places the cache breakpoint at the end of the last block that can be cached, which is typically the end of your system prompt or tool definitions.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},  # automatic — Claude picks the breakpoint
    system="You are a customer support agent.................  ",
    messages=[{"role": "user", "content": user_query}]
)

Explicit caching - you mark specific content blocks with cache_control directly inside the system array. Claude caches everything before and up to that block. Use this when you want to control exactly where the cache ends.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You are a customer support agent."},
        {
            "type": "text",
            "text": large_document,
            "cache_control": {"type": "ephemeral"}  # cache everything up to here
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

Always cache static content only. You can put system prompts, tool definitions, and large documents in cache. Never put dynamic content in cache.

Every API call checks whether the cached prefix matches exactly. Even a single character difference causes a cache miss and Claude reprocesses everything from scratch.

TTL and pricing

TTL stands for Time to Live. It is how long the cache stays active. By default the cache expires after 5 minutes. Every cache hit resets the timer. If your requests come in less frequently, you can extend the TTL to 1 hour at 2x the cache write price.

• The first call writes to cache and costs 1.25x normal input tokens.

• Cache read costs 0.1x normal input tokens.

• You can place a maximum of 4 cache_control breakpoints in a single request.

• If you use the Batch API and prompt caching together, both discounts apply.

• The first call costs more because it writes to cache. From the 4th read onwards you start saving money.

To check if caching is working, look at the response usage.

print(response.usage.cache_read_input_tokens)     # tokens read from cache
print(response.usage.cache_creation_input_tokens)  # tokens written to cache

If cache_read_input_tokens is greater than 0, the cache was hit.

Message Batches API

When you need to process a large number of API requests without needing an immediate response, use the Message Batches API. For example, processing thousands of customer feedback forms overnight, or doing bulk content generation.

You can submit up to 100,000 requests in one batch. Claude processes them asynchronously. Most batches finish within 1 hour, but they can run up to 24 hours. If they do not complete within 24 hours, they expire.

The cost is 50% off standard API pricing. The output quality is the same. Only the timing is different.

import anthropic
import time

client = anthropic.Anthropic()

# Create a batch with multiple independent requests
batch = client.messages.batches.create(
    requests=[
        {
            # This custom id will be returned with the result, 
            # so we know this output is for feedback_001
            "custom_id": "feedback_001",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 500,
                "system": "You are a support analyst. Summarize customer feedback in 2 short bullet points.",
                "messages": [
                    {
                        "role": "user",
                        "content": "The app is useful, but the login takes too much time."
                    }]
            }},
        {
            # This custom id will be returned with the result
            # so we know this output is for feedback_002
            "custom_id": "feedback_002",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 500,
                "system": "You are a support analyst. Summarize customer feedback in 2 short bullet points.",
                "messages": [
                    {
                        "role": "user",
                        "content": "The dashboard is clean, but export to PDF is missing."
                    }]
            }}
    ])

print(f"Batch ID: {batch.id}")

# Wait until the batch completes
while True:
    current_batch = client.messages.batches.retrieve(batch.id)

    if current_batch.processing_status == "ended":
        break

    time.sleep(30)

# Read the results
for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        print(f"{result.custom_id}: {result.result.message.content[0].text}")

    elif result.result.type == "errored":
        print(f"Error in {result.custom_id}: {result.result.error}")

    elif result.result.type == "canceled":
        print(f"Canceled: {result.custom_id}")

    elif result.result.type == "expired":
        print(f"Expired: {result.custom_id}")

Three things to know.

• Use custom_id to tie each result back to your input. Without it you cannot match results to requests.

• You can combine the Batch API with prompt caching. Both discounts apply together, so if your requests share the same system prompt, use both for maximum savings.

• Use the Batch API for async workloads only. If you need a real-time response, use the standard Messages API.

3. How to Register for the exam

The exam is currently available to employees of companies in the Anthropic Partner Network. The Partner Network is free to join. Any company building with Claude qualifies for it.

Step 1 — Join the Partner Network

Your company needs to be part of the Anthropic Partner Network. If you are not in the partner network then apply for Claude Partner Network.

Step 2 — Request exam access

If you are already in the partner network, then login to the network and take up the exam.

Step 3 — About exam

60 questions. 120 minutes. No notes, no AI tools, no external resources are allowed.

Free prep resources

Free resources are available on Anthropic Academy and open to everyone. Start there regardless of whether you have exam access yet.

Certificate validity

The certificate is valid for 6 months. After that you need to recertify.

Conclusion

I hope this gave you a clear picture of what the exam covers. We went through all the domains across both parts.

I have also added 6 sets of practice questions to the GitHub repo.

These concepts are not just for the exam. Knowing them well will make you a better engineer when building with Claude.

Happy Learning!

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• Google DeepMind has introduced AI Pointer. You can point to something on your screen and ask Gemini to act on it. It understands what you are pointing at, so you don’t need long prompts. It also supports voice, text, and images. Check Google DeepMind’s post for more details.

• OpenAI has brought Codex to the ChatGPT mobile app. You can track tasks, review outputs, and guide Codex from your phone. Your files and credentials stay on the machine where Codex is running, while updates come to your phone in real time. Check OpenAI’s post for more details.

• OpenClaw’s Peekaboo is worth checking if you are exploring screen based agents. It helps AI agents capture screens, understand what is on them, and automate GUI actions. It works as both a CLI and MCP server for Codex, Claude Code, and Cursor. Check the Peekaboo GitHub repo for more details.

• Thinking Machines Lab has introduced interaction models. The idea is to make AI conversations feel more natural and live. The interesting part is the architecture. One model stays responsive during the live conversation, while a background model handles reasoning, search, and tool use. Check Thinking Machines Lab’s post for more details.

OSS Highlight of the Week

This week we are featuring Flue. It is an agent harness framework for building headless and programmable agents. Think of it like Claude Code, but without the terminal UI or human operator. It supports sandboxes, sessions, skills, MCP tools, and deployment across runtimes. Check the Flue GitHub repo for more details.

Share

Good to know

• Claude Code now supports /goal. You can give a task with a clear goal. Claude will keep working until that goal is done. A small evaluator model checks the progress after each turn. Check Claude Code docs for more details.

• Claude Platform is now available directly on AWS. AWS customers can now use more Claude capabilities, beyond Bedrock models. It includes Claude Managed Agents, code execution, web search, Skills, MCP, and more. Check Claude’s post for more details.

• OpenAI has introduced Daybreak for cybersecurity. It brings GPT 5.5 and Codex Security into security workflows. It helps teams review code, find risks, validate patches, and fix issues faster. The goal is to bring AI earlier into secure software development. Check OpenAI’s Daybreak page for details.

• I came across Thariq’s post on using HTML instead of Markdown for agent outputs. Markdown works well for simple notes, but large outputs can become hard to read. HTML can show the same content with better visuals and richer information. His collection has 20 HTML examples generated by agents. Check the post and collection for more details.

Notable FYIs

• Google has released Agent Skills for Google products. It includes skills for BigQuery, Cloud Run, Firebase, GKE, and more. It also covers Google Cloud onboarding, authentication, and network observability. Check the Google Skills GitHub repo for more details.

• If you are using AI coding agents and want to know where your tokens are going, check CodeBurn. It shows usage across Claude Code, Codex, and Cursor. It also breaks usage down by task, tool, model, and project. You also get an interactive terminal dashboard for cost visibility. Check the CodeBurn GitHub repo for more details.

• xAI has released Grok Build. It is a coding agent that runs from the terminal. It comes with familiar coding agent features like plans, skills, plugins, hooks, and parallel subagents. Check xAI’s Grok Build page for more details.

• Claude Code now has Agent View. It helps you manage many Claude Code sessions from one place. You can see which agents need input, which are still working, and which are done. It is useful if you run multiple coding agents in parallel. Check Claude’s blog for more details.

• Mirage is a virtual filesystem for AI agents. It gives agents one common way to access tools like S3, Google Drive, Slack, Gmail, and more. Agents can use simple file commands instead of separate APIs. Check the Mirage GitHub repo for more details.

• Higgsfield has released Supercomputer. It is an AI agent for creating ads, product shots, marketing content, and campaigns. You can describe what you want, and it picks the right model for the task and gets the work done. Check Higgsfield’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• Claude Certified Architect Foundations: The Complete Guide - Part 1

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• Anthropic has signed a compute deal with SpaceX. This will increase Claude’s compute capacity. Because of this, Claude Code’s five hour limits are now doubled for paid tiers. Peak hour limit reductions are also removed. Check Anthropic’s announcement for more details.

• OpenAI has released GPT 5.5 Instant as ChatGPT’s new default model. It is also available in the API. OpenAI says it gives smarter, more accurate, and clearer answers based on your context. Check OpenAI’s announcement for more details.

• We have already seen models with 1M context windows. But SubQ has introduced a model built for 12M token reasoning. It is designed to work across full repos and long context tasks. SubQ says it runs at one fifth the cost of leading LLMs. Check SubQ’s post to know how this model works.

• Claude and Perplexity are moving deeper into finance workflows. Claude has introduced finance agent templates. Perplexity has launched Perplexity Computer for Finance. Both show how AI tools are moving from general chat to specific business work. Check their posts for more details.

OSS Highlight of the Week

This week we are featuring Deepsec. It is an open source security harness from Vercel Labs. It uses coding agents to find vulnerabilities in your codebase. It can scan large repos, investigate issues, and generate findings with recommendations. Check the GitHub repo if you want to try agent based security scanning.

Good to know

• Eugene Yan has written a practical post on working better with AI. He talks about giving better context, saving your preferences into config, and making output verification easier. Useful if you use AI for writing, coding, or daily work. Check Eugene’s post for more details.

• Paper Copilot is a useful site for AI and ML papers. It brings papers from different conferences into one place and makes them easier to explore. Useful if you want to track new research without jumping across many sites. Check Paper Copilot for more details.

• Editframe has launched Agent Skills for video. This skill helps coding agents create videos from simple prompts. You can use it with Claude Code, Cursor, or Codex. It can generate a working video or a full interactive GUI from your prompt. Check the Editframe post for more details.

• Inworld has released Realtime TTS 2. It is built for realtime voice conversations. It understands the full audio context, including tone, pacing, and emotional state. Check Inworld’s post for more details.

• SpAItial has released Echo 2 for 3D world generation. It can take text or image input and create a 3D world that can be explored in real time. This can be useful for games, digital twins, architecture, and robotics simulation. Check SpAItial’s post for more details.

Notable FYIs

• OpenAI has released three new audio models in the API. GPT Realtime 2 brings GPT 5 class reasoning to voice apps. GPT Realtime Translate supports live speech translation, and GPT Realtime Whisper supports live transcription as someone speaks. Check OpenAI’s announcement for more details.

• Last time we covered Claude Managed Agents. Now Anthropic has added more features to Claude Managed Agents. It includes dreaming, outcomes, webhooks, and multiagent orchestration. Dreaming reviews past work and improves memory over time. Outcomes checks whether the work meets the expected result. Check Anthropic’s announcement for more details.

• xAI has introduced Custom Voices and Voice Library for Grok. Developers can create their own voice and use it in Grok’s TTS and Voice Agent APIs. Teams can also browse, preview, and manage voices from the xAI console. Check xAI’s announcement for more details.

• Xiaomi has open sourced MiMo V2.5 Pro. It is built for agentic coding, long horizon tasks, and large context work. Xiaomi says it can handle complex workflows with many tool calls and a 1M token context window. Check Xiaomi’s post for more details.

• Anthropic has released Claude Security for Claude Enterprise customers. It scans code for vulnerabilities and uses Opus 4.7 to generate proposed fixes. It also supports scheduled scans, targeted scans, triage tracking, and exports for audit workflows. Check Claude’s announcement for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

I have been building agentic systems with Claude for a long time. When I heard about the exam, I wanted to understand what it actually tests.

So I went through the entire exam guide, also took some mock tests to understand what they covered.

Below are the sections you need to understand to become a Claude Certified Architect.

1. Agentic Architecture & Orchestration

2. Tool Design & MCP Integration

3. Claude Code Configuration

4. Prompt Engineering & Structured Output

5. Context & Reliability

Each section is detailed enough to be its own blog. We will cover the first three in this part. The remaining sections along with how to register will be in Part 2.

I have also put together a set of practice questions with answers on GitHub. I will keep adding more as I come across them.

1. Agentic Architecture & Orchestration

This section carries 27% of your exam score. It covers Claude Agent SDK, the library you use to build production grade agents. Below are the key Agent SDK concepts, that turn a normal LLM into an agent.

• stop_reason

• Conversation History

• Loop Termination

• Multi-Agent Systems

• Task Decomposition

• Hooks

• Session Management

A normal LLM call is simple. You send a message, Claude replies, done. An agent is different. It is multiple LLM calls chained together until the task is fully complete. It includes tool calling, getting results, and deciding what to do next.

Let us start with stop_reason. It is the core of every agent loop.

stop_reason

Every Claude API response has a field called stop_reason. It tells you why Claude stopped. This is what decides whether your loop continues or ends. stop_reason has multiple values. The three you need to know for the exam are,

If stop_reason == "tool_use" then it means Claude wants to call a tool. Then you execute the tool, append the result, and loop again.

If stop_reason == "end_turn" then Claude is done. We can return the response to the user. Loop ends.

If stop_reason == "max_tokens" then the response got cut off. This happens when Claude hits the max_tokens limit you set in the API call.

If the response genuinely needs more tokens, increase max_tokens. If the response is too verbose, then restructure your prompt to produce a shorter output. Never return a cut-off response as it is incomplete.

Here is the stop_reason with all three options, explained in code.

import anthropic
import json

client = anthropic.Anthropic()

class Agent:
    def __init__(self, tools):
        self.tools = tools

    def run(self, task: str) -> str:
        # Every conversation starts with the user task
        messages = [{"role": "user", "content": task}]

        while True:
            # Claude does not remember previous call, 
            # So we pass the full conversation history every time
            response = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=1024,
                tools=self.tools,
                messages=messages
            )

            # Check the stop_reason to ensure the Task is complete
            if response.stop_reason == "end_turn":
                return extract_text(response.content)
            
            # If stop_reason is tool_use then execute the tool
            elif response.stop_reason == "tool_use":

                # Step 1 — save what Claude said, including which tool it wants to call
                messages.append({
                    "role": "assistant",
                    "content": response.content
                })

                for block in response.content:
                    if block.type == "tool_use":

                        # Step 2 — we execute the tool, not Claude
                        result = tool_map[block.name](**block.input)

                        # Step 3 — send the tool result back so Claude can continue
                        # tool_use_id tells Claude which tool call this result belongs to
                        messages.append({
                            "role": "user",
                            "content": [{
                                "type": "tool_result",
                                "tool_use_id": block.id,
                                "content": json.dumps(result)
                            }]
                        })
                # Claude now sees the result and decides what to do next

            else:
                # stop_reason == "max_tokens" — response was cut off, never return incomplete results
                raise RuntimeError(f"Unexpected: {response.stop_reason}")

The loop runs until Claude returns end_turn.

Handling stop_reason is one of the most important concepts in agentic workflows. Learn more in the official docs.

Now that you understand stop_reason, let us look at how Claude keeps track of everything that happens in the loop.

Conversation History

In agentic workflows, Claude has no memory between API calls. Every time you call the API, you have to pass the full conversation history. That is how Claude knows what happened before.

The messages array holds that history. User messages, Claude responses, and tool results all get appended here until the task is done.

So how does the messages array grow? Every time stop_reason == "tool_use", you append two things.

First, you append the response Claude just sent. This contains the tool name Claude wants to call and the input values it decided to pass.

messages.append({
    "role": "assistant",
    "content": response.content    # text block + tool_use block
})

Then you execute the tool and append the result back. The tool_use_id in the result must match the one from the response we appended previously. This tells Claude that this result is for the tool call it requested.

Now you loop again. Claude reads everything in the messages array and decides what to do next.

for block in response.content:
    if block.type == "tool_use":
        result = tool_map[block.name](**block.input)

        messages.append({
            "role": "user",
            "content": [{
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": json.dumps(result)
            }]
        })

Do not add text immediately after tool results. Send tool results directly without additional text

Loop Termination

An agent loop can terminate for different reasons. We need to identify each termination reason and handle it. If we do not, the agent either runs forever, returns incomplete results, or takes actions it should not.

Here are the three ways we handle it.

• stop_reason == "end_turn" - Claude is done. Return the response to the user and exit the loop.

• result.get("requires_human") == True - escalate to a human and exit the loop.

• MAX_ITERATIONS = 10 - the loop hit the safety cap. Raise an error and exit.

In all three cases, we handle the termination and never return incomplete results. Here is how all three work together in code.

MAX_ITERATIONS = 10

def escalate_to_human(result: dict) -> None:
    # Notify your human review system — ticket, Slack, email etc.
    print(f"Escalating to human: {result}")

def extract_text(content) -> str:
    # Extract the text block from Claude's response
    for block in content:
        if hasattr(block, "text"):
            return block.text

class Agent:
    def __init__(self, tools):
        self.tools = tools

    def run(self, task: str) -> str:
        # Every conversation starts with the user task
        messages = [{"role": "user", "content": task}]

        for i in range(MAX_ITERATIONS):
            # Claude does not remember previous calls
            # So we pass the full conversation history every time
            response = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=1024,
                tools=self.tools,
                messages=messages
            )

            # Claude is done — return the response to the user
            if response.stop_reason == "end_turn":
                return extract_text(response.content)

            elif response.stop_reason == "tool_use":
                # Append Claude's response to history
                messages.append({
                    "role": "assistant",
                    "content": response.content
                })

                for block in response.content:
                    if block.type == "tool_use":
                        # we execute the tool
                        result = tool_map[block.name](**block.input)

                        # Tool requires human intervention — escalate and exit the loop
                        if result.get("requires_human"):
                            escalate_to_human(result)
                            return

                        # Append tool result so Claude can continue
                        messages.append({
                            "role": "user",
                            "content": [{
                                "type": "tool_result",
                                "tool_use_id": block.id,
                                "content": json.dumps(result)
                            }]
                        })

        # Max iterations reached — exit with error, never return incomplete results
        raise RuntimeError("Agent hit max iterations without completing")

Multi-Agent Systems

You now know how a single agent works. But some tasks are too complex for one agent to handle alone.

That is where multi-agent systems come in. You break the work across multiple specialized agents. Each one is the same Agent class we defined in the previous sections, just with different tools and a different responsibility.

search_agent = Agent(tools=[web_search_tool])
analysis_agent = Agent(tools=[analysis_tool])
report_agent = Agent(tools=[report_tool])

Anthropic uses a pattern called hub-and-spoke to coordinate agents. Think of it like this. One coordinator receives the task, breaks it down, and delegates to specialized agents. Each agent does its part and reports back. The coordinator collects everything and produces the final response.

Now, when do you run agents in parallel and when in sequence?

If the tasks are independent, run them in parallel. If one task needs the output of another, run them in sequence.

import asyncio

# Step 1 — Independent subagents, run in parallel
search_result, document_result = await asyncio.gather(
    search_agent.run("Search web for competitors"),
    analysis_agent.run("Analyze our internal documents")
)

# Step 2 — This subagent depends on Step 1, runs after
report_result = report_agent.run("Generate report", search_result, document_result)

# Step 3 — Coordinator collects all results and produces the final response
final_result = coordinator_agent.run("Finalize", search_result, document_result, report_result)

Every subagent starts with a fresh context. It does not have access to the coordinator's conversation history. The only way to pass context to a subagent is through its prompt. So be specific and detailed in what you pass.

# Too vague — subagent does not know enough to do its job well
search_agent.run("Search web for competitors.")

# Right — give the subagent exactly what it needs
search_agent.run("Search web for competitors in the B2B SaaS space. Focus on pricing and features.")

Agents never talk directly to the user. They always report back to the coordinator. The coordinator owns the task from start to finish.

Task Decomposition

Task decomposition is an important part of building multi-agent systems. When you build one, remember that your coordinator agent should never delegate a vague task directly to a subagent.

Take this for example. Your coordinator receives “Research the competitive landscape for our project management tool.” If it passes this directly to a subagent, the subagent does not know where to start. You will get different results every run.

Break it down first.

• Search Google for “Notion vs Linear pricing plans 2026”

• Extract pricing tiers, feature limits, and target user segments for both

• Generate a comparison table showing where your product has an advantage

Each subtask goes to one specialized agent. Each agent has one job and knows exactly what to return.

The agents are not the problem. Vague instructions are.

Hooks

When you build an agent, some actions need to be controlled programmatically. You cannot rely on Claude to always follow prompt instructions. That is where hooks come in.

Hooks are callback functions you register in the Claude Agent SDK. They fire automatically at specific points during agent execution. No prompts involved.

Two hooks you need to know for the exam,

PreToolUse :

It fires before a tool executes. Since it runs before, it can block the action. Use it when you want to stop Claude from doing something like blocking rm -rf commands, preventing writes to .env, or requiring human approval before processing a refund above $500.

PostToolUse :

PostToolUse fires after a tool executes. It cannot block anything since the action already happened. Use it for things like auto-formatting a file after Claude edits it, writing to an audit log after a deletion, or running a linter after every code change.

Here is a real example. Your agent has a process_refund tool. Any refund above $500 needs human approval before it goes through.

from claude_agent_sdk import ClaudeAgentOptions, ClaudeSDKClient, HookMatcher

async def block_large_refunds(input_data, tool_use_id, context):
    tool_name = input_data["tool_name"]
    tool_input = input_data["tool_input"]

    # Only intercept the process_refund tool
    if tool_name != "process_refund":
        return {}  # allow all other tools to proceed

    # Block refunds above $500 — requires human approval
    if tool_input.get("amount", 0) > 500:
        return {
            "hookSpecificOutput": {
                "hookEventName": input_data["hook_event_name"],
                # deny stops the tool from executing
                "permissionDecision": "deny",
                # this reason is sent back to Claude so it knows why it was blocked
                "permissionDecisionReason": "Refunds above $500 require human approval"
            }
        }

    # Allow refunds under $500 to proceed normally
    return {}

options = ClaudeAgentOptions(
    hooks={
        # PreToolUse fires before the tool executes
        "PreToolUse": [
            # matcher tells the SDK which tool to intercept
            HookMatcher(matcher="process_refund", hooks=[block_large_refunds])
        ]
    }
)

async with ClaudeSDKClient(options=options) as client:
    await client.query("Process a $600 refund for order ORD-999")
    async for message in client.receive_response():
        print(message)

The key difference between hooks and prompt instructions is reliability. A prompt instruction like “never process refunds above $500” is not guaranteed. Claude may follow it or not. A hook always fires. If you want something enforced without exception, put it in a hook.

Session Management

A session contains the full conversation history. The SDK saves it to disk automatically so you can come back to it later.

Here is what you need to know.

• Session Resumption

• Session Isolation

• Session Forking

Session Resumption

Imagine your agent is halfway through a long task and the server crashes. Without session resumption, it starts from scratch. With it, you pass the session ID and the agent continues from where it stopped.

Here is how you implement it.

from claude_agent_sdk import ClaudeAgentOptions, query, ResultMessage

# Start a session and save the session ID
session_id = None
async for message in query("Analyze the refund flow in our codebase"):
    if isinstance(message, ResultMessage):
        session_id = message.session_id

# Resume later — agent has full context from before
async for message in query(
    prompt="Now fix the bug you found",
    options=ClaudeAgentOptions(
        resume=session_id,
        allowed_tools=["Read", "Edit", "Write", "Glob", "Grep"],
    ),
):
    if isinstance(message, ResultMessage) and message.subtype == "success":
        print(message.result)

Session Isolation

Each user or task gets its own session. If two users share the same session, Claude will mix up their context and produce wrong results. Always create a new session for each user or task.

Session Forking

Sometimes you want to try a different approach from where you are, without affecting your current session. For example, your agent has analyzed a codebase and you want to try both a REST and a GraphQL implementation. Instead of starting over, you fork the session. Both forks start from the same point. The original stays untouched.

from claude_agent_sdk import ClaudeAgentOptions, query

# Fork — original session stays unchanged
options = ClaudeAgentOptions(
    resume=session_id,
    fork_session=True   # new session ID, same history
)

async for message in query("Try a GraphQL approach instead", options=options):
    print(message)

To learn more about working with sessions, check out the Claude Agent SDK session guide.

2. Tool Design & MCP Integration

MCP stands for Model Context Protocol. It is an open standard for connecting your agent to external services. For example, your agent can query a database, fetch GitHub issues, or send a Slack message through an MCP server.

If you are new to MCP, check out our complete MCP Server Guide that covers everything from scratch.

Below are the key concepts.

• MCP Components

• Tool Descriptions

• Structured Error Responses

• Tool Distribution

• MCP Server Configuration

MCP Components

An MCP server consists of three things.

• Tools are functions exposed by the MCP server. When Claude calls a tool, the MCP server executes that function. Claude decides when to call the tool and what input to send.

• Resources are read only data exposed by the MCP server. They give Claude extra context for the task. For example, a resource can be an API spec, database schema, product catalog, or project document.

• Prompts are reusable instructions exposed by the MCP server. They tell Claude how to handle a repeated task. In supported clients, prompts can also be triggered as slash commands.

Here is a simple MCP server example. This one connects to PostgreSQL and shows all three components.

from mcp.server.fastmcp import FastMCP
import psycopg2
import os

mcp = FastMCP("DatabaseServer")

# Connect to PostgreSQL — use environment variables for credentials
conn = psycopg2.connect(
    host=os.getenv("DB_HOST"),
    database=os.getenv("DB_NAME"),
    user=os.getenv("DB_USER"),
    password=os.getenv("DB_PASSWORD")
)

# Tool — model calls this to query the database
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up an order by order ID from the database."""
    cursor = conn.cursor()
    cursor.execute("SELECT id, status, item FROM orders WHERE id = %s", (order_id,))
    row = cursor.fetchone()
    
    if not row:
        return {"error": "Order not found"}
    
    return {"id": row[0], "status": row[1], "item": row[2]}

# Resource — exposes the full product catalog from the database
@mcp.resource("data://product-catalog")
def get_product_catalog() -> str:
    """Returns all products from the database."""
    cursor = conn.cursor()
    cursor.execute("SELECT name, price FROM products")
    rows = cursor.fetchall()
    return "\n".join([f"{row[0]} - ${row[1]}" for row in rows])

# Prompt — can appear as a slash command in supported clients
@mcp.prompt()
def review_order_prompt() -> str:
    """Template for reviewing an order status."""
    return """You are an order review specialist. 
When reviewing an order:
- Check the current status
- Identify any issues
- Suggest next steps"""

if __name__ == "__main__":
    mcp.run()

Once this MCP server is running and connected to your agent, you can query it directly.

“What is the status of order ORD-999?”

The agent calls the get_order tool, queries the database in real time, and returns the result.

Tool Descriptions

When Claude has multiple tools, it uses the tool description to decide which one to call. If the description is vague, Claude may pick the wrong tool.

A good tool description should clearly say three things.

• What the tool does

• What input it expects

• When to use it and when not to

# Bad — too vague, Claude cannot differentiate
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Retrieves order details."""
    ...

# Good — clear boundaries, Claude knows exactly when to use it
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up an order by order ID. 
    Use this when you need order status, items, and shipping details. 
    Do not use this for customer account lookups."""
    ...

Structured Error Responses

When a tool fails, do not return a generic error. Claude needs to know what went wrong so it can decide what to do next.

In production, return more than just an error. Tell Claude what went wrong, whether it can retry, and what to do next.

Here are a few common categories.

• Transient - If the external service is down or timed out, we return the error as transient. It means the failure is temporary and usually safe to retry.

• Validation - If the input is missing or invalid, we return the error as validation. It means Claude should fix the input before calling the tool again.

• Business - If the tool runs, but the action is not allowed by your system rules, we return the error as business. It means there is no point retrying the same request.

• Permission - If the user or agent does not have access to perform the action, we return the error as permission. It means access should be granted first before retrying.

@mcp.tool()
def process_refund(order_id: str, amount: float) -> dict:
    """Process a refund for a given order."""

    # validation — bad input, no point retrying
    if not order_id:
        return {"error": True, "errorCategory": "validation", "isRetryable": False, "message": "order_id is required"}

    # business — order is not eligible for refund, refund window has expired
    if order_status == "delivered_over_30_days":
        return {"error": True, "errorCategory": "business", "isRetryable": False, "message": "Refund window has expired. Orders can only be refunded within 30 days of delivery."}
    
    # transient — service down, safe to retry
    if not payment_service.is_available():
        return {"error": True, "errorCategory": "transient", "isRetryable": True, "message": "Payment service unavailable. Try again."}

    return {"success": True, "refundId": "REF-001"}

Never return a generic error like {"error": "Operation failed"}. The more context you give Claude, the better it recovers.

Tool Distribution

Give each agent only the tools it really needs. Too many tools can confuse Claude. It may call the wrong tool or take the wrong action.

# Bad — agent has access to tools it should never use
research_agent = Agent(tools=[
    web_search_tool,
    process_refund_tool,    # research agent should never process refunds
    delete_record_tool,     # research agent should never delete records
    synthesis_tool
])

# Good — agent only gets what it needs
research_agent = Agent(tools=[
    web_search_tool,
    synthesis_tool
])

Use allowed_tools and disallowed_tools in the Claude Agent SDK to control which tools each agent can access.

options = ClaudeAgentOptions(
    mcp_servers={"orders": order_server},
    allowed_tools=[
        "mcp__orders__get_order",       # pre-approve read operations
        "mcp__orders__get_customer"
    ],
    disallowed_tools=[
        "mcp__orders__delete_record",   # block delete operations
        "mcp__orders__update_record"    # block write operations
    ]
)

To learn more, check the official SDK reference.

MCP Server Configuration

When you add an MCP server to your project, you need to decide where to configure it. There are two scopes.

• Project level — .mcp.json in your repo. It can be shared with the whole team via version control.

• User level — ~/.claude.json. It is personal and experimental. It is not shared.

// .mcp.json — project level, committed to the repo
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"  // never hardcode secrets
      }
    },
    "database": {
      "command": "python",
      "args": ["./mcp_servers/database_server.py"],
      "env": {
        "DB_URL": "${DATABASE_URL}"
      }
    }
  }
}

Use existing community MCP servers for standard integrations like GitHub, Slack, and Jira. Build custom servers only for internal or team-specific workflows.

Check the official docs for MCP and Agent SDK integration.

3. Claude Code Configuration & Workflows

Claude Code deserves its own blog. We have covered the important concepts that will be useful for your daily development as well as for the exam.

• CLAUDE.md

• Custom Commands and Skills

• Path-specific Rules

• Plan Mode vs Direct Execution

• Headless Mode

• Hooks

• Built-in Tools

CLAUDE.md

CLAUDE.md is the first file Claude reads when it starts a session. It tells Claude the project conventions and rules.

It supports three levels:

• User level — ~/.claude/CLAUDE.md. Applies to all your projects.

• Project level — CLAUDE.md in the repo root. Applies to the whole project. Commit this to Git.

• Directory level — CLAUDE.md inside a subdirectory. Applies only when Claude is working in that folder.

repo/
├── CLAUDE.md              # applies to everything
├── frontend/
│   └── CLAUDE.md          # applies only in /frontend
└── backend/
    └── CLAUDE.md          # applies only in /backend

It can be placed directly in the repo root or inside the .claude/ directory. Both work the same way.

CLAUDE.md is advisory. Claude reads it and tries to follow it. But it is not guaranteed. Claude may not always follow it. If you have a constraint that must always run without exception, put it in a hook. Hooks fire programmatically and always run regardless of what Claude decides.

Custom Commands and Skills

Skills give domain-specific expertise to Claude. You package your team’s workflows, standards, and best practices into a SKILL.md file. Claude picks them up automatically when the task matches, or you call them directly with a slash command.

Skills live in two places:

• .claude/skills/ — project level. Shared with the team via Git.

• ~/.claude/skills/ — user level. Personal, not shared.

Each skill lives in its own subdirectory. For example, a review-security skill would be at .claude/skills/review-security/SKILL.md.

<!-- .claude/skills/review-security/SKILL.md -->
---
name: review-security
description: Run a security audit on the current file
allowed-tools: Read, Grep
context: fork
argument-hint: [file-path to review]
---

Review this file for SQL injection, XSS, and hardcoded secrets.
Output findings as JSON with severity, line number, and recommendation.

Three fields to know:

• allowed-tools - It controls which tools the skill can use. For example, if you set Read, Grep, the skill can only read files and search. It cannot write or run commands.

• context: fork - It runs the skill in a separate session. Whatever Claude does in that session stays there. Use this when you want Claude to explore something without affecting your main session.

• argument-hint - It shows a hint when someone types the slash command. It helps the user to understand what input to provide.

All fields are optional. But always include description so Claude knows when to load the skill automatically. Check the full frontmatter reference for all available fields.

Custom Commands were the older way to define slash commands in Claude Code. They lived in .claude/commands/*.md. Skills have now replaced them. If you are starting fresh, use Skills.

You can also find community-built skills at skills.sh.

Path-specific Rules

Rules live in .claude/rules/ as markdown files. When you want path-specific rules for your codebase, you add a paths field in your rules.

<!-- .claude/rules/frontend-rules.md -->
---
paths:
  - "frontend/**/*.ts"
  - "frontend/**/*.tsx"
---

Always use React functional components.
Never use class components.
Use Tailwind for styling. Never use inline styles.

<!-- .claude/rules/backend-rules.md -->
---
paths:
  - "backend/**/*.py"
---

Always use FastAPI for routes.
Business logic goes in services/. Never in routes/.
Always add type hints.

When you write rules like above, Claude picks up the right rules based on the file it is touching. This is more token efficient than putting all rules in one big CLAUDE.md.

Note: The official docs use paths: but some versions of Claude Code work more reliably with globs:. If paths: does not work, try globs: with your pattern instead.

Plan Mode vs Direct Execution

By default, Claude executes tasks immediately. It reads files, writes code, runs commands without stopping.

Plan mode changes that. Claude outlines what it is going to do first. No files written, no commands run. You review the plan and approve before anything happens.

claude --permission-mode plan

Use plan mode for large scale or destructive changes. For small, well-scoped tasks, just run directly.

Headless Mode

Headless mode runs Claude non-interactively using the -p flag. No terminal prompts. No approvals. Used for CI/CD pipelines and automation scripts.

claude -p "Review this PR for security vulnerabilities" --output-format json > report.json

Use --output-format json when you need the output in json.

Check more about Claude’s mode in the Claude Code docs.

Hooks

We already covered hooks in the Claude Agent SDK section. The concept is the same but the implementation is different in Claude Code.

In the Agent SDK, hooks are Python callback functions. In Claude Code, hooks are shell commands configured in .claude/settings.json. They fire automatically at specific points in Claude Code’s lifecycle.

As we already saw, two hooks matter here.

PreToolUse fires before a tool executes and can block the action. PostToolUse fires after tool execution. Here is how they look in Claude Code.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "echo '$CLAUDE_TOOL_INPUT' | grep -q 'rm -rf' && exit 2 || exit 0"}]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{"type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"}]
    }]
  }
}

Built-in Tools

Claude Code ships with built-in tools. As an architect, you need to know when each one is the right choice.

Tool              When to use
-------           -----------
Read              Read the contents of a file
Write             Create or overwrite a file
Edit              Make targeted changes to a specific file
Bash              Run shell commands
Grep              Search for patterns inside file contents
Glob              Find files by name or pattern
LSP               Code intelligence — jump to definitions, find references, get type errors
Agent             Spawn a subagent with its own context window to handle a task
WebFetch          Fetch content from a URL
WebSearch         Search the web
Skill             Run a skill within the main conversation
NotebookEdit      Edit Jupyter notebook cells
AskUserQuestion   Ask the user a multiple choice question to clarify requirements

These are the most commonly used tools. Claude Code has many more built-in tools. Check the full tools reference for the complete list.

Up Next:

That is it for Part 1.

We covered agentic architecture, MCP integration, and Claude Code configuration.

In Part 2, we will move to the remaining areas. That includes prompt engineering, structured outputs, context management, reliability, and the registration flow.

I have added the mock test materials to this GitHub page. I will keep adding more questions as I find useful ones.

If you are planning to take the exam, use this blog and the mock questions as a practical guide. But before the exam, make sure you also go through the official docs once.

See you in Part 2.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Cursor + Opus 4.5 - The Developer Workflow

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• OpenAI has released GPT 5.5, their smartest model so far. It is good at coding, debugging, and creating docs. It is also strong at agentic coding, computer use, and research work. OpenAI says it matches GPT 5.4 speed while completing Codex tasks with fewer tokens. Check OpenAI’s announcement for more details.

• DeepSeek has released DeepSeek V4. The model is open sourced and comes with 1M context window at a lower cost. It has two versions, Pro for stronger performance and Flash for faster and economical use. You can try it on Chat or use the API. Check DeepSeek’s post for more details.

• Anthropic has launched Claude Design, a new tool for creating visual work with Claude. It can help with wireframes, prototypes, pitch decks, landing pages, and campaign visuals. It can also build visuals that match your existing brand style. Check Anthropic’s announcement for more details.

• Moonshot AI has released Kimi K2.6, an open source coding model. It is built for long running coding tasks. It can also create richer frontend like animated hero sections and motion based UI. It also supports large agentic workflows. Check Kimi’s post for more details.

OSS Highlight of the Week

This week we are featuring HyperFrames. It is an open source video rendering framework. It lets you create videos using HTML, preview them in the browser, and export them as MP4. It also works well with AI coding agents like Claude Code, Cursor, Gemini CLI, and Codex, so they can help you create videos with animations. Check the GitHub repo for more details.

Share

Good to know

• Anthropic is testing a change to Claude Code access. Claude Code access was removed from the Pro plan for around 2% of new Pro signups. Those users now need the $100 Max plan to use Claude Code. Existing Pro users are not affected for now, but we need to wait and see if this expands later.

• Anthropic’s Mythos model was reportedly accessed by a private Discord group. Mythos was meant only for selected partners, because Anthropic considered it too powerful for public release. The group reportedly used leaked vendor details to find the access path. Check Bloomberg’s report for more details.

• Vercel reported a recent security incident. It started after Context.ai, a third party AI tool used by one employee, was compromised. The attacker used that access to enter some Vercel systems. They also decrypted some non sensitive environment variables. Read Vercel’s security bulletin for full details.

• Cursor and SpaceXAI are working together on AI for coding tasks. Cursor brings the coding product. SpaceXAI brings the Colossus training supercomputer. SpaceXAI also has the option to acquire Cursor later this year for $60 billion. Check the post for more details.

Notable FYIs

• OpenAI has released ChatGPT Images 2.0. It improves image generation, text rendering, and multilingual support. It can create visuals for social posts, presentations, infographics, comics, and other content. Check OpenAI’s announcement for more details.

• Qwen has released Qwen3.6 27B, a 27B dense model focused on coding. It delivers strong agentic coding performance in a much smaller model. It also supports multimodal input and can work with coding agents. Check Qwen’s blog for more details.

• OpenAI has released Privacy Filter, an open source model for finding and masking personal data in text. It is useful for teams that want to clean sensitive data on their own systems. It can redact PII before the data is stored or processed. Check the GitHub repo for more details.

• We now have a free web search MCP server from Parallel. It is used for web search inside AI agents and MCP supported tools. It does not need any account or API key. You can use it with Claude Code, Codex, or any MCP supported tool. Check Parallel’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Cursor + Opus 4.5 - The Developer Workflow

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• Anthropic has released Claude Opus 4.7. It comes with stronger coding, high resolution vision, and a new xhigh effort level. Pricing remains the same as Opus 4.6. Anthropic notes that Mythos Preview still remains its best aligned model based on its evaluations. Check Anthropic’s page for more details.

• Google has released Gemini 3.1 Flash TTS. It generates more natural speech and supports 70+ languages. It also adds audio tags to control vocal style, pace, and delivery. Its audio output is watermarked with SynthID to identify AI generated content. Check Google’s announcement for more details.

• OpenAI has rolled out GPT 5.4 Cyber. It is built for defensive security work. Access to this model is now open through identity verification. OpenAI says it can inspect compiled software and find malware, vulnerabilities, and other security issues without the original source code. Check OpenAI’s post for details.

• Qwen has open sourced Qwen3.6 35B A3B. It is a sparse MoE model with 35B total parameters and 3B active. It comes with strong agentic coding and multimodal reasoning. It also supports both thinking and non thinking modes in one model. Check Qwen’s announcement for more details.

OSS Highlight of the Week

This week we are featuring Scion. It is an open source multi agent orchestration tool. It runs each agent in its own container and git worktree. It helps multiple agents work in parallel without getting in each other’s way. It works with Claude Code, Gemini CLI, Codex, and others too. Check the GitHub repo for more details.

Share

Good to know

• Google has launched the Gemini app for Mac. It is a native macOS app. You can share anything on your screen with Gemini to get help, including local files. Check Google’s post for more details.

• OpenAI has introduced GPT Rosalind. It is a new model built for life sciences research and drug discovery. OpenAI says it can reason across chemistry, proteins, and DNA, and help with experiment analysis. Check OpenAI’s post for more details.

• Google has solved one of the old problems in RNNs with Memory Caching. Earlier, RNNs had to rely on one fixed memory as the input got longer. This new method keeps useful memory from earlier in the sequence. The paper says this improves long context and recall heavy tasks. It also brings RNNs closer to Transformers. Check the paper for more details.

• I came across Baileys. It is a WebSockets-based TypeScript library for interacting with the WhatsApp Web API. If you are working on WhatsApp based apps, this is worth a look. Check the GitHub repo for more details.

Notable FYIs

• Anthropic has introduced routines in Claude Code. You can now set up repeatable automations and run them on a schedule, through an API call, or from GitHub events. Since they run on Claude Code’s web infrastructure, you do not need to keep your laptop open. Check Anthropic’s post for more details.

• Windsurf has launched Windsurf 2.0. It adds a new Agent Command Center to manage local and cloud agents in one place. Devin is now built into Windsurf, so cloud agents can keep working even after you close your laptop. Check Windsurf’s post for more details.

• OpenAI has updated Codex in a big way. It now goes beyond coding. It can handle computer use, run multiple agents, and browse the web. It also adds image generation and 90+ new plugins. OpenAI is also adding memory and automations for long running work. Check OpenAI’s post for more details.

• Google has introduced Skills in Chrome. You can now turn your prompts into one click tools. They can run on the page you are viewing or across selected tabs. Google is also adding a ready made Skills library. Check Google’s post for more details.

• If you are building agents, this is a must read. Garry Tan shared a useful idea on building AI agents. He says keep the harness thin and put more value into skills. His point is that the real bottleneck is not model intelligence. It is whether the model understands your data, process, and context. Check Garry Tan’s post for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Cursor + Opus 4.5 - The Developer Workflow

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• Anthropic’s new Project Glasswing is getting a lot of attention. It is a new effort to secure critical software. It is built around Claude Mythos Preview, Anthropic’s latest model. Anthropic says Mythos can find serious software flaws. It has already identified flaws in the Linux kernel and major browsers. Because of its capabilities, Anthropic is not making it publicly available. Check Anthropic’s announcement for more details.

• Meta is back in the model race with Muse Spark. It is the first model from Meta Superintelligence Labs. It supports multimodal reasoning and visual chain of thought, and multi agent tasks. Check Meta’s announcement for more details.

• Amazon has announced S3 Files. It lets you access S3 buckets like a file system, without moving data out of S3. It gives file system access to S3 data with low latency. Check AWS’s announcement for more details.

• OpenClaw has released a new memory feature called Dreaming. It is a background memory consolidation system for long term recall. It takes useful short term context and stores it in durable memory. It is off by default. Check OpenClaw’s docs for more details.

OSS Highlight of the Week

This week we are featuring nono. It is an open source sandbox for AI agents. It lets you run agents in an isolated environment without extra infrastructure. It also supports tools like Claude Code, Codex, OpenCode, and OpenClaw. Check the nono GitHub repo for more details.

Share

Good to know

• Anthropic has launched Claude Managed Agents. It helps teams build and run cloud hosted agents on Anthropic’s infrastructure. Anthropic handles things like sandboxing, permissions, state, and tracing. So teams can focus more on the agent itself. Check Anthropic’s announcement for more details.

• LangChain has introduced Deep Agents Deploy. It is an open alternative to Claude Managed Agents. It helps teams deploy production ready agents with one command. It is model agnostic and open source, so teams are not locked into one provider. Check LangChain’s announcement for more details.

• If you keep a lot of notes in markdown, Atomic is worth a look. It is an open source personal knowledge base. It turns markdown notes into a connected knowledge graph. You can explore it through wiki style pages, a canvas, and chat. Check the Atomic GitHub repo for more details.

• xAI looks to be scaling up fast. Elon Musk says they have 7 models in training. They include Imagine V2, two 1T variants, two 1.5T variants, a 6T model, and a 10T model. Check Elon Musk’s post for more details.

• IBM Research has released ALTK Evolve for AI agents. It helps agents learn from past runs instead of just re reading old transcripts. IBM says it turns agent traces into reusable guidelines, and improves reliability on harder tasks. Check the Hugging Face post for more details.

• Microsoft has released Memento. It is a new way to extend LLM output length without needing a bigger context window. It breaks reasoning into blocks, writes short summaries, and clears old KV cache. So the model can keep going longer. Check the Memento GitHub repo for more details.

Notable FYIs

• llmfit looks useful if you run models locally. It checks your RAM, CPU, and GPU, then tells you which models will run well on your machine. It also scores them across fit, speed, quality, and context. It comes with both a terminal UI and a CLI mode. Check the llmfit GitHub repo for more details.

• The skill called Graphify caught my attention. It is an open source skill for Claude Code and other coding assistants. It turns a folder of code, PDFs, markdown, and images into a queryable knowledge graph with one command. It can help you understand a codebase faster and trace architecture decisions. Check the Graphify GitHub repo for more details.

• Claude Code has added /autofix-pr in the CLI. You can now trigger PR autofix directly after finishing your PR. It sends your session to the cloud, so the autofixer gets full context to handle CI failures and review comments. Check the X post for more details.

• Perplexity has added Plaid integration to its Computer agent. Users can now link bank accounts, credit cards, and loans for a fuller view of their finances. Perplexity says Computer can analyze spending, track net worth, and build custom finance tools from simple prompts. Check Perplexity’s announcement for more details.

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.

For those who joined recently or are reading Dev Catch Up for the first time, I write about developer stories and open source, partly based on my work and experience interacting with people all over the globe.

Thanks for reading Dev Shorts! Subscribe for free to receive new posts and support my work.

Some recent issues from Dev Catch up:

• OpenClaw Workflow and Automation

• Claude Skills - Automate Your Workflows

• Finetuning DeepSeek-V3 with Tinker API

• Cursor + Opus 4.5 - The Developer Workflow

• Coding with Parallel Agents and Git worktrees

Join 8800+ developers to hear stories from Open source and technology.

Must Read

• Google has released Gemma 4. It is a new open model family. It is built from the same research and technology behind Gemini 3. Google says it supports agent workflows, multimodal reasoning, and 140 languages. Check Google DeepMind’s post for more details

• Microsoft has announced three new MAI models in Foundry. They are MAI Transcribe 1, MAI Voice 1, and MAI Image 2. These cover speech to text, voice generation, and image generation. The models focus on speed, quality, and lower cost. Check Microsoft’s announcement for more details.

• Qwen has introduced Qwen3.6 Plus. It comes with better coding, stronger multimodal vision, and a 1M context window in the API. Qwen says it is built to support real world agents and developer workflows. Check Qwen’s blog for more details.

• Anthropic accidentally exposed Claude Code source code through a map file in its npm package. The leaked code then spread across GitHub through multiple repos and forks. Anthropic sent takedown notices to remove those leaked copies. Check the TechCrunch report for more details.

OSS Highlight of the Week

This week we are featuring Semiotic. It is a React library for building data visualizations in web apps. It comes with schemas and an MCP server, so AI coding assistants can generate correct chart code on the first try. Check the GitHub repo for more details.

Share

Good to know

• Claude Code now has a No Flicker mode. It reduces screen flicker and keeps memory usage stable in long chats. It also adds mouse support in the terminal. Check Anthropic’s announcement for more details.

• Prism ML has introduced 1 bit Bonsai 8B. It is a model with 1 bit weights and needs only 1.15 GB of memory. Prism says it is built for robotics, real time agents, and edge use cases. Check Prism ML’s announcement for more details.

• Anthropic has shared new research on emotion concepts in language models. The research says models can form internal emotion related representations from human text. Anthropic says these patterns can influence how Claude behaves in some cases. Check Anthropic’s research post for more details.

• AI has helped a solo founder build a $1.8B business. Medvi is one reported example built with AI tools for coding, ads, and support. It shows how a very small team can now scale much faster with AI. Check the New York Times report for more details.

• Andrej Karpathy shared a workflow for building personal knowledge bases with LLMs. He uses them to turn papers, articles, repos, and images into a markdown wiki. The wiki then keeps growing through search, Q and A, and new outputs. Check Karpathy’s post for more details.

Notable FYIs

• Pika has released a beta video chat skill for agents. It is powered by a new real time model called PikaStream 1.0. Pika says it keeps memory and personality during calls and can also support agentic tasks in the same session. Check Pika’s announcement for more details.

• Boris Cherny shared practical Claude Code tips from his daily workflow. He showed features like teleport, remote control, loop, schedule, hooks, and Dispatch. These help Claude Code run across devices and automate more work. Check Boris Cherny’s thread for more details.

• Qwen has released Qwen3.5 Omni. It is a native multimodal model that can understand text, images, audio, and video. Qwen says it brings stronger multilingual support and better audio and video understanding. Check Qwen’s blog for more details

• Falcon has released Falcon Perception. It is a vision model for referring expression segmentation. Along with it, they also released Falcon OCR, a 0.3B OCR model. Falcon says it performs on par with much larger models. Check the Falcon’s post for more details.

• Z.ai has introduced GLM 5V Turbo, a vision model built for coding. It can understand images, video, text, and files as input. Z.ai says it is built for multimodal coding tasks and can work with agents like OpenClaw. Check Z.ai’s docs for more details

That’s it from us with this edition. We hope you are going away with a ton of new information. Lastly, share this newsletter with your colleagues and pals if you find it valuable. A subscription to the newsletter will be awesome if you are reading it for the first time.