databricks-claude-3-7-sonnet compatible

[ikejiri-makoto]

Description

databricks-claude-3-7-sonnet compatible

Screenshots

[netlify[bot]]

✅ Deploy Preview for continuedev ready!

Name	Link
🔨 Latest commit	9f1ae5a493dd60d6ffeef049b635d1c056b47ebd
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/68186bc8f21d2b0008c59c71
😎 Deploy Preview	https://deploy-preview-5379--continuedev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[chezsmithy]

Curious if you were expecting tools to function as well. You might need to take a look at the tools support file and the openAI provider and how it supports tool calls.

[ikejiri-makoto]

We don't want to keep the pnpm lock file. ⇒ Fixed

There is a lot of extra logging-related code that we don't have in other providers. This isn't something we want to support. ⇒ Fixed

A question: there is a lot of code here, and I'm wondering whether this is equivalent to OpenAI-compatible APIs or AWS Bedrock, or something else where we would be able to swap out a base URL rather than rewriting all of the logic? ⇒ Referenced “Anthropic.ts” and “OpenAI.ts” and fixed

[ikejiri-makoto]

Technical Explanation: Why the Complex Databricks Adapter Implementation is Essential for Claude 3.7 Sonnet's Thinking Mode

Executive Summary

I initially implemented a simplified version of Databricks.ts based on Anthropic.ts, but this resulted in a critical issue: Claude 3.7 Sonnet's output volume was reduced to approximately 10% of what the original implementation delivers. This document explains why the original complex implementation is essential for properly leveraging the thinking mode capabilities.

Background: Fundamental Differences Between Anthropic and Databricks Adapters

While Anthropic.ts is a straightforward adapter that communicates directly with the Anthropic API, the Databricks adapter needs to interact with Claude models through a more complex platform layer. In particular, Claude 3.7 Sonnet's "thinking mode" requires specialized processing that cannot be simplified without significant functional loss.

Specific Issues with the Simplified Implementation

1. Insufficient Streaming Implementation

   The original implementation contains approximately 300 lines of code handling both WHATWG streams and Node.js Readable streams. Without this logic, it's impossible to fully capture the large volume of tokens generated in thinking mode:

   typescript if (typeof (res.body as any).getReader === "function") { // WHATWG streams implementation // ...extensive streaming code... } else { // Node.js Readable stream implementation // ...additional streaming code... }

2. Lack of Multi-Format Response Handling

   Claude 3.7 Sonnet's output can be returned in multiple JSON formats, especially when in thinking mode:

   typescript // Example from original code detecting thinking mode output if (json.thinking || (json.content && json.content[0]?.type === "reasoning")) { // Extract and process thinking content }

   Without handling these various formats, most of the thinking process is lost.

3. Insufficient Buffer Management

   The original code uses multiple buffers to reconstruct responses:

   typescript let buffer = ""; let rawBuffer = ""; let thinkingContent = "";

   Without this detailed buffer management, data is lost, especially during lengthy thinking processes.

4. Thinking Mode Token Configuration

   Claude 3.7 Sonnet's thinking mode requires proper configuration:

   typescript finalOptions.thinking = { type: "enabled", budget_tokens: 16000 // Sufficient token budget }; const maxTokens = Math.max( options.maxTokens ?? 4096, isThinkingEnabled ? thinkingBudget + 1000 : 0 );

   Inadequate configuration restricts the thinking mode and prevents deep analysis.

5. Missing Error Recovery Mechanisms

   The original code includes robust error handling, including recovery from stream interruptions and detection of various completion signals. Without this, responses are lost when connection issues occur.

Impact on User Experience

With the simplified code, users cannot effectively utilize Claude 3.7 Sonnet's most valuable features: detailed analysis and reasoning. Although the adapter appears to function, it creates the following issues:

1. Incomplete responses (only about 10% is retrieved)

2. Lack of deep analysis

3. Truncated complex reasoning processes

4. Unexpected terminations during streaming

Recommendation

For the Continue extension to deliver the true value of Claude 3.7 Sonnet, it's essential to maintain the robust implementation of the original Databricks.ts. While the code may appear complex at first glance, this complexity is necessary to reliably extract Claude 3.7 Sonnet's advanced capabilities.

The 90% of output lost through simplification contains the most valuable analysis and insights. To provide users with the complete functionality they expect, we should embrace this complex logic.

For these reasons, I conclude that we should maintain the original complex Databricks.ts implementation and avoid introducing the simplified version based on Anthropic.ts.

[ikejiri-makoto]

The following features are also implemented ・Real-time display of output results on the screen ・Creation of a dedicated thinking panel in VS Code ・Implementation of a progress indicator showing what Claude is actively thinking about ・Formatting of thinking text for better readability ・Display of thinking text on the screen