Claude Code release notes: 2.1.202 controls workflow size and traceability
Part of the series: Claude Code release notes

Claude Code 2.1.202 is not the kind of release that shouts for attention. It does something more useful: it gives teams a way to say how large dynamic workflows should generally be, and it makes those runs easier to follow in OpenTelemetry.
A dynamic workflow in Claude Code is a script that orchestrates multiple subagents in the background. OpenTelemetry, often shortened to OTel, is an open standard for sending metrics, logs and traces to your own monitoring system. Together, they point to a practical question: when Claude can start many agent jobs, how do you keep the work appropriately sized and reviewable afterward?
Source: Claude Code v2.1.202 release notes and the @anthropic-ai/claude-code 2.1.202 npm package.
Claude Code release notes 2.1.202: size becomes a control signal
The clearest change is the Dynamic workflow size setting in /config. It is not a hard cap, but it sends size guidance to Claude when Claude writes workflows: fewer than 5 agents for small, fewer than 15 for medium, fewer than 50 for large, or no guidance with unrestricted.
That matters for teams already using workflows for larger code reviews, migrations or research. You do not have to choose between "no agent orchestration" and "let everything loose". You can start with a size that fits the workflow, inspect the result, and only increase it when the receipt shows that quality and cost hold up.
Source: Claude Code workflow documentation on Dynamic workflow size.
Traceability: the workflow runner gets its own OTel attributes
2.1.202 also adds workflow.run_id and workflow.name to OpenTelemetry data from agents spawned by a workflow. That makes it possible to reconstruct a run afterward in your own observability tool.
This is useful for organizations that want Claude to work more independently while still answering basic operational questions: which workflow started the job, which agents were involved, how much time and tokens were used, and where did the work stall? Claude Code's monitoring documentation already shows how OTel can export metrics, events and traces to your own backends. This release note makes the workflow connection more useful.
Source: Claude Code monitoring and OpenTelemetry and Claude Code v2.1.202 release notes.
Remote Control and MCP remove daily friction
The release note also includes several everyday fixes. Remote Control commands from mobile or web into an interactive session should no longer fail with Unknown command, and images or files sent without a caption should no longer be dropped. Remote Control means the Claude Code session runs locally on your machine, while web or mobile works as a remote window into that session.
MCP, the Model Context Protocol, is the standard that lets Claude Code connect to tools and data sources. In 2.1.202, one common configuration mistake gets a clearer message: if a server has url but no type, the error points toward "type": "http" instead of complaining about a missing command.
These are not boardroom headlines. But for a technical team, they mean fewer stops when an agent is steered from a phone, continues inside a local repo environment, or talks to an internal tool.
Source: Claude Code Remote Control documentation and Claude Code MCP documentation.
What Nordic teams can do with the signal
Treat 2.1.202 as a chance to make agent work more operational. Not bigger for the sake of it. More controllable.
- Choose a workflow size for each type of job: codebase review, document research, migration or test generation.
- Save a run receipt with workflow name, run ID, goal, size setting, key files or sources, decisions and open questions.
- Connect OTel to a backend you already use if agent work touches production, customer data or recurring delivery.
- Use scoped API keys, environment variables or secret managers for connections, and let approval gates stop changes that need a human decision.
The Hammer angle is Tool Forge: turn Claude Code into a governed workflow, not just a faster chat. Start with one focused workflow you can follow from prompt to receipt.
Try this prompt this week
Human step: Open a project where Claude Code 2.1.202 is available. Set Dynamic workflow size in /config to a level that fits the task, for example small for a first review. Also gather the link or export from your OTel tool if you already monitor Claude Code.
Read our Claude Code settings, workflow routines and latest run receipts.
Compare them with 2.1.202: Dynamic workflow size, workflow.run_id, workflow.name and the Remote Control fixes.
Propose a workflow routine for one recurring agent job.
State the recommended size, which OTel fields we should follow, when the agent should ask, and what the receipt should contain.
End with a first run we can test this week.
Good output should include:
- A concrete workflow, not a general AI policy.
- A recommended size level and why it fits.
- A short run receipt with
workflow.run_id, goal, status and next decision. - Clear points where human approval is needed before Claude changes anything important.
FAQ
What matters most in Claude Code 2.1.202?
Dynamic workflow size in /config and new OpenTelemetry attributes for workflow runs. Together, they make larger agent jobs easier to size and review.
Is Dynamic workflow size a hard agent cap?
No. Anthropic describes it as advisory size guidance sent to Claude when workflows are written. Runtime limits still apply separately.
When should a team care about workflow.run_id?
When Claude Code is used for recurring jobs, larger codebase reviews or work where you need to reconstruct which run did what afterward.
The Forge newsletter
Get new articles in your inbox
Pick the topics you care about. No noise, at most one email a week.
We follow GDPR. Unsubscribe anytime.