noconnorandClaude Opus 5
135112eee5
Folds in the in-flight local-checkout work and fixes the context accounting
on top of it. Both halves are the same bug seen from two ends: clients were
sending requests larger than the backend's window and getting hard
ContextWindowExceededError 400s, intermittently, in a way that looked like
the model or the GPU misbehaving.
Already in flight here (unchanged in intent):
- sync.sh prefers the LOCAL CHECKOUT over re-downloading from Gitea, and
install.sh records the checkout path so it can be found. That recording
is load-bearing: without it sync.sh cannot find the repo, silently falls
back to Gitea, and every local edit to opencode.gateway.json is ignored.
Observed on this box — ~/.config/mcp-sync/source did not exist, the
default ~/.dotfiles is not where the checkout lives, and the Gitea base
still served models:{}.
- the hermes custom-provider wiring.
Fixed on top:
opencode had NO context limit on ANY gateway model, not a wrong one. Two
faults compounded. /model/info 403s for a day-to-day virtual key (only
management-scoped keys may read it), which sync.sh treats as best-effort and
falls back to names-only — as designed and as commented. But the merge then
did `prov["models"] = models`, replacing the map wholesale, so limits
declared in the base config were discarded too and there was no floor left.
Base specs are now a floor that live /model/info overrides field by field:
discovery still wins where present, so this adds no drift, and a 403 no
longer strips the limits. Verified: ornith 195584/32768, the qwens
261120/32768.
hermes' model map named `qwen3-vl-30b-a3b` at 262144 — a model the gateway
stopped serving when Ornith replaced it — while ornith-1.0-35b, the model
actually on cg-1 AND the only one with a window smaller than its neighbours
(196608), had no entry at all and inherited Hermes' default. The one model
needing a lower ceiling was the one not declaring one, which is exactly the
shape that fails only once a session grows.
NOTE for other boxes: hermes reads ~/.hermes/config.yaml, which install.sh
produces by MERGING gateway.yaml. Editing gateway.yaml alone changes nothing
until install.sh re-runs — this machine's live config was patched by hand.
Not addressed here, deliberately: the gateway-side context_window_fallback
(ai-k8s-iac). It is wired but inert while cg-2 is scaled down, so preventing
the oversized request client-side is what actually works today.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FoDK4wwB1Twty5gwiriYLf
2.2 KiB
skills — shared opencode skills
Skills every covert-gpt user gets. mcp-config/sync.sh deploys this directory
to ~/.config/mcp-sync/skills on each box; the shared opencode.gateway.json
points opencode at it via skills.paths.
Unlike models and MCP servers — which are discovered from the LiteLLM gateway
at sync time — skills are plain files with nothing on the gateway to query, so
this repo is the source of truth. They are copied from the local checkout
(the same source as the gateway config — see "Where the config comes from" in
mcp-config/README.md), so no anonymous read of this repo is required. Add a
skill here, push to main, and it lands everywhere within the sync TTL (~1h,
or immediately on a new shell) once the checkout picks the commit up.
LiteLLM's
/v1/skillsis not an alternative: it is a passthrough to Anthropic's Skills API (?beta=true), which lists skills on an Anthropic account. It does not serve skill files to a client, and opencode cannot read it./public/skill_hubis a marketplace catalog, also not a skill source.
Layout
One folder per skill, each with a SKILL.md:
skills/
my-skill/
SKILL.md # required
reference.md # optional supporting files
SKILL.md needs YAML frontmatter with name and description. name must be
1–64 chars, lowercase alphanumeric with single-hyphen separators, and match the
folder name. description is 1–1024 chars and is what the model reads to decide
whether to pull the skill in — write it to say when to use this, not just what
it is.
---
name: my-skill
description: Use when doing X. Covers Y and Z.
---
Body: the instructions the model follows once the skill is loaded.
Don't put per-user things here
Same rule as the MCP gateway: this tree is identical for every user. Skills
that depend on one person's credentials, kubeconfig, or local paths belong in
that user's own ~/.config/opencode/skills/, which sync never touches.
Verifying
opencode debug skill # lists every skill opencode can see, with its path
If a skill you added here is missing, check that the sync ran (ls ~/.config/mcp-sync/skills) and that the folder name matches the frontmatter
name.