Idea: Automatic API awareness #2051

Open
opened 2026-02-16 17:33:57 -05:00 by yindo · 3 comments
Owner

Originally created by @sigalor on GitHub (Oct 11, 2025).

Originally assigned to: @thdxr on GitHub.

My version: 0.14.7 on MacOS 26.0.1 (M2).

So I recently had a very simple use case:

Image

The code opencode created initially included this:

export async function ai(prompt: string): Promise<string> {
        const apiKey = (typeof process !== 'undefined' && (process as any).env?.OPENAI_API_KEY) ?? '';
        if (!apiKey) {
                throw new Error("OPENAI_API_KEY is not set");
        }
        const body = {
                model: "gpt-5-nano",
                messages: [{ role: "user", content: prompt }],
                temperature: 0.7
        };
        const res = await fetch("https://api.openai.com/v1/chat/completions", {
                method: "POST",
                headers: {
                        "Content-Type": "application/json",
                        "Authorization": `Bearer ${apiKey}`
                },
                body: JSON.stringify(body)
        });
        if (!res.ok) {
                const err = await res.text();
                throw new Error(`OpenAI request failed: ${res.status} ${res.statusText} - ${err}`);
        }
        const data: any = await res.json();
        const content = data?.choices?.[0]?.message?.content ?? '';
        return content.trim();
}

Later, I wrote bun index.ts (not as an actual shell command, but as just another chat message in the opencode TUI) and after fixing another bug, it also included this:

Shell Run updated index.ts with Bun (CLI harness active)

$ bun index.ts
16 |         },
17 |         body: JSON.stringify(body)
18 |     });
19 |     if (!res.ok) {
20 |         const err = await res.text();
21 |         throw new Error(`OpenAI request failed: ${res.status} ${res.statusText} - ${err}`);
             ^
error: OpenAI request failed: 400 Bad Request - {
  "error": {
    "message": "Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.",
    "type": "invalid_request_error",
    "param": "temperature",
    "code": "unsupported_value"
  }
}
      at <anonymous> (/Users/nalenz/Programmierung/functional-llm/index.ts:21:9)

Of course opencode did fix it, but I think to improve speed, mistakes like these should not happen in the first place. So I think "awareness of APIs" is very important to have.

For example, when a call to api.openai.com is detected, it could automatically inject the OpenAI API docs. Curious about opinions.

Originally created by @sigalor on GitHub (Oct 11, 2025). Originally assigned to: @thdxr on GitHub. My version: 0.14.7 on MacOS 26.0.1 (M2). So I recently had a very simple use case: <img width="718" height="85" alt="Image" src="https://github.com/user-attachments/assets/0e15d517-d603-44da-882e-86e28b7e190d" /> The code opencode created initially included this: ``` export async function ai(prompt: string): Promise<string> { const apiKey = (typeof process !== 'undefined' && (process as any).env?.OPENAI_API_KEY) ?? ''; if (!apiKey) { throw new Error("OPENAI_API_KEY is not set"); } const body = { model: "gpt-5-nano", messages: [{ role: "user", content: prompt }], temperature: 0.7 }; const res = await fetch("https://api.openai.com/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${apiKey}` }, body: JSON.stringify(body) }); if (!res.ok) { const err = await res.text(); throw new Error(`OpenAI request failed: ${res.status} ${res.statusText} - ${err}`); } const data: any = await res.json(); const content = data?.choices?.[0]?.message?.content ?? ''; return content.trim(); } ``` Later, I wrote `bun index.ts` (not as an actual shell command, but as just another chat message in the opencode TUI) and after fixing another bug, it also included this: ``` Shell Run updated index.ts with Bun (CLI harness active) $ bun index.ts 16 | }, 17 | body: JSON.stringify(body) 18 | }); 19 | if (!res.ok) { 20 | const err = await res.text(); 21 | throw new Error(`OpenAI request failed: ${res.status} ${res.statusText} - ${err}`); ^ error: OpenAI request failed: 400 Bad Request - { "error": { "message": "Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.", "type": "invalid_request_error", "param": "temperature", "code": "unsupported_value" } } at <anonymous> (/Users/nalenz/Programmierung/functional-llm/index.ts:21:9) ``` Of course opencode did fix it, but I think to improve speed, mistakes like these should not happen in the first place. So I think "awareness of APIs" is very important to have. For example, when a call to `api.openai.com` is detected, it could automatically inject the OpenAI API docs. Curious about opinions.
Author
Owner

@github-actions[bot] commented on GitHub (Oct 11, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #3067: About OpenCode having access to its own documentation - discusses automatic context injection of documentation for better self-awareness
  • #3095: Automatically include currently open file and selected lines as context - deals with automatic context awareness (though closed)
  • #3096: Show current open file and selected line info in cli - related to automatic context inclusion

Feel free to ignore if none of these address your specific case of automatic API documentation injection.

@github-actions[bot] commented on GitHub (Oct 11, 2025): This issue might be a duplicate of existing issues. Please check: - #3067: About OpenCode having access to its own documentation - discusses automatic context injection of documentation for better self-awareness - #3095: Automatically include currently open file and selected lines as context - deals with automatic context awareness (though closed) - #3096: Show current open file and selected line info in cli - related to automatic context inclusion Feel free to ignore if none of these address your specific case of automatic API documentation injection.
Author
Owner

@rekram1-node commented on GitHub (Oct 11, 2025):

So it worked for everything just didn't have most up to date docs for gpt-5 models and their limitations right?

Maybe doing this out of box may happen at some point, right now I think you should use some docs searching tooling, like context7 mcp and add instructions to your global AGENTS.md to tell llm to utilize that mcp when reading docs

@rekram1-node commented on GitHub (Oct 11, 2025): So it worked for everything just didn't have most up to date docs for gpt-5 models and their limitations right? Maybe doing this out of box may happen at some point, right now I think you should use some docs searching tooling, like context7 mcp and add instructions to your global AGENTS.md to tell llm to utilize that mcp when reading docs
Author
Owner

@taqtiqa-mark commented on GitHub (Oct 12, 2025):

The code opencode created initially included this

As @rekram1-node notes, indirectly, opencode did not create any of that code. It came from the AI (LLM) vendor you are using.

Where you do have a good point:
The default OC prompts probably should be well suited to developing OC, in which case that error should not have happened.

But this gets fraught because you end up either having to package some default MCP's with OC (as Goose does), and you have to craft default prompts specialized to OC development.

My 2c, is that this is the path OC should take: Default prompts (and their implicit workflows) are dedicated to developing OC and other prompts and workflows are out-of-scope.

The scope of OC being to provided the maximally performant and robust environment for the widest range of prompts and workflows. See #3112 and #3113.

@taqtiqa-mark commented on GitHub (Oct 12, 2025): > The code opencode created initially included this As @rekram1-node notes, indirectly, opencode did not create any of that code. It came from the AI (LLM) vendor you are using. **Where you do have a good point:** The default OC prompts probably should be well suited to developing OC, in which case that error should not have happened. But this gets fraught because you end up either having to package some default MCP's with OC (as Goose does), and you have to craft default prompts specialized to OC development. My 2c, is that this is the path OC should take: Default prompts (and their implicit workflows) are dedicated to developing OC and other prompts and workflows are out-of-scope. The scope of OC being to provided the maximally performant and robust environment for the widest range of prompts and workflows. See #3112 and #3113.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2051