Memory sidecar is dead on Claude credentials: SIDECAR_CLAUDE_MODEL uses the Haiku 3.5 date, 404s on every call

[MatrixMagician]

Problem

The memory sidecar's Claude model is pinned to claude-haiku-4-5-20241022:

https://github.com/1jehuang/jcode/blob/master/crates/jcode-base/src/sidecar.rs#L22

20241022 is the Haiku 3.5 snapshot date. Paired with a claude-haiku-4-5 base it forms an id Anthropic does not publish, so every sidecar call on the Claude path returns 404 not_found_error.

Verified against the live API with jcode's own OAuth credentials and headers:

claude-haiku-4-5-20241022      HTTP 404  {"type":"error","error":{"type":"not_found_error","message":"model: claude-haiku-4-5-20241022"},...}
claude-haiku-4-5-20251001      HTTP 200  {"content":[{"type":"text","text":"OK"}],...}

GET /v1/models confirms claude-haiku-4-5-20251001 is the only Haiku in the catalogue, so the correct id is unambiguous.

The failure is near-silent, which is why it survived so long. rerank_candidates_consensus_attributed catches the transport error, logs it rate-limited, and arms a circuit breaker:

[WARN] EVENT event="Memory consensus judge failed; circuit breaker armed" error="Claude API error (404 Not Found): ... model: claude-haiku-4-5-20241022 ..."

After that the breaker suppresses the judge for the rest of the session. Nothing surfaces to the user, and since the judge is the only thing allowed to surface memory, memory recall silently degrades rather than erroring.

git log -S dates the bad id to the original feat: add Haiku 4.5 sidecar for memory system commit, so the Claude sidecar path has never worked. Users on Codex credentials are unaffected (they select SIDECAR_OPENAI_MODEL); only Claude-credentialed users without Codex creds hit it.

Every other reference in the tree already uses the correct id (auth/lifecycle.rs, provider-core/anthropic.rs, provider-core/model_id.rs, tui/model_names.rs). sidecar.rs is the sole outlier.

Expected behavior

• The sidecar's Claude model is an id the Anthropic catalogue actually publishes.
• A wrong model id does not degrade into a silently-disabled feature.

Fix

1. Pin SIDECAR_CLAUDE_MODEL to claude-haiku-4-5-20251001, matching the rest of the codebase.
2. Add a regression test asserting the id is a dated Haiku snapshot and specifically rejecting the 3.5 date, so a family/date mismatch cannot recur.

Affected file:

• crates/jcode-base/src/sidecar.rs

I have this fixed and tested locally (1252/1252 jcode-base tests pass) and am happy to open a PR.

Possible follow-up

The near-silence is arguably the more valuable fix. A 404 not_found_error is a permanent configuration fault, not a transient transport failure, yet record_failure_backoff treats them identically. Distinguishing "this model does not exist" from "the network blipped" and surfacing the former once at startup would have made this immediately visible instead of invisible for the feature's entire lifetime. Happy to file that separately if useful.

[MatrixMagician]

A branch with the fix is pushed and rebased onto current master (3 ahead, 0 behind, clean merge):

https://github.com/MatrixMagician/jcode/tree/fix/sidecar-haiku-model-id

Compare view against upstream master:
master...MatrixMagician:jcode:fix/sidecar-haiku-model-id

Two files, crates/jcode-base/src/sidecar.rs (+43/-2) and scripts/install_release.sh (+49/-12). It also covers #799, since both bugs surfaced from the same upgrade.

I could not open the PR myself: POST /repos/1jehuang/jcode/pulls returns 404 and the GraphQL path reports "MatrixMagician does not have the correct permissions to execute CreatePullRequest", despite the fork being present, the branch being visible to the fork network, and my token carrying the repo scope. Other contributors' PRs are merging normally, so this looks account-specific rather than a repo setting. Happy to retry if that clears, or feel free to pull the branch directly.

Testing on the rebased branch: cargo test -p jcode-base --lib sidecar:: passes 12/12. The model id itself was verified against the live API rather than inferred: the old id returns HTTP 404 not_found_error and the new one returns HTTP 200, and GET /v1/models lists claude-haiku-4-5-20251001 as the only published Haiku.

[MatrixMagician]

Narrowed the PR-creation failure, since my earlier note guessed at the cause.

It is specific to this repository, not my account. Creating a PR on a repo I own returns a content-level error ("No commits between..."), so CreatePullRequest works for me generally. Against 1jehuang/jcode it returns:

• REST POST /repos/1jehuang/jcode/pulls -> 404 Not Found
• GraphQL -> MatrixMagician does not have the correct permissions to execute CreatePullRequest

I also ruled out a stale fork: MatrixMagician/jcode master was 211 commits behind, so I fast-forwarded it to upstream 02439b492. Retrying the PR afterwards produced the identical error, so divergence was not the cause.

The remaining plausible causes are only visible to a repo admin: a temporary interaction limit on the repository, or a user-level block. Both GET /repos/1jehuang/jcode/interaction-limits and the collaborator-permission endpoint return 403 for me, so I cannot confirm which from outside.

The branch is ready either way, now based on current master with a synced fork:

master...MatrixMagician:jcode:fix/sidecar-haiku-model-id

If an interaction limit is set and later lifts, I am happy to open the PR properly. Otherwise the two commits can be cherry-picked directly, or I can attach them as patches here if that is easier.

[1jehuang]

Fixed in #820 by updating the sidecar default to claude-haiku-4-5-20251001 and adding regression coverage for the configured model ID. The focused sidecar test suite passes.

--- — Jcode agent (automated triage), on behalf of @1jehuang