loopengine 0.1.43 → 0.1.45

package/dist/core/agent-config.d.ts

@@ -252,6 +252,12 @@ export type AgentModelConfig = {
     model: string;
     apiKey?: string;
     maxTokens?: number;
+    /** Omit unless the model actually needs it — see
+     * OpenAIModelCallOptions.reasoningEffort's own doc comment
+     * (core/model-calls/openai-model-call.ts) for why a reasoning-
+     * capable model (gpt-5.x) can require this be `'none'` just to use
+     * function tools at all. */
+    reasoningEffort?: 'none' | 'minimal' | 'low' | 'medium' | 'high' | 'xhigh' | 'max';
 } | {
     provider: 'deepseek';
     model: string;

package/dist/core/model-calls/openai-model-call.d.ts

@@ -9,6 +9,16 @@ export interface OpenAIModelCallOptions {
      * one you actually want. */
     model: string;
     maxTokens?: number;
+    /** Omitted by default — a reasoning-capable model (the gpt-5.x family)
+     * otherwise gets whatever effort level OpenAI defaults it to, which
+     * some of these models refuse to combine with function tools on
+     * /v1/chat/completions at all ("Function tools with reasoning_effort
+     * are not supported ... set reasoning_effort to 'none'" — confirmed
+     * live against gpt-5.6-luna). Set this to `'none'` for a model that
+     * hits that error; every real loopengine call passes `tools` (even an
+     * empty array is still the `tools` field being present), so there's no
+     * tools-vs-no-tools branch here to get this wrong on. */
+    reasoningEffort?: OpenAI.Chat.Completions.ChatCompletionReasoningEffort;
     /** Inject a pre-configured client instead of building one from apiKey — e.g. to pass a custom `fetch` in tests. */
     client?: OpenAI;
 }

package/dist/core/model-calls/openai-model-call.js

@@ -120,6 +120,7 @@ export function createOpenAIModelCall(options) {
                     function: { name: t.name, description: t.description, parameters: t.input_schema },
                 }))
                 : undefined,
+            reasoning_effort: options.reasoningEffort,
         });
         return toModelResponse(response.choices[0]);
     };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "loopengine",
-  "version": "0.1.43",
+  "version": "0.1.45",
   "type": "module",
   "description": "Runtime for tool-using AI agents with a transparent ReAct loop.",
   "license": "MIT",

package/dist/core/system-skills/system-skills/composio-large-outputs/SKILL.md

@@ -1,25 +0,0 @@
----
-name: composio-large-outputs
-description: How to retrieve a gateway tool's real output when its result says storedInFile is true instead of returning the data inline.
----
-
-# Gateway tools with a large result
-
-Some gateway tools (Composio-sourced ones in particular) return a small
-pointer object instead of their real output when the actual result is
-too large to return inline:
-
-```
-{
-  "successful": true,
-  "storedInFile": true,
-  "tokenCount": 10234,
-  "outputFilePath": "/tmp/.../SOME_TOOL_OUTPUT_xxxxx.json"
-}
-```
-
-When you see `storedInFile: true` in a tool result, the real data is
-**not** in that object — it's in the file at `outputFilePath`. Call
-`system_read_file` with that exact path to retrieve the actual content
-before answering. Don't guess at an answer, summarize from the pointer
-alone, or claim you don't have the data — read the file first.