dongarandClaude Opus 5 e38adf40ca
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 47s
Discover a model's vendor from LiteLLM instead of its name
Route selection sniffed model names: anything starting "claude-" or
"anthropic/" took the vendor-native passthrough, everything else took the
normalized route. That works only while an alias names its vendor. A
semantic role alias like "remote-architecture" is meant to point at
Anthropic today and somewhere else tomorrow, and the name says nothing
either way -- so it would have taken the normalized route regardless of
what was behind it, silently losing the fidelity A13 wants for delegations.

LiteLLM already knows the answer. /model/info reports each alias's backing
model, provider, and declared tool support, so the agent asks at startup and
routes on the provider it discovers. That keeps vendor knowledge where A5
already put it -- in the proxy -- rather than duplicating it as name patterns
here.

There is deliberately no name-based fallback: PASSTHROUGH_PREFIXES and
has_native_adapter are gone, and select_client now requires a catalog. A
second heuristic could only ever disagree with the proxy. An unknown model
raises instead of guessing a route.

Misconfiguration is therefore loud and early. build_agent validates every
role against the catalog before it clones anything, naming all the bad ones
at once. Discovery is per key -- /model/info returns only what the presented
token may use -- so the same check catches a role pointed at a real model
this key cannot reach. An unreachable proxy is reported separately, since an
outage and a typo call for different responses from the operator.

Two things now get recorded rather than inferred: the resolved model is
pinned alongside the role mapping at task start, for the reason A11 already
pins roles, and DelegationStarted carries backing_model so A16 eval history
is not averaged across whatever an alias happened to point at.

A model LiteLLM declares tool-less warns at startup rather than refusing;
A15 expects weak local models to be accommodated, and they are observed
driving tool loops anyway.

Verified live: all four aliases the production key can see route correctly
through discovery, and each chosen route works.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-23 01:47:58 +00:00

Nisse

Two self-hosted AI agents sharing a common library, named for the Nordic farm spirit that keeps the place running overnight and expects to be treated well in return.

Package Role
nisse-core/ Shared library both agents sit on (Part A)
nisse-dev/ Dev Agent — plans and implements software projects (Part B)
nisse-ops/ Sysadmin Agent — operates infrastructure (Part C)

One repository, three packages. The library does not exist as code yet: it is extracted from nisse-dev once that agent works (build-order step 10), as a package split within this tree.

Architecture

The system-level specification lives at docs/Architecture-Build-Spec.md. It covers the shared library, both agents, the supporting services, the build order, and the remaining open decisions.

S
Description
LLM Agents for specialized tasks.
Readme
4.4 MiB
1 Stars 2 Watchers 0 Forks
v0.1.0
Latest
2026-10-07 22:39:30 +00:00
Languages
Python 98.1%
Shell 1.6%
Dockerfile 0.3%