mito-ai: remove api key traitlet

[aarondr77]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context, and the specification if there is one.

Testing

Please provide a list of the ways you can "access" or use the functionality. Please try and be exhaustive here, and make sure that you test everything you list.

• I have tested this on real data that is reasonable and large
• If I changed the interaction with JupyterLab, I tested that it does not break other programs (like VS Code), and tested that it works "multiple times" in the same notebook.

Documentation

Note if any new documentation needs to addressed or reviewed.

---

Note

Modernizes provider configuration and capabilities handling.

• Replace CLAUDE_API_KEY with ANTHROPIC_API_KEY across constants, provider routing, and tests
• Remove traitlet api_key config plumbing from OpenAIClient/ProviderManager; rely on OPENAI_API_KEY/env for selection
• Standardize capability reporting (e.g., OpenAI now provider: "OpenAI" with model: "<dynamic>"); simplify key_type to user_key when any user provider env/model is present
• Update OpenAI client construction to use env keys directly; keep Azure/Ollama precedence and dynamic model resolution
• Adjust tests to new env names/behaviors and expectations (Azure priority, Mito server fallback, limits, retries)

^{Written by Cursor Bugbot for commit 68a3626. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
monorepo	Ready	Preview, Comment	Jan 15, 2026 1:36pm

[cursor]

Invalid API key reports wrong provider capabilities

Medium Severity

The capabilities and key_type properties now check raw constants.OPENAI_API_KEY (an unvalidated environment variable) instead of delegating to self._openai_client.capabilities which checks the validated self.api_key. When a user sets an invalid OpenAI API key, OpenAIClient validates it and sets self.api_key = None, but constants.OPENAI_API_KEY remains truthy. The new code reports provider="OpenAI" and key_type="openai" even for invalid keys, while actual API calls fall back to Mito server. This causes incorrect provider information to be shown to users.

Additional Locations (1)

• mito-ai/mito_ai/completions/providers.py#L94-L96

 

[cursor]

Orphaned traitlet decorators reference removed api_key attribute

High Severity

The api_key Unicode traitlet was removed from OpenAIClient, but the @default("api_key") decorator (line 63) and @validate("api_key") decorator (line 68) with their associated methods were left behind. These decorators reference a non-existent trait, which will cause a TraitError when the class is instantiated because traitlets cannot find the api_key attribute to bind these handlers to. The _validate_api_key method also makes HTTP calls to OpenAI to validate keys, which is now unreachable dead code.