Rounds, launches, and benchmarks worth measuring yourself against.
Claude Haiku 5.5 launched with a 1M token window, and a migration that is not a model id swap
Models7 Oct
Anthropic launched Claude Haiku 5.5 (claude-haiku-5-5) on 7 October with a 1M token context window, 128K maximum output and adaptive thinking controlled by the effort parameter. The model id is fixed, with no date suffix and no alias. Compared with Haiku 4.5, a request now returns a 400 error if it sends manual thinking with budget_tokens, sets top_k at all or sets temperature or top_p to anything but their defaults, ends the messages with an assistant prefill even when thinking is off, or declares the computer_20250124 tool. Sending a thinking block back after changing the system prompt, the tools or earlier messages also returns a 400. Thinking text is omitted unless you set thinking.display to "summarized". The guide says Haiku 5.5 runs safety classifiers that can decline a request, that it has no server side fallback, and that Priority Tier is not supported.
So what
Treat this as a migration, not a model id swap. Search your code for budget_tokens, temperature, top_p, top_k and any request that ends on an assistant turn, because each one is now a hard failure rather than a quiet change. Select response content blocks by type, not by position, since a response can begin with a thinking block even when you never asked for thinking. Raise max_tokens, because thinking counts toward it and a small limit can stop after a thinking block with no text. Handle the refusal stop reason, and if you rely on Priority Tier for Haiku 4.5, plan that capacity separately. On Amazon Bedrock, structured outputs are not available for this model.
GPT-6.1 Sol got an Ultrafast mode at six times the standard price, with EU data residency that Astra Ultrafast lacks
Launch8 Oct
OpenAI added Ultrafast mode for GPT-6.1 Sol in the Responses API on 8 October. Setting service_tier to "ultrafast" on gpt-6.1-sol reduces the time between generated output tokens, and the changelog says it is available to all API users, subject to rate limits, "with global processing and US and EU data residency". The pricing page lists it at $12 input, $0.60 cached input and $60 output per million tokens for short context prompts, and $24, $1.20 and $90 for long context, against $2, $0.10 and $10 on standard. In issue 5 we reported that Ultrafast for GPT-6 Astra does not support EU or other regional inference residency. That is still what the changelog says for Astra, so the two modes differ. The pricing page also notes a 10 percent uplift on regional processing endpoints for models released on or after 5 March 2026.
So what
Ultrafast is a latency product priced like one. Six times the standard rate only makes sense where a person is waiting on each token, such as a live coding or voice surface, and not for background work, which belongs on standard, Batch or Flex. The pricing page lists Sol at $1 input and $5 output on both of those. If you held back from Ultrafast because of EU residency, the Sol mode removes that obstacle, but cost the EU path with the regional uplift included rather than at the headline rate.
Managed Agents can now write and run their own multi phase workflows, in beta
Tooling9 Oct
On 9 October Anthropic put dynamic workflows into beta for Claude Managed Agents. You enable them in the agent definition with multiagent set to {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}, under the managed-agents-2026-04-01 beta header. The documentation describes a workflow as "a program that runs many agents in phases and combines what they return", which the server runs in the background as a workflow run while the agent keeps working or ends its turn. With the multiagent_20261001 type, workflows and subagents are both enabled by default, and so are inline agents that a workflow defines itself. You can list up to 20 predefined agents for a workflow to use. Separately, on 14 October Anthropic made Managed Agents scheduled deployments available on Claude Platform on AWS.
So what
The risk is spend you did not decide on. Choosing the multiagent_20261001 type turns workflows on by default, and a workflow can fan out to many agents, so if you only want delegation, set workflows to {"type": "disabled"} explicitly. Set a session budget when you create the session, because the documentation says you cannot add one to an existing session, and runs pause when the budget is reached. Tell the agent in its system prompt when a run is warranted, as the documentation suggests, and keep every listed agent on the same inference geography as the main agent, which the documentation requires.
Claude OpenTelemetry export is in beta, and it keeps prompts out of your traces unless you switch them on
Tooling14 Oct
On 14 October Anthropic released OpenTelemetry export for the Claude API in beta, covering Messages API requests, tool uses and Managed Agents sessions. The Claude SDK emits spans in Python, TypeScript, C#, Go, Java, PHP and Ruby, and API tracing is set up as a destination in the Claude Console, which needs Admin permission. The default content mode is metadata only, with spans holding identifiers, timing, status and token counts. Full content mode adds prompts and responses, up to 0.75 MB per span by default before the content is truncated and anthropic.content.truncated is set to true. The documentation says span delivery is best effort and that exported spans are not a complete record of API usage.
So what
Start in metadata only mode, which is the default, and make switching to full content a decision rather than an accident: prompts and responses will sit in your observability vendor under its own access and retention settings, which the documentation tells you to check. Do not build billing or quota enforcement on spans, because delivery is best effort and the documentation points to the Usage API for that. And if you add up tokens from traces, sum spans from one source only. The SDK and the API both emit an anthropic.messages.create span for the same request, and adding both double counts.
GitHub Actions workflow lockfiles are in public preview, so a moved tag can no longer change what your workflow runs
Tooling14 Oct
GitHub put Actions workflow dependency lockfiles into public preview on 14 October for GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free plans. The changelog says "Tags and branches can move after you review a workflow, so a later run might execute different code". A lockfile records the exact commits for actions and their transitive dependencies, including reusable workflows, in .github/workflows/actions.lock, and you create and maintain it with the gh actions-lock extension for the GitHub CLI. Once a workflow is onboarded, Actions requires every dependency to be in the lockfile and runs the recorded commit even if a tag or branch moves. A Require lockfile policy is also in public preview for enterprise, organization and repository administrators, and Dependabot regenerates the matching lockfile entry in the same pull request when it updates an action in an onboarded workflow. GitHub is clear that locking "does not determine whether the dependency itself is safe".
So what
Onboard your deploy and release workflows first, because they hold the production secrets and a moved tag does the most damage there. Locking pins what you reviewed, it does not review it, so read each action before you lock it. It also does nothing about a malicious install step inside a workflow, which is the tensorlake case in this issue, so it sits alongside ignore-scripts and a careful look at new dependencies rather than replacing them.
GitHub now blocks Anthropic API keys on push by default, for every repository with secret scanning on, including free public ones
Security13 Oct
GitHub announced on 13 October that secret scanning detects two new Anthropic secret types, anthropic_service_api_key and anthropic_user_api_key, and that both are included in push protection by default. The changelog says repositories with secret scanning enabled, "including free public repositories", will have commits containing these secrets automatically blocked. It also adds Salesforce as a secret scanning partner with the type salesforce_marketing_cloud_api_oauth2_token, and a Cloudsmith detector, cloudsmith_api_key. Under the partner program, secrets found in public repositories are reported to the issuer so it can revoke or rotate them.
So what
A blocked push is a good failure, but it only protects repositories where secret scanning is on, so check that setting on everything you own rather than assuming a default. Tell your team what the error means before it appears in a deploy, because scripts and CI jobs that commit generated files will hit it first. The block applies to new pushes, so a key that is already in your history needs to be found and rotated by you. Better still, keep Anthropic keys out of client code and committed .env files in the first place.