add support for responses api in openai typescript sdk

[nexxeln]

[cloudflare-workers-and-pages[bot]]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	supermemory-app	af10f175	Nov 07 2025, 07:23 AM

[nexxeln]

• #549 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label Main to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude[bot]]

Code Review: Add Support for Responses API in OpenAI TypeScript SDK

Summary

This PR extends the SuperMemory middleware to support OpenAI's Responses API in addition to the existing Chat Completions API. The implementation follows the established patterns and adds memory injection capabilities to the new API.

---

✅ Strengths

1. Consistent Architecture: The implementation mirrors the existing Chat Completions logic, making it easy to maintain and understand.

2. Good Code Reuse: The memory search logic is properly abstracted into getMemoriesForInstructions(), avoiding code duplication.

3. Comprehensive Documentation: JSDoc comments are thorough and include examples for both APIs.

4. Graceful Degradation: The code checks for API availability before wrapping it (if (originalResponsesCreate)), preventing errors on older OpenAI SDK versions.

5. Proper Error Handling: Throws a clear error if the Responses API is called but not available in the client version.

---

🐛 Potential Issues

1. Type Safety Concern (packages/tools/src/openai/middleware.ts:421)

const createResponsesWithMemory = async (
  params: Parameters<typeof originalResponsesCreate>[0],
) => {

Issue: originalResponsesCreate could be undefined, but Parameters<typeof originalResponsesCreate> would fail at type-checking time if it's undefined.

Suggestion: Add a type guard or use a more explicit type:

type ResponsesCreateParams = NonNullable<typeof originalResponsesCreate> extends (...args: infer P) => any ? P[0] : never;

2. Silent Memory Addition Failure (middleware.ts:437)

addMemoryTool(client, containerTag, content, customId, logger)

Issue: This is a fire-and-forget call. If memory addition fails, the error is logged but execution continues. This is inconsistent between Chat Completions (line 483) and Responses API.

Impact: Low - this appears to be intentional design, but worth documenting why we don't await.

3. Input Type Narrowing (middleware.ts:427)

const input = typeof params.input === "string" ? params.input : ""

Question: What happens if params.input is an array or complex type? The Responses API might support structured inputs in the future.

Suggestion: Add logging when input is not a string:

const input = typeof params.input === "string" ? params.input : ""
if (params.input && typeof params.input !== "string") {
  logger.debug("Non-string input detected, skipping memory search", { inputType: typeof params.input })
}

---

🔒 Security Concerns

1. API Key Exposure: The code continues to rely on process.env.SUPERMEMORY_API_KEY which is good, but ensure this is documented in the package README.

2. Memory Injection Size: No validation on the size of memories being injected into instructions. Large memory sets could:

   • Exceed token limits
   • Increase costs unexpectedly
   • Cause API failures

Suggestion: Consider adding a size check or truncation mechanism similar to the 100-character preview logic.

---

⚡ Performance Considerations

1. Duplicate Code: The getMemoriesForInstructions function (lines 360-418) is nearly identical to the logic in addSystemPrompt (lines 145-217).

Suggestion: Extract common logic to reduce duplication:

const searchAndFormatMemories = async (
  queryText: string,
  containerTag: string,
  logger: Logger,
  mode: "profile" | "query" | "full",
  context: "chat" | "responses"
) => {
  // Shared implementation
}

2. Sequential API Calls: When both addMemory and memory search happen, they're sequential. Consider if these could be parallelized for Responses API.

---

🧪 Test Coverage

Critical Gap: No tests exist for the OpenAI middleware at all.

Found existing test files:

• test/vercel.test.ts
• test/claude-memory.test.ts
• src/tools.test.ts

Recommendation: Add test/openai-middleware.test.ts covering:

1. Chat Completions API with memory injection
2. Responses API with memory injection (new functionality)
3. Behavior when Responses API is unavailable
4. Error handling for missing API key
5. Different mode configurations (profile/query/full)
6. addMemory="always" vs "never"
7. Edge cases (empty input, missing instructions, etc.)

---

📝 Code Quality Observations

1. Minor Text Inconsistency (middleware.ts:190 vs 403):

   • Chat: "Search results for user's recent message"
   • Responses: "Search results for user's input"

   Consider unifying the terminology.

2. DRY Violation: Memory count logging appears in both functions with identical code.

3. Missing Validation: No check if params.instructions is undefined before concatenating (line 459), though it should work due to the || "" fallback.

---

🎯 Recommendations

High Priority:

1. Add comprehensive test coverage for both APIs
2. Consider extracting duplicate logic into shared functions

Medium Priority: 3. Add input size validation/limits for memory injection 4. Improve type safety for createResponsesWithMemory parameters 5. Add logging for non-string input types

Low Priority: 6. Unify terminology in log messages 7. Document why addMemoryTool is fire-and-forget

---

✅ Approval Status

Overall, this is a solid implementation that extends functionality consistently with the existing codebase. The main concern is the complete lack of test coverage for this feature.

Recommendation: Approve with the strong suggestion to add tests before or immediately after merging.

The code follows the repository's TypeScript standards, uses proper error handling, and maintains backward compatibility. Good work! 🚀

[graphite-app[bot]]