Skip to content

server: context_geometry reports the slot's capped context, the one size the slots enforce - #111

Open
joelteply wants to merge 1 commit into
codex/s4-per-mind-integrationfrom
fable/geometry-reports-the-slot-cap
Open

joelteply wants to merge 1 commit into
codex/s4-per-mind-integrationfrom
fable/geometry-reports-the-slot-cap

Conversation

@joelteply

Copy link
Copy Markdown

Why: the core's admission reads context_geometry.max_tokens_per_sequence as the most one mind's sequence may hold (our fork is the contract). It reported llama_n_ctx_seq while every slot caps that at the model's training context (server-context.cpp, slot init).

Measured (the M5, 2026-11-11 16:2xZ, Qwen3.6-35B-A3B, -c 524285 --parallel 5 --kv-unified): /props context_geometry = {allocated_tokens 524288, max_tokens_per_sequence 524288, sequence_capacity 5}, /slots n_ctx = 262144 on every slot. A grant above 262,144 would be refused by the slot the report said could hold it.

Change: the capped value is one member (n_ctx_slot), set at load; the slots are sized from it and the report reads it. No behaviour change for the slots.

Validation: compiles in CI; live receipt after the next engine build: /props max_tokens_per_sequence == /slots n_ctx. Core side: CambrianTech/continuum#5947 (an admitted request is bounded by its grant alone).

🤖 Generated with Claude Code

https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo

…ize the slots enforce

max_tokens_per_sequence read llama_n_ctx_seq while every slot caps that at the model's
training context. On the M5 (Qwen3.6-35B-A3B, -c 524285 --parallel 5 --kv-unified) the report
said 524288 and each slot refused past 262144. The capped value is now one member, set at load,
that sizes the slots and is reported.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant