[nasser1941]

Fixes two places that reported a loaded model wrongly.

1. lcode doctor never showed the Loaded line

cmd_doctor compared /api/ps names with ==. resolve_model returns lcode-qwen3.6-35b, while Ollama lists lcode-qwen3.6-35b:latest, so the line never appeared for the models lcode setup creates. This was seen on a real lcode doctor run with the model loaded. Doctor now uses residency.placement, which matches the name with same_model, and prints the same words as the line after a load, plus the context:

✓ Loaded     ~23 GB, 42% on the GPU and the rest in system RAM · 32K context

2. The line after a load repeated /api/ps

/api/ps counts the memory Ollama's runner allocates. The weights it keeps in system RAM stay mapped from the model's file, so they're left out. With Ollama 0.40.13, lcode-qwen3.6-35b at 32K on the 12 GB laptop reports size 10.49 GB and size_vram 10.29 GB. lcode printed 10.5 GB, 98% on the GPU and the rest in system RAM, while ~12 GB of experts were in RAM.

For a catalog model that Ollama reports as partly off the GPU, lcode now counts the whole model at the catalog's estimate (memory_gib, the same "~23 GB needed" that lcode setup, lcode doctor and the context picker show), unless Ollama counts more. ~ marks the estimate.

Case	Before	After
qwen3.6-35b, 32K, 12 GB GPU, Ollama 0.40.13	10.5 GB, 98% on the GPU and the rest in system RAM	~23 GB, 42% on the GPU and the rest in system RAM
A model all on the GPU	6.6 GB, all on the GPU	unchanged
Ollama counts more than the estimate	its numbers	unchanged
A model outside the catalog	Ollama's numbers	unchanged: nothing else is known

A read-only check on the laptop with Ollama 0.40.15 (the model was already loaded; nothing was loaded for this) gives size 9.78 GB and size_vram 9.58 GB, with 12.0 GiB of the model's file resident in the runner. The new line says ~23 GB, 39% on the GPU.

Why memory_gib and not in_ram_gib

in_ram_gib is memory_gib − vram_gib, so it assumes the model gets the whole GPU: 10.7 GB here. Ollama puts 9.6–10.3 GB of the 12 GB there, so the part in RAM is ~2 GB more than that. in_ram_gib also stays the same when another program takes GPU memory, which is exactly when the shortfall warning matters. Built on it, the share would come out at 47%, and the warning would fire only below ~4.5 GB on the GPU.

expected_share and SHORTFALL

expected_share is unchanged: 53% for this case. With Ollama's numbers, gpu_share was 98%, so the "less of it is on the GPU than usual" warning could never fire. A model squeezed to 4 GB on the GPU by another program still counted 95%. With the estimate, a normal load is at 39–42% and the warning fires below 28%: under ~6.8 GB on the GPU. Before Ollama 0.40, with its full count of ~22.3 GB, it fired under ~6.2 GB. The warning said usual (53%), but normal loads were never at 53% (they show 39–45%), so it now says (up to 53% fits). The dense-split warning uses the same share, so it no longer depends on whether Ollama counts a dense model's layers in RAM.

Tests

In tests/test_residency.py, using FakeOllama and make_agent:

• test_a_load_is_reported_once_with_how_it_fits: a session with Ollama 0.40.13's /api/ps entry says ~23 GB, 42% on the GPU and gives no warning. The old code gives 10.5 GB, 98%.
• test_less_on_the_gpu_than_usual_is_explained: the warning fires with the way Ollama 0.40 counts. The dense warning fires whether or not the part in RAM is counted.
• test_the_part_of_a_catalog_model_ollama_leaves_out_is_counted and test_what_ollama_counts_stands_when_nothing_is_left_out_or_nothing_is_known cover the estimate, the loaded context, CPU only, all on the GPU, a count above the estimate, and a model outside the catalog.
• test_doctor_shows_how_the_loaded_model_fits: doctor shows Loaded for lcode-qwen3.6-35b:latest, and nothing for another model. The old code shows nothing.

uv run pytest, ruff check, ruff format --check, basedpyright and mkdocs build --strict pass locally.

Left alone

• lcode bench has its own memory_use from /api/ps (Loaded in 18s · 10.4 GB, 98% on the GPU in docs/bench.md), which also goes into its JSON results. It has the same cause, but changing it changes what results compare against.
• The RAM line from Say when the machine is short of RAM for the model (#246) #247 uses in_ram_gib (~11 GB of the model that doesn't fit on the GPU). Measured, that part is nearer 12–13 GiB, because the model doesn't get the whole GPU.
• On a machine without a GPU, the line after loading a dense model still says it's "split between GPU and CPU". That was true before this PR too.

🤖 Generated with Claude Code