### Duplicates
- [x] I have searched the existing issues
### Summary 💡
The TypeSafe Jev blocks always call `api.typesafe.ai`, and `test_overload_is_not_retried_and_environment_cannot_redirect_credentials` makes sure `TYPESAFE_BASE_URL` can't change that. That makes sense for the hosted platform: a stray env var shouldn't be able to send users' keys somewhere else.
For self-hosted installs, an explicit operator setting would help instead. For example, `typesafe_api_base_url` in the backend `Config`, defaulting to `DEFAULT_BASE_URL` and passed to `AsyncTypeSafeClient` in `call_jev`. It wouldn't read the SDK's env var, so that test keeps passing, and nothing changes unless an operator sets it.
### Examples 🌈
Other projects already let operators set this: deer-flow's TypeSafe connection takes a validated `base_url` (`deerflow/typesafe/connection.py`), and LiteLLM's TypeSafe guardrail reads `TYPESAFE_API_BASE`. With the setting, a self-hosted Jev-compatible server could back the blocks without code changes, for example WaterSheep (open source, which I maintain).
### Motivation 🔦
Running the blocks against a local or private server when the data shouldn't leave the network, testing graphs without a TypeSafe key, or going through a company proxy. Happy to send a PR if this direction is OK with you.
Hi! I’d be interested in working on this issue.
I’ve reviewed the proposed approach and can implement support for an explicit operator-configured `typesafe_api_base_url` for self-hosted deployments, while keeping the existing hosted behavior and credential-safety test intact.
I can also add the relevant tests and documentation. Happy to send a PR if this direction works for the maintainers.
Could you assign this issue to me?
## Triage note (host-local AutoGPT backfill sweep)
Thanks for the clear write-up and the self-hosted / WaterSheep motivation.
This reads as a **feature request / enhancement** (opt-in `typesafe_api_base_url` Config for TypeSafe Jev blocks on self-hosted platforms), not a product bug report: no bug label, no broken runtime outcome to reproduce on `significantgravitas/autogpt:latest`.
- Image under test: `v0.8.2` / `sha-bf6e0c33d0f615983082ed7a5343dbbfc25adaab` @ `sha256:8322941548c6d43f7b343dff16c5a184cdc6928df8ad6c5fbae856bd380e1618`
- Leaving to maintainers/product whether an explicit operator setting (not the SDK env var) should redirect the TypeSafe client; out of the bug-repro queue unless a concrete broken hosted/self-hosted path is reported.
(Automated triage from the standing AutoGPT issue-sweep; not a maintainer decision.)
@superezzdev thanks, fine by me, though a maintainer should confirm the direction first. If it helps with testing: a Jev-compatible server runs locally without a TypeSafe key, so you can point the new setting at it.
```bash
pip install git+https://github.com/SamratDuttaOfficial/WaterSheep
watersheep --model samratduttaofficial/WaterSheep --serve # POST /v1/systemone on 127.0.0.1:8766
```
Then set `typesafe_api_base_url` to `http://127.0.0.1:8766/v1` (any placeholder key works). It answers noul, choice, score and multi questions in the same shape as Jev.
For testing the new setting, `pydecide` gives you a Jev-compatible server from PyPI without a git install: `pip install pydecide` then `decide serve --port 8811`, which serves `POST /v1/systemone` in the TypeSafe wire format. CI validates the responses against the typesafe-sdk pydantic models, and the SDK parses them unchanged, so pointing `typesafe_api_base_url` at it needs no key.