DEV Community: Pesimmoq

Migrating from Haiku 4.5 to Claude Haiku 5.5: 6 breaking changes and when the price goes up 5x

Pesimmoq — Mon, 26 Oct 2026 04:10:55 +0000

Claude Haiku 5.5 (claude-haiku-5-5) was released on October 7, 2026. It is the first Haiku with adaptive thinking and effort, has a 1M-token context window and 128K output, and its API shape now matches Opus 5.5 / Sonnet 5.5. Pricing is $0.10 / $0.50, one tenth of Haiku 4.5, but it is also the first Haiku where the price goes up 5x once the prompt exceeds 100K tokens.

Haiku 4.5 was the last generation that accepted budget_tokens, temperature, and prefill, so changing only model breaks more things than it does on the other 5.5 models. Based on the official migration guide (as of October 12, 2026), here are the 6 changes that return 400 and the things that change silently.

What I verified

On October 12, 2026, I checked items 1 and 2, plus the effort restriction on disabled, against the live API. All requests were short, with max_tokens: 64, and the three 400s are not billed.

1) thinking: {type: "enabled", budget_tokens: 2000}
   HTTP 400  "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

2) temperature: 0.2
   HTTP 400  `temperature` is deprecated for this model.

3) thinking: {type: "disabled"} + effort xhigh
   HTTP 400  output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking.

4) thinking: {type: "disabled"} + effort low
   HTTP 200  stop_reason=end_turn  content=['text']  input_tokens=15  output_tokens=3  thinking_tokens=0

Case 4 also shows that disabled is accepted with low, and that usage.output_tokens_details.thinking_tokens comes back as 0. For the other items (prefill, computer_20250124, history edits, the organization boundary), I am relying on the official migration guide and did not test them against the live API.

In my own code, the only place that used Haiku 4.5 was one worker in a crawling agent. It passed neither thinking nor temperature, so changing the model ID was all it needed.

6 changes that return 400

1. `budget_tokens` returns 400

# Haiku 4.5
thinking={"type": "enabled", "budget_tokens": 8000}

# Haiku 5.5
thinking={"type": "adaptive"}, output_config={"effort": "medium"}

Thinking amount is controlled by effort (low to max). The default is medium. thinking: {"type": "disabled"} turns thinking off, but it works only with high or below; combining it with xhigh / max returns 400. While thinking is disabled, changing effort per message also returns 400.

2. `temperature` / `top_p` / `top_k` return 400

Any non-default value returns 400. Remove them and steer with the prompt instead.

3. A trailing assistant turn (prefill) returns 400

End messages with a user turn. If you used prefill to force JSON, switch to structured outputs (output_config.format). Note that Haiku 5.5 on Amazon Bedrock has neither structured outputs nor strict. On Bedrock, specify the format in the prompt and validate the output yourself.

4. `computer_20250124` returns 400 on every platform

On the Claude API and Google Cloud, switch to computer_toolset_20260801 (no beta header needed). On Amazon Bedrock, switch to computer_20251124 (computer-use-2025-11-24). Remove the computer-use-2025-01-24 header. The browser tool (browser_toolset_20260801) is newly available on the Claude API and Google Cloud.

5. Editing conversation history returns 400

This check did not exist on Haiku 4.5. If you change system, tools, or earlier turns and then send thinking blocks back, you get 400. The check is on by default for accounts created on or after August 31, 2026; for older accounts it applies only when you send prefix_mismatch_behavior. Keep history append-only, and make instruction changes with a mid-conversation role: "system" message. I covered the details in a separate article (Invalid signature in thinking block, in Japanese).

6. Thinking blocks can only be read by the organization that created them

If you send them from a different organization, they are silently dropped without an error, and the model answers without that reasoning. A service that carries conversations for multiple customers in one store should replay each conversation in the organization that created it.

What changes without an error

Thinking is on by default. Code that never set thinking will start thinking on Haiku 5.5. Because max_tokens is a cap on thinking plus the answer combined, a small value can be used up by the thinking block alone and leave the text empty. Select the block by type, not content[0].text. The default for display is omitted.

Tokens increase by about 30%. This is the same new tokenizer as 4.7 and later. Images also use the high-resolution tier (about 2.5x for 2000x1500). Re-measure with count_tokens.

Thinking blocks from every turn stay in the input. Haiku 4.5 kept only the previous turn's. Multi-turn input grows by more than 30%. To remove them, use thinking block clearing in context editing (deleting them yourself triggers item 5).

The minimum cacheable prompt is 512 tokens (4,096 on 4.5). Short prompts you had given up on caching now work.

Refusals were added. cyber / frontier_llm / bio / general_harms. You get HTTP 200 with stop_reason: "refusal". There is no server-side fallback, so handle it yourself. Resending usually gets refused again.

Priority Tier is not supported. Context-awareness tags are also not injected (use task budgets for budgeting).

Forced tool_choice still works. Unlike Opus 5.5 / Sonnet 5.5, it does not return 400.

When the price goes up 5x

Prompt length	Input	Output	Cache read	Batch
100K tokens or less	$0.10	$0.50	$0.01	$0.05 / $0.25
Over 100K tokens	$0.50	$2.50	$0.05	$0.25 / $1.25

"Prompt length" is the total input tokens of a single request, including cache reads and cache writes. Even if caching makes the request cheaper, once the total crosses the threshold that request is billed at the higher rate. The decision is made per request, and earlier requests are not re-billed.

So an agent that runs a long conversation on Haiku 5.5 needs to either shrink it with compaction as input approaches 100K tokens, or compare against Sonnet 5.5 ($2 / $10), whose price does not depend on length. Haiku 5.5 above 100K tokens ($0.50 / $2.50) is still 1/4 of Sonnet 5.5, so it is often still cheaper, but an estimate built on "Haiku is 1/20" will be off.

Where to start with effort

The official starting points: medium for most work (including agentic coding); low for chat, short tool tasks, and simple high-volume processing; high for knowledge work, long agentic work, and strict instruction following. At low, long agentic tasks more often skip searches, stop early, or skip checks. Asking in the prompt to "answer directly" does not reduce thinking; lower the effort instead.

If you give the model a search tool, put today's date in the system prompt so it answers based on recent search results. Render it once at the start of the conversation and keep sending the same system. If the day rolls over, put the date in the latest turn.

Finding these statically

Before changing model, I updated a tool that lists the affected places as file:line. The check for Haiku 5.5 is --target haiku-5-5.

git clone https://github.com/volvox-ltd/claude5-migration-kit
python claude5-migration-kit/scan.py path/to/your/app --target haiku-5-5

Summary

#	Symptom	Fix
1	400 on `budget_tokens`	`adaptive` + `effort`
2	400 on `temperature`	Remove it
3	400 on prefill	Structured outputs (validate yourself on Bedrock)
4	400 on `computer_20250124`	New toolset; `computer_20251124` on Bedrock
5	400 on history edits	Append-only
6	Thinking vanishes across organizations	Replay in the creating organization

The Opus 5.5 / Sonnet 5.5 changes (no disabled, no forced tools, and so on) are covered in the Japanese article, which includes a section on those two models.

https://zenn.dev/persimmoq/articles/claude-opus-5-5-sonnet-5-5-breaking-changes

Official: https://platform.claude.com/docs/en/models/haiku-5-5/migration-guide / https://platform.claude.com/docs/en/about-claude/pricing

I wrote this with help from Claude, Anthropic's AI model. It drafted the post from the official Haiku 5.5 migration guide and pricing page, and I checked it before publishing.

LiteLLM 1.107.0 was malware. A 5-minute check for AI developers, and the one-line setting that would have skipped it

Pesimmoq — Mon, 26 Oct 2026 04:10:30 +0000

On October 21, 2026, a malicious litellm==1.107.0 was published to PyPI. It is the second compromise of the package this year, separate from the one in March. PyPI has removed it. The safe version is 1.106.2.

LiteLLM is the library many agents and proxies use to call Claude, GPT and other models through one interface. It often arrives as a dependency you never installed on purpose. And this payload goes after AI coding tool credentials by name: Claude, Cursor, Copilot, Gemini CLI, Codex CLI and others.

The best technical analysis so far is the write-up by GMO Flatt Security (in Japanese). This post summarizes it for an English-speaking audience and adds the part I couldn't find elsewhere: how to make your installer refuse brand-new releases.

https://blog.flatt.tech/entry/litellm_2nd_compromise

What happened

Times are UTC, from Flatt Security's timeline and PyPI's release metadata.

Time	Event
10-13 06:43	Attacker's GitHub account created
10-13 06:46	TLS certificate issued for the exfiltration domain `litellm[.]dev`
10-21 10:44	Legitimate 1.106.2 published
10-21 11:39	Malicious 1.107.0 published, about an hour later
10-21	PyPI removes 1.107.0

Three details matter.

The GitHub tag is clean. The malicious files exist only in the wheels on PyPI. Reading the source would not have caught it.
It runs every time Python starts, not just on import. The wheel drops a .pth file and a sitecustomize.py into site-packages. Python loads both automatically at startup, so any Python process in that environment triggers it, even one that never imports litellm.
It leaves a backdoor. A daemon fetches and executes remote code every hour, with the C2 domain read from a file on GitHub.

The legitimate 1.107.0rc1 and rc2 had been published days earlier, so 1.107.0 looked like the expected next release. Anyone who ran pip install -U litellm on October 21 is the most likely victim.

What it steals

Flatt Security lists 16 categories. The ones AI developers should care about most:

AI tool credentials: Claude, Cursor, Copilot, Gemini CLI, Codex CLI, Windsurf, Aider, OpenCode, Hugging Face tokens
Environment variables, including other processes' via /proc/*/environ. If you pass ANTHROPIC_API_KEY or OPENAI_API_KEY as env vars, assume they're gone
.env files and private key files
LiteLLM's own database, if you run the proxy: it queries the credentials table for your provider keys
SSH keys, AWS / GCP / Azure credentials, browser-saved passwords, shell history

On Claude Code specifically: per the official docs, credentials live in the macOS Keychain on macOS and in ~/.claude/.credentials.json on Linux and Windows. macOS also falls back to the file when the Keychain can't be written, for example over SSH. If you run Claude Code in CI or on a Linux box, treat that file as exposed.

The 5-minute check

I ran these on my own Mac. Nothing matched, but pip show alone would not have told me that.

1. Find every installed copy. pip show only checks the current environment. Search for the dist-info folder instead, which carries the version in its name and also catches copies inside uv tool and pipx environments.

find ~ -maxdepth 8 -type d -iname 'litellm-*.dist-info' 2>/dev/null

litellm-1.107.0.dist-info means that environment is infected.

2. Check lockfiles. A pinned 1.107.0 will reinfect whoever rebuilds the environment from an internal mirror or cache.

grep -rIl -i 'litellm' --include='requirements*.txt' --include='pyproject.toml' \
  --include='uv.lock' --include='poetry.lock' ~/code 2>/dev/null

3. Look for the markers.

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>&1
ps aux | grep -E 'cook|remote_code_loader' | grep -v grep

The first file means the data has already been sent. The lock file or a matching process means the backdoor is running. On macOS /tmp is cleared on reboot, so a missing marker is not proof of safety on its own. Combine it with step 1.

4. If you were hit, follow Flatt Security's removal steps, then rotate everything as if it was stolen. The AI-specific items people forget:

Revoke and reissue API keys in the Anthropic Console, OpenAI, Google AI Studio and any other provider
Claude Code: /logout, then /login. Do the same for Cursor, Codex and the rest
Every provider key stored in a LiteLLM proxy
Everything in your .env files
GitHub tokens, PyPI / npm tokens, SSH keys, cloud credentials

Also check each provider's usage page for traffic since October 21 that you don't recognize.

Don't install anything younger than 3 days

The malicious release was live for less than a day. Refusing releases that are only hours old would have skipped it entirely. Flatt Security's own registry proxy applies a 3-day quarantine, and its users were not affected. You can get the same effect with features already built into uv and pip.

uv: exclude-newer accepts a duration such as 24 hours, 1 week or 3 days, or an ISO 8601 duration such as P3D. It is compared against each file's upload time.

# pyproject.toml
[tool.uv]
exclude-newer = "3 days"

In a global ~/.config/uv/uv.toml, drop the [tool.uv] line and keep exclude-newer = "3 days".

pip: --uploaded-prior-to accepts a duration in days in the P3D form. It only works with indexes that expose upload times, which PyPI does.

pip install --uploaded-prior-to P3D litellm

# or make it the default
export PIP_UPLOADED_PRIOR_TO=P3D

If your pip doesn't recognize the option, upgrade pip.

The catch is urgent fixes. When a library ships a same-day security fix, you can't wait three days. uv lets you exempt single packages with exclude-newer-package:

[tool.uv]
exclude-newer = "3 days"
exclude-newer-package = { cryptography = false }

With pip, unset the variable for that one install. "Wait by default, opt out on purpose" leaves a trace in your shell history or commit when you skip the delay.

For Node.js, pnpm has a setting for the same purpose, minimumReleaseAge (https://pnpm.io/settings).

Summary

litellm==1.107.0 is malware. Use 1.106.2. The GitHub source was clean; only the PyPI wheels were poisoned.
It runs on every Python startup and targets AI tool credentials, environment variables, .env files and the LiteLLM proxy database.
Check for installed copies with find, not just pip show. Check lockfiles and the marker files.
If you were hit, rotate every key, including your model provider API keys.
Set exclude-newer = "3 days" in uv or PIP_UPLOADED_PRIOR_TO=P3D for pip, and exempt urgent fixes explicitly.

If you run Claude agents on Claude Managed Agents, vault credentials of type environment_variable sit in the sandbox only as opaque placeholders and are swapped for the real secret at egress, so a poisoned dependency that dumps environment variables gets the placeholder, not the key: https://platform.claude.com/docs/en/managed-agents/vaults

I write about Claude API changes as they ship. The English edition of my Claude 5 migration guide is on Gumroad: https://persimmoq.gumroad.com/l/claude-5-migration-guide

What shared hosting WordPress users can do about php2shell

Pesimmoq — Sun, 25 Oct 2026 04:48:00 +0000

On October 21, 2026, around 22:40 Japan time, fixes for two critical PHP vulnerabilities shipped, nicknamed "php2shell." Most of the writeups that followed assume you administer your own server: set this directive, restart these workers, update this proxy config. If you run WordPress on shared hosting, the kind where you don't get to edit php.ini and can't update the PHP binary yourself, none of that is actually available to you.

I run seven sites on shared hosting for a small company. This post sorts out, based on the official advisories and the hosting providers' own incident reports, what shared hosting users can do themselves, what they cannot do no matter what, and what just has to be waited out.

What happened

PHP's official announcement: https://www.php.net/ (security advisory for 2026-10-21)
Advisories: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
An alert from Japan's IPA (in Japanese): https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
A writeup from GMO Flatt Security (in Japanese): https://blog.flatt.tech/entry/php2shell

Two unauthenticated remote code execution vulnerabilities, CVSS v4.0 score 9.2. The flaw is in PHP itself, not in WordPress or Laravel code, so a well written application is not protected just because it's well written. The official advisory names mod_php as the highest risk, with PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed also affected. Fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and earlier are outside the official support window, so only a minimal fix is available for people who build PHP from source. Attacks were observed before the public disclosure: Cloudflare says it saw attack traffic on the morning of October 21.

Checking the claims that were circulating

Claim	Verdict	Evidence
PHP powers 80% of the web	Overstated	W3Techs puts server-side language share at 69.3% among sites where it's known. Wiz, who discovered the bug, says "70%"
The real danger starts right after the patch ships (a 1-day attack)	Correct	True in general, and in this case attacks started even before disclosure
AI can reverse engineer an exploit in minutes	Overstated	Wiz wrote that "a frontier AI model" built exploit code for multiple applications "in a few hours," not minutes
CVSS 10.0	Wrong	The official score is 9.2. A member of the PHP security team corrected an earlier 10.0 figure that had leaked out
Setting `session.upload_progress.enabled=0` fixes it	Only partly	That mitigates one path in CVE-2026-109619. It does nothing for the other vulnerability, CVE-2026-109618

The last row matters most. The single mitigation that spread the widest before disclosure, the one-line fix, only covers part of one of the two CVEs. Alexandre Daubois, a member of the PHP security team, wrote a correction from the inside: https://daubois.dev/blog/cve-2026-109618-php2shell-rumors/

What shared hosting users cannot do

The official mitigations are mostly out of reach if you're on shared hosting. Setting memory_limit=-1 in a way the application can't override, the first mitigation the advisory lists, assumes you control the FPM pool configuration or can set php_admin_value in Apache, neither of which a shared hosting account gives you. Making session.upload_progress.enabled=0 actually take effect requires restarting every worker process, and the advisory explicitly says not to rely on ini_set() or .user.ini instead, both of which are the only levers a shared hosting user actually has. Limiting request size or multipart bodies at the web server or proxy level is also the hosting company's job, not something you can configure from a control panel. In practice, the only real fix for a shared hosting site is the hosting company updating PHP itself. There is no patch a user can apply.

At major Japanese shared hosting providers, the response to that constraint played out two different ways. One provider announced by 6:45 on October 22 that it had already applied the official patch to every server running PHP 8.2 through 8.5, was rolling out its own patches for older versions as they became ready, and had temporarily disabled its control panel and server panel as a precaution. Another provider went further: starting on October 21 it began emergency maintenance, and from around 3:09 on October 22 it took down public access to sites on some of its servers entirely, including sites that weren't even running a vulnerable PHP version, choosing to protect everyone quickly over patching server by server. According to its report (in Japanese, https://lolipop.jp/info/news/8239/), it restored access around 13:00 on October 22 after applying the official patches for 8.2 through 8.5, equivalent fixes for the already end-of-life 7.4 through 8.1, and its own custom patch for 5.3 through 7.3, and it disabled session.upload_progress across every version as a blanket measure. It said it had seen access attempts that looked like they were targeting the vulnerability, but had not confirmed any unauthorized access or data leak. WordPress core doesn't use PHP sessions, so that last change doesn't affect a stock WordPress install, but a custom upload form or a plugin that relies on sessions is worth checking.

What you can do

1. Move PHP to 8.2 or newer

This is the single most effective step. As providers' own announcements show, patches land for 8.2 through 8.5 first. A site still sitting on 7.4 or 8.0 is both last in line for a fix and on a version with no official patch at all. Check your PHP version setting in your hosting control panel; some providers let you set it per domain. If an older plugin assumes an old PHP version, as happened on one of my own sites with a plugin built for PHP 7.4, update the plugin before you switch.

2. Check for signs of compromise

A patch doesn't undo damage done before it was applied, and attacks were already happening before disclosure. For WordPress, check the following.

# After SSHing in and moving to the WordPress root
wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name '*.php'
find . -name '*.php' -mtime -3 -not -path './wp-content/cache/*'

Look for new administrator accounts (filter the users list by the administrator role), for .php files inside wp-content/uploads/ (a PHP file in an image directory is almost always a sign of compromise), for core or plugin files that don't match the official checksums, and for PHP files modified in the last few days. If you don't have SSH access, sorting the uploads directory by date in an FTP client already tells you a lot.

3. If you find anything, rotate every credential

Wiz's writeup notes that this vulnerability can, in some cases, expose other requests or the server's own memory, which can include passwords, auth tokens, and API keys. If you find any sign of compromise, rotate all of the following: your WordPress admin password, the database password and the authentication keys in wp-config.php (AUTH_KEY and the others; WordPress's generator is at https://api.wordpress.org/secret-key/1.1/salt/), your server's FTP and SSH passwords, and any API keys for external services your site uses, such as payment processors, email delivery, or Google. Even without a confirmed compromise, if you're storing API keys in wp-config.php or in plugin settings, rotating them is worth considering.

4. If you're already behind Cloudflare, you're covered

Cloudflare says WAF customers, including on the free plan, have been protected by default since 3:02 UTC on October 21 (https://blog.cloudflare.com/php-vulnerabilities-waf-protection/), as long as your DNS is proxied through Cloudflare. That doesn't replace updating PHP.

What you don't need to do

Update WordPress core or plugins expecting that to fix this. The flaw is in PHP itself, so a fully updated WordPress install is still vulnerable. Keeping WordPress updated is good practice regardless, just not a fix for this issue.
Add session.upload_progress.enabled = 0 to .htaccess or .user.ini. The official advisory explicitly says not to rely on .user.ini for this, and believing it worked when it didn't is worse than not trying at all.
Panic and delete the site. Checking for compromise and rotating credentials comes first. Deleting the site destroys the evidence you'd need to investigate.

Takeaways

php2shell is a flaw in PHP itself, so on shared hosting the only real fix is the hosting company updating PHP, something users cannot do on their own. What a user can do comes down to three things: move to PHP 8.2 or newer, check for signs of compromise, and rotate every credential if any sign turns up. The widely shared one-line fix only covers part of one of the two CVEs, and writing it into .user.ini doesn't even apply it. Hosting providers were updating their advisories every few hours, so check your own provider's announcement rather than anyone else's.

This post was drafted on the morning of October 22 and updated on October 23 after one provider's incident report. Response details from hosting companies keep changing, so treat official advisories as the current source, not this post.

I wrote this with help from Claude, Anthropic's AI model. It drafted the post from PHP's own security advisories, the GHSA entries for CVE-2026-109618 and CVE-2026-109619, and the hosting providers' incident reports, and I reviewed it before publishing.

LiteLLM 1.107.0 was malware. A 5-minute check for AI developers, and the one-line setting that would have skipped it

Pesimmoq — Thu, 22 Oct 2026 23:51:57 +0000

On October 21, 2026, someone published a malicious litellm==1.107.0 to PyPI. It's the second time the package has been compromised this year, and it's unrelated to the March incident. PyPI has pulled it, and 1.106.2 is safe.

If you build with LLMs, there's a decent chance LiteLLM is somewhere on your machine even if you never installed it yourself. A lot of agents and proxies use it to talk to Claude, GPT and the rest through one interface. That's what makes this one nasty: the payload goes looking for AI coding tool credentials by name, including Claude, Cursor, Copilot, Gemini CLI and Codex CLI.

GMO Flatt Security published the most detailed analysis I've seen, but it's in Japanese. This post summarizes it in English and adds something I couldn't find in any of the write-ups: how to tell uv and pip to refuse brand-new releases.

https://blog.flatt.tech/entry/litellm_2nd_compromise

What happened

The timeline below comes from Flatt Security's analysis and PyPI's release metadata. Times are UTC.

Time	Event
10-13 06:43	Attacker's GitHub account created
10-13 06:46	TLS certificate issued for the exfiltration domain `litellm[.]dev`
10-21 10:44	Legitimate 1.106.2 published
10-21 11:39	Malicious 1.107.0 published, about an hour later
10-21	PyPI removes 1.107.0

The v1.107.0 tag on GitHub is clean. The malicious files only exist in the wheels uploaded to PyPI, so reading the source wouldn't have saved you.

It also doesn't wait for you to import anything. The wheel drops a .pth file and a sitecustomize.py into site-packages, and Python loads both on every startup. Any Python process in that environment sets it off. On top of the data theft, it starts a daemon that pulls and runs remote code once an hour, with the server address read from a file on GitHub.

The timing was clever, too. 1.107.0rc1 and rc2 had gone out normally a few days earlier, so a final 1.107.0 was exactly what you'd expect next. If you ran pip install -U litellm on October 21, you're the person this was aimed at.

What it steals

Flatt Security counted 16 categories of data. For AI developers, the AI tool credentials are the obvious worry: Claude, Cursor, Copilot, Gemini CLI, Codex CLI, Windsurf, Aider, OpenCode and Hugging Face tokens are all on the list.

Environment variables are the less obvious one. It reads its own and other processes' through /proc/*/environ, so if you pass ANTHROPIC_API_KEY or OPENAI_API_KEY that way, assume they've been taken. It also collects .env files and private key files, and if you run the LiteLLM proxy, it queries the proxy's database for the provider keys stored there. SSH keys, cloud credentials, browser passwords and shell history round it out.

A note on Claude Code. According to the official docs, it keeps credentials in the Keychain on macOS and in ~/.claude/.credentials.json on Linux and Windows. macOS falls back to that file when the Keychain isn't writable, which happens over SSH. If you run Claude Code in CI or on a Linux server, treat that file as exposed.

The 5-minute check

I ran all of this on my own Mac. Nothing turned up, but I wouldn't have known that from pip show alone, because it only looks at whichever environment is active.

Searching for the dist-info folder works better. The version is in the folder name, and it finds copies tucked inside uv tool and pipx environments as well.

find ~ -maxdepth 8 -type d -iname 'litellm-*.dist-info' 2>/dev/null

If you see litellm-1.107.0.dist-info, that environment is infected.

Next, check your lockfiles. A pinned 1.107.0 will infect whoever rebuilds that environment from an internal mirror or a cache.

grep -rIl -i 'litellm' --include='requirements*.txt' --include='pyproject.toml' \
  --include='uv.lock' --include='poetry.lock' ~/code 2>/dev/null

Then look for the files the malware leaves behind.

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>&1
ps aux | grep -E 'cook|remote_code_loader' | grep -v grep

The first file means your data has already been sent. The lock file, or a matching process, means the backdoor is running. Keep in mind that macOS clears /tmp on reboot, so not finding them doesn't prove much by itself. Read it together with the find result.

If you were hit, follow Flatt Security's removal steps and then rotate everything as if it were stolen. The ones I'd expect AI developers to forget are their model provider API keys (Anthropic Console, OpenAI, Google AI Studio), their Claude Code login (/logout, then /login, and the same for Cursor or Codex), and every key stored in a LiteLLM proxy. After that come the usual suspects: .env contents, GitHub and package registry tokens, SSH keys and cloud credentials. It's also worth checking each provider's usage page for anything since October 21 you don't recognize.

Don't install anything younger than 3 days

The bad release was up for less than a day. If your installer had simply ignored anything only a few hours old, you'd have skipped it without noticing. Flatt Security runs a registry proxy with a 3-day quarantine, and its users weren't affected. You don't need a proxy to get the same effect, though. Both uv and pip can do it today.

In uv, exclude-newer takes a duration like 24 hours, 1 week or 3 days, or an ISO 8601 duration like P3D, and compares it against each file's upload time.

# pyproject.toml
[tool.uv]
exclude-newer = "3 days"

For a global ~/.config/uv/uv.toml, leave out the [tool.uv] line.

In pip, the option is --uploaded-prior-to, and it takes days in the P3D form. It only works with indexes that report upload times, which PyPI does. If your pip doesn't know the option, upgrade it.

pip install --uploaded-prior-to P3D litellm

# or make it the default
export PIP_UPLOADED_PRIOR_TO=P3D

The downside is that urgent fixes get held back too, and you can't sit on a same-day security patch for three days. uv handles this with exclude-newer-package, which lets you exempt a single package.

[tool.uv]
exclude-newer = "3 days"
exclude-newer-package = { cryptography = false }

With pip, unset the variable for that one install. I like this split because skipping the delay becomes a deliberate act that shows up in your shell history or a commit, rather than something that happens by default.

If you're on Node.js, pnpm has a setting for the same thing called minimumReleaseAge (https://pnpm.io/settings).

Wrapping up

litellm==1.107.0 is malware, and 1.106.2 is the version to use. Search for installed copies with find instead of trusting pip show, check your lockfiles, and rotate your provider API keys along with everything else if you find it. Going forward, a 3-day delay in uv or pip would have kept this release off your machine.

One more thing if you run Claude agents on Claude Managed Agents. Vault credentials of type environment_variable only exist inside the sandbox as placeholders and get swapped for the real secret on the way out, so a poisoned dependency that dumps environment variables ends up with the placeholder. The docs are here: https://platform.claude.com/docs/en/managed-agents/vaults

I wrote this with help from Claude, Anthropic's AI model. It drafted the post from Flatt Security's analysis and the uv, pip and Claude Code docs. I ran the checks on my own machine and reviewed everything before publishing.

I built an AI coworker that works while I sleep, using nothing but Claude Code

Pesimmoq — Fri, 16 Oct 2026 03:06:05 +0000

Claude Code has a feature called routines: a cloud session that starts on a cron schedule, clones a GitHub repository, uses the MCP connectors you've attached on claude.ai (Slack, Gmail), and exits. No server, no extra tooling.

I used it to build a watcher that, every morning at 09:00 JST, reads 12 pages of Anthropic's official docs, diffs them against yesterday, posts a Japanese summary to Slack, and, when a change affects my books, pushes a draft article to GitHub. The motivation was embarrassing: I write guides about the Claude API, and I missed the Haiku 5.5 launch for five days. A local script had been posting "changed" notices to Slack every day. Nobody was reading them.

Everything below is as of October 16, 2026. Routines are moving fast; check the official docs for the current shape.

What a routine is

A 5-field cron expression (UTC) or a one-time timestamp starts a cloud session. Minimum interval is one hour.
The session starts with your GitHub repository cloned. It cannot see your local files, local environment variables, or local services.
It can use MCP connectors attached on claude.ai (Slack, Gmail, ...). MCP servers configured only in Claude Code are not available.
Model, allowed tools, and the prompt go in one JSON object. The prompt is read from scratch every run, so it has to be self-contained.
Create, update, run-now, and run logs are available through an API (from inside Claude Code, the RemoteTrigger tool). Deleting is web-only.

What I built

volvox-ltd/claude-docs-watch (private)
├── pages.json        # 12 official pages (the .md versions on platform.claude.com)
├── watch.py          # fetch -> compare with state/ -> diffs/<date>/ + result.json (stdlib only)
├── state/            # yesterday's text
├── diffs/            # unified diffs per day
├── drafts/           # article drafts the routine writes when a change matters
├── log/              # daily summaries
└── ROUTINE_PROMPT.md # the instructions the routine receives

The design decision that matters: Python finds the diff; the model only judges and writes. Asking a model to "read these 12 pages and tell me what changed" means reading ~300k characters every morning and missing things. watch.py produces the diff files; the model reads only those.

The routine definition

{
  "name": "claude-docs-watch 09:00 JST",
  "cron_expression": "0 0 * * *",
  "enabled": true,
  "job_config": {"ccr": {
    "environment_id": "env_…",
    "session_context": {
      "model": "claude-sonnet-5-5",
      "sources": [{"git_repository": {"url": "https://github.com/volvox-ltd/claude-docs-watch"}}],
      "allowed_tools": ["Bash", "Read", "Write", "Edit", "Glob", "Grep",
                        "mcp__Slack__slack_send_message", "mcp__Slack__slack_search_channels"]},
    "events": [{"data": {"uuid": "…", "session_id": "", "type": "user", "parent_tool_use_id": null,
                "message": {"role": "user", "content": "<the prompt below>"}}}]}},
  "mcp_connections": [{"connector_uuid": "…", "name": "Slack", "url": "https://mcp.slack.com/mcp"}]
}

Sonnet 5.5 is plenty: the daily job is "read a diff and summarize it".

The prompt

The repository https://github.com/volvox-ltd/claude-docs-watch is already cloned in your
working directory (branch main). Configure git with user.name 'docs-watch-bot' and
user.email 'contact@volvox-ltd.com' before committing.

You are the daily docs watcher for persimmoq, an author of Claude API guides. You run
inside a fresh clone of this repository every morning. Work in Japanese for all
human-facing text.

Do these steps in order.

1. Run `git pull --rebase origin main` first (the checkout can be stale). Then run
   `python3 watch.py` from the repository root and read `result.json`.

2. If `changed` is empty and `errors` is empty: append one line `<date> no changes` to
   `log/<YYYY-MM>.md`, commit it, push to `main`, and send ONE short Slack message to the
   private channel #mail (channel_id C0BEY8JUCDR). Then stop.

3. If there are changes: read every file listed under `changed[].diff`. Ignore pure
   formatting changes. For the substantive changes, write a summary with, per page: the
   page key, 1–3 sentences on what changed, and a judgement on whether it affects the
   author's published material (the books on Claude 5 migration and on Managed Agents,
   and the articles on those topics). Mark each page as affected / not affected / check.

4. Write that summary to `log/<YYYY-MM>.md` under a heading `## <date>` and post the same
   summary to the Slack channel. Keep it under 2,000 characters; link each page URL.

5. If at least one page is affected and the change is a new model, a new price, a new
   breaking change, a deprecation/retirement, or a new Managed Agents feature: write ONE
   draft article in `drafts/<date>-<short-slug>.md` (front matter with published: false),
   quoting the exact new text from the diff where it matters, linking the official page,
   and ending with a section "What I verified" containing only a placeholder for the author
   to fill in after testing against the live API. Do not invent behavior that the
   documentation does not state. Do not claim anything was tested.

6. `git add -A`, commit, push to `main`. If the push fails, retry once after `git pull --rebase`.

7. If any `errors` are present, mention them at the end of the Slack message.

Never publish anything outside this repository. Never edit files under `state/` by hand.

Step 5 is the point. The coworker drafts; it never publishes. The draft ends with an empty "What I verified" section that a human fills in after running the real API. The prompt says "do not claim anything was tested" for the same reason.

What happened on the first two runs (October 16)

Run 1 (23 seconds, 8 turns). Sandbox allocated, repo cloned, watch.py found no changes, log appended, push succeeded, Slack post failed with channel_not_found. The agent searched for the channel, found nothing, and fell back to a mobile push notification. Cause: the Slack connector on claude.ai was attached to a different workspace. I reconnected it and put the channel ID in the prompt.

Run 2 (51 seconds, 9 turns). Slack post succeeded. Then the push was rejected: the sandbox's checkout predated run 1's commit. The agent ran git pull --rebase, saw its own commit was a duplicate line, discarded it, and exited cleanly. Reasonable, but I added git pull --rebase as step 1 so it doesn't happen every morning.

The run log is available from the API with timestamps for every tool call, error, and the final message. You can read everything the coworker did while you were asleep.

Three things that broke

The GitHub App must be installed on the organization. Connecting GitHub on claude.ai was not enough for a private repo under an org; creating the routine failed with repo_access_denied until I installed github.com/apps/claude on the org and granted the repo.
A connector points at one workspace. With several Slack workspaces, it was attached to the wrong one. Use channel IDs, not names.
The checkout is not always fresh. A routine that pushes should pull first.

Cost and limits

Runs use the allowance of my Claude subscription plan; I have seen no separate API charges. A no-change run is a few thousand tokens. Check the pricing page for your plan.
Minimum interval one hour. Not a tool for "poll every five minutes".
No access to your local machine. Anything the job needs must be in the repo or reachable from the cloud.
Deletion is web-only.

Three ways to build the same thing

	Claude Code routine	Managed Agents	cron + API on your machine
Runs on	Anthropic's cloud	Anthropic's cloud	your machine
Setup	one JSON	Agent + Deployment	plist/crontab + script
Billing	plan allowance	tokens + session time ($0.08/h)	API tokens
Best for	periodic jobs that fit in a repo + connectors	long-running agents that need a hosted toolbox	jobs that need local files or local credentials
Notify via	connectors (Slack/Gmail), push	webhooks	your own

I use all three. This watcher is a routine; my production agent platform is Managed Agents; the weekly Search Console report, which needs local OAuth tokens, stays on launchd.

Takeaways

A Claude Code routine gives you a cron'd cloud agent with a repo and Slack, with no infrastructure.
Split the roles: Python detects, the model judges and writes, a human publishes.
What breaks is permissions and connections, not the prompt.

I wrote this with help from Claude, Anthropic's AI model. The routine, the repository and the problems described are my own setup; Claude drafted the text from my notes and I checked it before publishing.

Claude Opus 5.5 / Sonnet 5.5: 5 settings that return 400 when you only change the model name

Pesimmoq — Thu, 15 Oct 2026 01:47:16 +0000

Claude Opus 5.5 shipped on September 22, 2026 and Claude Sonnet 5.5 on September 28. If you take code that runs on Opus 5 or Sonnet 5 and change only the model string, one of these five settings will return an HTTP 400. All five are in Anthropic's official migration guides; I reproduced the first one against the live API on October 6 and pasted the exact responses below.

A static scanner that finds these in your code (file:line) is open source: claude5-migration-kit.

python scan.py path/to/your/app --target opus-5-5
python scan.py path/to/your/app --target sonnet-5-5

1. `thinking: {"type": "disabled"}` returns 400

Opus 5.5 cannot turn thinking off. On Opus 5 you could send disabled at high effort or below. On Opus 5.5, both disabled and enabled + budget_tokens are rejected at every effort level:

"thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

Omit thinking (same as adaptive) and lower output_config.effort where you used to disable thinking.

Sonnet 5.5 replaces disabled with between_tools. It is the lowest thinking setting: no up-front thinking, only the short notes between tool calls.

To turn thinking off on this model, send "thinking": {"type": "between_tools"} instead of {"type": "disabled"}. The model does not think before responding. The short updates it writes between tool calls come back as thinking blocks.

# Sonnet 5
client.messages.create(model="claude-sonnet-5", max_tokens=16000,
                       thinking={"type": "disabled"}, output_config={"effort": "xhigh"}, messages=[...])

# Sonnet 5.5
client.messages.create(model="claude-sonnet-5-5", max_tokens=16000,
                       thinking={"type": "between_tools"}, output_config={"effort": "high"}, messages=[...])

between_tools works only at high effort or below (400 with xhigh / max), takes no other field (display, budget_tokens and block_binding are 400), and cannot be combined with per-message effort changes. In a request without tools it answers without thinking at all, so move multi-step reasoning tasks back to adaptive.

Both responses above are verbatim from the API (max_tokens: 64, no charge for a 400).

2. Forced `tool_choice` returns 400

{"type": "any"} and {"type": "tool", "name": ...} are rejected on both models, including on the token-counting endpoint:

tool_choice: type "tool" and "any" are not supported for this model.

Use tool_choice: {"type": "auto"}, mark the tool strict: true so the input matches the schema, and say in the prompt when to call it. Strict tools are capped at 20 per request and need additionalProperties: false on every object. If you only wanted JSON, use structured outputs (output_config.format) instead of a tool. On Amazon Bedrock, Opus 5.5 and Sonnet 5.5 have no structured outputs (strict included): send auto, name the tool in the prompt, and validate the input yourself.

3. `computer_20251124` returns 400 on the Claude API and Google Cloud

Declare computer use as the computer_toolset_20260801 toolset (no beta header). Sonnet 5.5 also rejects computer_20250124 on every platform. Amazon Bedrock keeps computer_20251124. The fine-grained-tool-streaming-2025-05-14 header is a 400 next to a toolset entry; set eager_input_streaming: true on the tools that need it.

4. Editing conversation history returns 400 (or drops the thinking)

The preserved-thinking check that Fable 5.1 introduced now applies to both models: thinking blocks are bound to the model and to the conversation prefix. Editing system, tools or earlier turns and then sending the thinking blocks back is a 400 on accounts created on or after August 31, 2026 (enforced by default), or a dropped block otherwise.

Keep history append-only. Change instructions with a mid-conversation {"role": "system", ...} message.
Change tools with tool_addition / tool_removal; with the inline-tools-2026-09-15 beta you can include full definitions.
To shrink history, use on-demand compaction (compact-2026-09-04): you receive a signed summary block and send it first on the next request.
Sonnet 5.5 thinking blocks are also account-bound: sent from another organization they are silently dropped.

5. Sonnet 5.5 rejects Opus 4.x / Sonnet 5 as advisors

With a Sonnet 5.5 executor, the advisor must be Opus 5, Opus 5.5, Sonnet 5.5, Fable 5 / 5.1 or Mythos 5 / 5.1. Opus 4.8 / 4.7 / 4.6, Sonnet 5, Sonnet 4.6 and Haiku 5.5 return 400. Advice comes back encrypted as advisor_redacted_result.

Changes that don't fail, but matter

Opus 5.5 defaults to effort: medium (Opus 5: high). Carry over a request without effort and it runs one level lower. Anthropic reports that 5.5 at medium matches or beats Opus 5 at high; start there and sweep.
Sonnet 5.5 effort levels are recalibrated. Start coding agents at medium, general work at high, max_tokens 128K with streaming.
Text between tool calls now arrives in thinking blocks, empty at the default display. A UI that streams progress notes goes quiet with no error. Use display: "updates" (beta header thinking-display-updates-2026-08-18).
More refusal categories. Opus 5.5 adds bio; Sonnet 5.5 has cyber, bio, frontier_llm, reasoning_extraction, general_harms. Server-side fallback only retries cyber and frontier_llm on Sonnet 5. Since September 24, refusals before any output in bio / frontier_llm / reasoning_extraction are billed.
Prompt cache minimum is 512 tokens (Sonnet 5: 1,024). Sonnet 5.5 cache reads dropped to $0.10/MTok on October 7 (0.05x).
Priority Tier is not supported on Opus 5.5.
Sonnet 4.5 retires on November 30, 2026. Replacement: Sonnet 5.5.

Summary

#	Symptom	Fix
1	`disabled` → 400	Opus 5.5: omit + lower effort. Sonnet 5.5: `between_tools` (≤ `high`)
2	`tool_choice: any` → 400	`auto` + `strict` + name the tool in the prompt
3	`computer_20251124` → 400	`computer_toolset_20260801`
4	edited history → 400	append-only; system messages, tool_addition, compaction
5	advisor → 400	Opus 5 / 5.5, Sonnet 5.5, Fable

The seven things that already broke when moving from 4.x to Opus 5 / Sonnet 5 (temperature, budget_tokens, prefill, max_tokens eaten by thinking, content[0] on refusals, empty thinking text, the ~30% tokenizer increase) still apply.

Official sources: Opus 5.5 migration guide · Sonnet 5.5 migration guide

I wrote this with help from Claude, Anthropic's AI model. It drafted the post from the official migration guides and my notes. I checked every 400 against the live API before publishing.

DEV Community: Pesimmoq

Migrating from Haiku 4.5 to Claude Haiku 5.5: 6 breaking changes and when the price goes up 5x

What I verified

6 changes that return 400

1. budget_tokens returns 400

2. temperature / top_p / top_k return 400

3. A trailing assistant turn (prefill) returns 400

4. computer_20250124 returns 400 on every platform

5. Editing conversation history returns 400

6. Thinking blocks can only be read by the organization that created them

What changes without an error

When the price goes up 5x

Where to start with effort

Finding these statically

Summary

LiteLLM 1.107.0 was malware. A 5-minute check for AI developers, and the one-line setting that would have skipped it

What happened

What it steals

The 5-minute check

Don't install anything younger than 3 days

Summary

What shared hosting WordPress users can do about php2shell

What happened

Checking the claims that were circulating

What shared hosting users cannot do

What you can do

1. Move PHP to 8.2 or newer

2. Check for signs of compromise

3. If you find anything, rotate every credential

4. If you're already behind Cloudflare, you're covered

What you don't need to do

Takeaways

LiteLLM 1.107.0 was malware. A 5-minute check for AI developers, and the one-line setting that would have skipped it

What happened

What it steals

The 5-minute check

Don't install anything younger than 3 days

Wrapping up

I built an AI coworker that works while I sleep, using nothing but Claude Code

What a routine is

What I built

The routine definition

The prompt

What happened on the first two runs (October 16)

Three things that broke

Cost and limits

Three ways to build the same thing

Takeaways

Claude Opus 5.5 / Sonnet 5.5: 5 settings that return 400 when you only change the model name

1. thinking: {"type": "disabled"} returns 400

2. Forced tool_choice returns 400

3. computer_20251124 returns 400 on the Claude API and Google Cloud

4. Editing conversation history returns 400 (or drops the thinking)

5. Sonnet 5.5 rejects Opus 4.x / Sonnet 5 as advisors

Changes that don't fail, but matter

Summary

1. `budget_tokens` returns 400

2. `temperature` / `top_p` / `top_k` return 400

4. `computer_20250124` returns 400 on every platform

1. `thinking: {"type": "disabled"}` returns 400

2. Forced `tool_choice` returns 400

3. `computer_20251124` returns 400 on the Claude API and Google Cloud