haylan/LLM-Server
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Should opencode's context/output limits be generated from litellm-config.yaml, or hand-maintained? #28

New Issue
Closed
opened 2026-09-03 04:19:45 +00:00 by haylan · 1 comment
haylan commented 2026-09-03 04:19:45 +00:00
Owner
Copy Link
Copy Source

Part of #26

Question

opencode's `limit.context`/`limit.output` (in the `qwen3.8-27b-local`
provider block of `opencode.json`) are bookkeeping-only hints with no
server-side enforcement or runtime auto-discovery (confirmed in
`docs/research/opencode-cli-setup.md` §5). They need to track this repo's
own `LLAMA_CTX_SIZE` (`.env.example`, currently 65536) and litellm's
`max_tokens` (`litellm-config.yaml`, currently 16384) or they'll silently
drift whenever those change.

Decide: does this repo close that gap with its own tooling, and if so how?
Options to weigh (not exhaustive):

  • A small generator script (e.g. `scripts/generate-opencode-config.sh`)
    that reads `.env`/`litellm-config.yaml` and writes/patches the relevant
    block of `opencode.json`, run manually or folded into `scripts/update.sh`.
  • A documented manual-sync convention (a comment in each file pointing at
    the other, checked by eye) — no new tooling.
  • Accept the drift risk as-is; just document the dependency.

Depends on: what #27 (How does opencode's auto-compact actually work) finds
about the actual config surface — if compaction has its own separate knob
beyond `limit.context`/`limit.output`, that knob needs the same treatment.

If a generator script is chosen, this ticket's resolution should also
settle: where opencode.json lives that gets written (this session's
`~/.config/opencode/opencode.json` has no provider block yet — is the
target the project-local `opencode.json` instead, checked into this repo?)
and the exact source-of-truth values to pull (env var vs. parsed YAML).

Part of #26 ## Question opencode's \`limit.context\`/\`limit.output\` (in the \`qwen3.8-27b-local\` provider block of \`opencode.json\`) are bookkeeping-only hints with no server-side enforcement or runtime auto-discovery (confirmed in \`docs/research/opencode-cli-setup.md\` §5). They need to track this repo's own \`LLAMA_CTX_SIZE\` (\`.env.example\`, currently 65536) and litellm's \`max_tokens\` (\`litellm-config.yaml\`, currently 16384) or they'll silently drift whenever those change. Decide: does this repo close that gap with its own tooling, and if so how? Options to weigh (not exhaustive): - A small generator script (e.g. \`scripts/generate-opencode-config.sh\`) that reads \`.env\`/\`litellm-config.yaml\` and writes/patches the relevant block of \`opencode.json\`, run manually or folded into \`scripts/update.sh\`. - A documented manual-sync convention (a comment in each file pointing at the other, checked by eye) — no new tooling. - Accept the drift risk as-is; just document the dependency. Depends on: what #27 (How does opencode's auto-compact actually work) finds about the actual config surface — if compaction has its own separate knob beyond \`limit.context\`/\`limit.output\`, that knob needs the same treatment. If a generator script is chosen, this ticket's resolution should also settle: where opencode.json lives that gets written (this session's \`~/.config/opencode/opencode.json\` has no provider block yet — is the target the project-local \`opencode.json\` instead, checked into this repo?) and the exact source-of-truth values to pull (env var vs. parsed YAML).
haylan added the wayfinder:grilling label 2026-09-03 04:19:45 +00:00
haylan commented 2026-09-03 04:42:15 +00:00
Author
Owner
Copy Link
Copy Source

Decided in practice, not via a generator script: opencode's limit.context/limit.output are hand-set in ~/.config/opencode/opencode.json (65536/16384, matching what's currently live), with an inline comment flagging that they must be bumped by hand when LLAMA_CTX_SIZE/litellm's max_tokens change — no automated sync built. Rationale: this stack's config changes are infrequent and already require a manual update.sh run on the server, so a generator script would be new code tracking a low-frequency drift risk; a comment pointing at the source of truth is enough.

Decided in practice, not via a generator script: opencode's `limit.context`/`limit.output` are hand-set in `~/.config/opencode/opencode.json` (65536/16384, matching what's currently live), with an inline comment flagging that they must be bumped by hand when `LLAMA_CTX_SIZE`/litellm's `max_tokens` change — no automated sync built. Rationale: this stack's config changes are infrequent and already require a manual `update.sh` run on the server, so a generator script would be new code tracking a low-frequency drift risk; a comment pointing at the source of truth is enough.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder grilling ticket
 wayfinder:map
Wayfinder map issue
 wayfinder:prototype
Wayfinder prototype ticket
 wayfinder:research
Wayfinder research ticket
 wayfinder:task
Wayfinder task ticket
No labels wayfinder:grilling
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
haylan (Arthur Erlich)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Blocks
#29 Point opencode's provider block at litellm.home with a virtual key
haylan/LLM-Server
Depends on
#27 How does opencode's auto-compact actually work — trigger threshold and config surface?
haylan/LLM-Server
Reference: haylan/LLM-Server#28