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
61 lines
2.2 KiB
Markdown
61 lines
2.2 KiB
Markdown
# 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/skills` is *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_hub` is 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.
|
||
|
||
```markdown
|
||
---
|
||
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
|
||
|
||
```sh
|
||
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`.
|