Failure to connect to AI provider

dmontaine

I have a Deepseek API key. Both the URL and the key validate. The models list, but then fail on validation.

Garry

I've been investigating this and it would seem there is a peculiarity to how DeepSeek handles reasoning compared to other OpenAI compatible providers. I think I have fixed the issue but just need to test it a bit more thoroughly tomorrow. I will update with my results but I think this should be fixed in the next release 🤞

Garry

Morning. I have thoroughly tested Objo AI Assistant with the patch with DeepSeek's API and it is now working.

The fix will be in the next release: https://feedback.objo.dev/bug/1119

dmontaine

Thanks. And I would ask that you seriously consider MCP support. In a Free Basic IDE that I am modifying with the help of Claude Code, adding an MCP sidecar was a 1/2 hr session. There are real advantages in being able to use one of the subscription models rather than an API, both in cost and capabilities. I understand the concerns expressed above, but MCP access can be made optional with a simple check box. Then it is up to the user to determine the risk in their situation.

Garry

Thanks. I have given MCP support serious consideration, and I’ve decided to implement it.

I don’t doubt that a minimal MCP sidecar can be demonstrated in half an hour, particularly when an IDE already exposes the necessary internal commands. However, I think that understates the difference between a proof of concept and a secure, supported feature in a shipping, cross-platform IDE with many users.

The server itself is the relatively easy part. The larger job is defining a stable control API, authenticating the connection to Studio, making access explicitly opt-in, separating read, edit and execution permissions, handling multiple Studio instances, displaying external-agent activity, supporting cancellation and timeouts, and thoroughly testing the whole boundary. It must also be packaged, signed and notarised correctly on every platform without compromising Studio’s existing release process. A checkbox will certainly be part of the experience, but a checkbox alone is not the security model.

That said, I agree with your broader argument. Many users already pay for Claude Code, Codex or another agent and understandably want to use that subscription rather than configure another API account. Professional users may also prefer their existing agent and workflow over an assistant embedded in the IDE. More generally, making it possible to tell an agent to build something using Objo could be very advantageous for adoption.

The current plan is therefore to keep Studio’s built-in AI Assistant as the most integrated experience while adding optional MCP access for external agents. The proposed design uses a small local MCP companion that connects to an authenticated local gateway in Studio. It will expose carefully bounded Studio operations rather than arbitrary shell or filesystem access. Implementation will be staged, beginning with read-only capabilities before adding guarded source editing, saving and project execution.

I’m not ready to promise a release date, but this has moved beyond “I’ll consider it”: there is now a detailed implementation plan, and I am actively working on it.