Skip to content

Using Claude Science with other models

Claude Science does not have to draw its models from Anthropic's cloud: a local gateway translates between the app and a provider of your choice or local inference.

Claude Science is Anthropic’s workbench for scientific analysis: persistent Python and R kernels, versioned artifacts, literature database access out of the box, and so on. The app is tied to a Claude account with a subscription, and the models come from Anthropic’s cloud. That’s what I thought, at least about the second part. Not true: inference can be redirected to the models of my choice.

Why this path?

Several reasons come to mind why I want free model choice (open weights instead of Claude):

  1. Processing should stay in the EU or on my own servers, without US Cloud Act exposure, because I want full control over my data.
  2. I want to try other interesting models, because I am curious.
  3. I want blazingly fast inference.
  4. I can no longer stand Claude’s style of writing.
  5. I have found a provider with lower costs.

How it works

The official Claude Science documentation lists the app’s environment variables exhaustively: DO_NOT_TRACK, GITHUB_TOKEN and the proxy variables. An endpoint override is absent.

Claude Science ships as an app with a 122 MB CLI binary (~/.claude-science/bin/claude-science). A look into its embedded strings reveals:

strings ~/.claude-science/bin/claude-science | grep ANTHROPIC_BASE_URL

The daemon embeds the Anthropic TypeScript SDK, and that SDK reads ANTHROPIC_BASE_URL as a default. More important is a function of the daemon itself (anthropicBaseUrl()), which evaluates the variable, enforces HTTPS and allows exceptions for local addresses.

The technique works with any provider that implements Anthropic’s Messages API (POST /v1/messages), or with your own local inference behind such an endpoint.

What has to sit between app and provider

A direct redirect is not enough. In testing with a real provider, there were three points where the two sides did not understand each other, and for each one a solution that ended up in a small translator script on my machine:

  1. Authentication: App and provider expect the access key in different forms. The translator puts it into the right format.
  2. Built-in functions: The app sends Anthropic-specific add-on functions along that other providers do not know. The translator drops them. The price: the agent’s built-in web search is gone; approved databases and the app’s own API calls are unaffected.
  3. Model names: The app requests models under Anthropic names. The translator replaces them with the models that are actually booked. The model selection in the app’s picker is then correct as well.

The build instructions

I did not build this myself, and I do not understand every line of it. I don’t have to. My AI agent worked it out. What came out of it can be summarised so that any other AI model can rebuild it:

Build a small local translator (proxy) between the Claude Science app and the endpoint of a provider that speaks Anthropic’s Messages API. It must do four things: translate the access key into the provider’s format, remove the Anthropic-specific server tools from the requests, map the requested model names to the booked models, and answer the model list the app retrieves with the desired models. The key lives in a file readable only by me. The app is started with two environment variables: the translator’s address and the key. Started without these variables, everything runs as before through Anthropic; the way back always stays open.

How secure is this?

The local sandbox remains untouched. Folder and network permissions, execution approvals and artifacts do not change through the proxy.

The translator reads every request in plain text. It has to see the content to rewrite model names and add-on functions. For prompts and analysis results it is therefore a trust anchor on your own machine: if you have not checked the script yourself, do not push sensitive data through it. Patient data has a hard boundary: a model provider who sees prompts with patient reference is an auxiliary person under § 203 (3) of the German Criminal Code (StGB) and, in addition to the data processing agreement under Art. 28 GDPR, must be separately bound to confidentiality. Both must be contractually in place before such data goes through this chain.

Model processing moves from Anthropic to the chosen provider. Whether that removes the US Cloud Act exposure depends on the provider; EU hosting or local inference deliver that. The due diligence stays with the user: who processes my prompts, where, with what retention?

Limits that remain

Four restrictions remain: the redirect relies on an undocumented property of a beta app; an update can break it. The agent’s built-in web search is gone, but that suits me fine; anyone who needs it can free the literature domains via the network permissions and work with fetches from the sandbox. And the provenance of the artifacts is no longer accurate: the app writes into every artifact which model created it; after the redirect it shows the Anthropic name, while a different model did the work. For a workbench whose whole point is auditability, that carries weight. Anyone who keeps using this chain should log the real provider in the translator and correct the artifact description accordingly; for publications or regulated contexts this is mandatory. And last, a risk beyond technology: Anthropic’s Consumer Terms prohibit bypassing the service’s systems or protective measures. Whether a redirect via an environment variable constitutes such a bypass cannot be read from the terms; in case of doubt, Anthropic decides. The tangible risk is the account: under the terms, Anthropic may suspend or terminate access and subscriptions at any time. Anyone unwilling to carry that risk leaves the redirect alone and runs the workbench through Anthropic’s own models.

Conclusion

Whether this works could not be learned from the documentation; only the test could answer that. The test said: yes, with a small translator between app and provider. Anyone who wants to run scientific analyses on open models gets the complete Science workbench on the infrastructure of their choice.

Sources

← All articles