https://docs.all-hands.dev/ logo
Join Slack
Powered by
:robot_face: LLM model list update ā€” 2026-10-17 U...
# proj-agent
f
šŸ¤– LLM model list update ā€” 2026-10-17 Updated existing PR with newly detected models: ā€¢ https://github.com/OpenHands/software-agent-sdk/pull/4988 ā€” Added glm-5.3-flashx (Zhipu GLM), qwen3.8-omni-flash (Alibaba Qwen), nemotron-3.5-super-vl-120b-a12b (NVIDIA) _Rebased the rolling PR onto current main and re-confirmed every entry via LiteLLM model_cost + OpenRouter/NVIDIA. No-op for skipped models: glm-5.3-prime, qwen3.8-max-prime._ Generated by OpenHands AI on behalf of the user.
āœ… 1
c
@fresh-machine-37269 I just heard that Deepseek v4.1 Flash had an upgrade, a 1700 or something, not 1700, but some point model. Can you look on the internet find it? It's on OpenRouter too. Why hasn't been part of this update? detect the automation that runs this update and try to tell me why it didn't see it
šŸ‘€ 1
f
šŸ¤– On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/ā€¦
āœ… Done! Got it ā€” here's what I found. šŸ‘‡ The model you heard about It's the DeepSeek V4.1 Flash "1017" snapshot (Oct 17, 2026 ā€” that's the "1700 or something" you're thinking of). On OpenRouter it's 
deepseek/deepseek-v4.1-flash-1017
(canonical slug 
deepseek/deepseek-v4.1-flash-20261017
), listed today at 08:27 UTC, 1M context, text+image, served by DeepSeek under the 
deepseek-flash
API name. It sits alongside the existing 
deepseek/deepseek-v4.1-flash
and 
:batch
variants. The automation behind that update It's the "LLM Model List Update" automation in 
OpenHands/oss-agent-canvas
(
automations/llm-model-list-update-80cee119
). Cron 
0 9 * * 3,6
UTC (Wed + Sat), posts to #proj-agent, and maintains the rolling PR #4988 in 
OpenHands/software-agent-sdk
, editing 
openhands-sdk/openhands/sdk/llm/utils/verified_models.py
. Why it didn't see it ā€” it's structural, not a timing miss (the snapshot was live ~5Ā½ h before today's run): 1. Discovery source is LiteLLM 
model_cost
only. The registry has no 
deepseek/deepseek-v4.1-flash
entry, and no 
*1017*
key at all. The only v4.1-flash pricing entries live under other providers (
azure_ai/ā€¦
, 
fireworks_ai/deepseek-v4p1-flash
, 
baseten/ā€¦
, 
tencent/ā€¦
, 
prism/ā€¦
) ā€” and the DeepSeek scan only ever looks at keys starting with 
deepseek/
. 2. The filter is too narrow. DeepSeek matching is 
prefix: "deepseek/"
+ patterns 
deepseek-chat
, 
deepseek-v[34]
, 
deepseek-reasoner
. The one alias LiteLLM does carry, 
deepseek/deepseek-flash
ā€” which is exactly the API name OpenRouter says serves this snapshot ā€” matches none of them. 3. OpenRouter is only a confirmation step, never a discovery source. The prompt explicitly bans web/OpenRouter browsing for discovery (it previously caused phantom models like 
qwen3.8-flash
to be added). OpenRouter is queried only to confirm candidates LiteLLM already produced. No candidate ā†’ OpenRouter never gets asked ā†’ the 1017 entry stays invisible. One extra wrinkle: even if it had been detected, 
-1017
is a dated snapshot of the already-verified 
deepseek-v4.1-flash
, and the file's own rule says dated aliases of a kept version "stay with it" ā€” so it would likely be folded in rather than listed separately. To fix it: promote OpenRouter's 
/models
endpoint to a discovery tier (it's already queried for confirmation), broaden the DeepSeek pattern to catch `deepseek-flash`/`deepseek-v4.1`, and add an explicit dated-snapshot rule. This reply was created by an AI agent (OpenHands) on behalf of the user.
c
@fresh-machine-37269 Ooh how interesting, thanks! On DeepSeek provider, so at home, so to speak, what is its name, and is the previous flash (4.1 without point name) still available? link me the deepseek page
šŸ‘€ 1
f
āœ… Done! On DeepSeek's own API it has no dated name ā€” you call it 
deepseek-flash
. That's the only Flash model name in their docs, and as of today that alias serves DeepSeek-V4.1-Flash-1017. So "at home" the upgrade is invisible by design: same name, same pricing, same calling method ā€” just a newer model behind it. (Only OpenRouter/other hosts expose the dated form: 
deepseek/deepseek-v4.1-flash-1017
, canonical slug 
deepseek/deepseek-v4.1-flash-20261017
, HF 
deepseek-ai/DeepSeek-V4.1-Flash-1017
.) Is the previous 4.1 Flash still available? Depends where: ā€¢ DeepSeek direct: no. The Sept 10 build (the "4.1 without point name") is gone as a separately selectable model. 
deepseek-flash
is a moving alias that now points at 1017, and there's no dated name to pin. Interestingly, even the older legacy names 
deepseek-v4-flash
and 
deepseek-v4-flash-vision-exp
are still accepted, but they too route to 1017 and bill at Flash price ā€” so nothing at home gets you the pre-upgrade weights. ā€¢ OpenRouter: yes, still listed. 
deepseek/deepseek-v4.1-flash
(canonical slug 
...-20260910
) is still up and routable, alongside 
deepseek/deepseek-v4.1-flash:batch
. That's currently the only way to keep calling the pre-upgrade 4.1 Flash. Pages: ā€¢ Release post: api-docs.deepseek.com/news/news261017 ā€¢ Changelog (has the 10/17 + 09/10 entries): api-docs.deepseek.com/updates ā€¢ Models & pricing (where 
deepseek-flash
is documented): api-docs.deepseek.com/quick_start/pricing ā€¢ OpenRouter listing: openrouter.ai/deepseek/deepseek-v4.1-flash-1017 One thing worth flagging: since pricing and the API name are unchanged, this upgrade is a drop-in swap ā€” anything pointing at 
deepseek-flash
silently moved to 1017 today. If you wanted to pin behaviour, OpenRouter's dated id is the only lever. This reply was created by an AI agent (OpenHands) on behalf of the user.
c
@fresh-machine-37269 the pr is failing a test in CI. what's up? please fix it if it's from the pr, or rerun it if flaky
šŸ‘€ 1
f
āœ… Done! All green now. Here's the story: What failed: one test in the 
sdk-tests
job on the rolling PR (#4988): 
tests/sdk/agent/test_acp_agent.py::TestACPAgentAstep::test_astep_finalizes_and_reraises_completed_cancelled_prompt
Copy code
AssertionError: assert <ConversationExecutionStatus.IDLE: 'idle'> == <ConversationExecutionStatus.FINISHED: 'finished'>
1 failed, 7458 passed, 7 skipped, 12 xfailed
It's flaky, not from the PR. The test simulates cancelling an in-flight ACP prompt and asserts the turn still gets finalized (
FINISHED
) when the prompt drains inside a short grace window. The test patches 
_ACP_CANCEL_DRAIN_TIMEOUT
down to 0.01 s, and the failing run logged 
Timed out waiting for cancelled ACP prompt to drain
ā€” so the prompt didn't quiesce within that 10 ms window and the status stayed 
IDLE
. Under a 16-worker xdist run that window is a coin flip. Four things confirm it's not the PR's doing: ā€¢ The PR diff is a single file ā€” 
verified_models.py
, 
+8/-1
, just model-ID strings. No code, nothing the test touches. ā€¢ The exact same test passed on 
main
at 09:03 today (run 
39019662685
) on 
5966c781
ā€” which is precisely this PR's merge base. ā€¢ The test file was last changed 2026-10-09 (#5579), well before this branch. ā€¢ 
test_acp_agent.py
has a track record here (issues #4840 "flakes ~57% of runs", #3487). Same run also had an unrelated flaky failure on main (
test_prepare_for_sandbox_pause_blocks_new_hydration
). What I did: the rerun endpoint needs 
actions:write
, which the bot token doesn't have, so I retriggered by pushing an empty commit (
b58df447
, "ci: retrigger tests") to the PR branch. Result: 48 checks passed, 2 skipped, 0 failures ā€” including the previously-failing test, which passed cleanly on the first attempt. 
mergeable_state
is now 
blocked
only on review/branch-protection, not CI. One note: that empty commit will disappear the next time the model-list automation force-pushes this rolling branch, so no cleanup needed. And if this test keeps flaking, it's worth widening that 0.01 s drain window or marking it retry-on-failure ā€” the underlying flake is real, just not this PR's. This reply was created by an AI agent (OpenHands) on behalf of the user.
Open in Slack
PreviousNext
Powered by