[mishioo]

Problem

jev.py posts to https://api.typesafe.ai/v1/systemone with jev-latest, both hardcoded. We're moving decision models behind LiteLLM, which serves the same /v1/systemone route natively (and translates it for OpenAI Decisions models), so the request itself doesn't need to change. Only where it goes, and what the model is called there: a proxy names models by its own aliases, and a virtual key may call only the ones it lists.

Solution

Two optional settings, read the same way as the key (environment first, then ~/.config/typesafe/env):

Variable	Default
JEV_BASE_URL	https://api.typesafe.ai	/v1/systemone is appended; a base ending in /v1 or the full path works too
JEV_MODEL	jev-latest	used when a call passes no --model

The key stays in TYPESAFE_API_KEY. Slightly misnamed when it holds a LiteLLM key, I know, but renaming it would break every existing setup for the sake of one word.

Smaller things that fell out of it:

• A 400 reads as a malformed request and isn't retried, same as 422, because that's how LiteLLM rejects one.
• 401 and 403 name the model. Behind a proxy, a perfectly valid key can still be refused a model it doesn't list, and "your key is wrong" sends you looking in the wrong place.
• Error messages name the host that answered rather than always saying "TypeSafe".
• key-status also reports the endpoint and default model, and where each came from. Still never the key.
• lean-jev-usage described the evaluate binary we dropped in 0.3.0; it now lists the actual requirements.

Without the new variables, behaviour is exactly as before.

Testing

• python3 -m unittest tests/test_jev.py: 33 pass, including new ones for settings resolution, the 400/401 paths and key redaction.
• claude plugin validate . --strict passes.
• Live against our LiteLLM proxy: a noul + score + choice call to jev comes back correct in ~0.7 s. A model the key doesn't list returns the 403 message above, with the proxy's own detail attached.

🤖 Generated with Claude Code