opencode-titan 0.1.3 → 0.1.4

package/README.md

@@ -133,12 +133,17 @@ Here's a complete starting configuration:
 > [!TIP]
 > Mix providers to unlock real parallelism. Two Myrmidons running **different models** on the same provider run one after another; two Myrmidons on *different* providers run at the same time. Set `maxInstances` on a Myrmidon to run several copies of its *same* model in parallel on one provider.
 
+> [!TIP]
+> Running local models with fixed context windows? Set `maxContextLength` (in tokens) on those Myrmidons. Titan then knows each worker's budget and steers large or complex tasks away from small-context workers — avoiding the lossy mid-task history compaction that would otherwise wreck their output. Leave it off cloud/ample-capacity models.
+
 ## Meet the Agents
 
 ### 🧠 Titan — The Orchestrator
 
 Titan is the most intelligent agent in the fleet, and by far the slowest and most expensive to run. It never reads a file, runs a search, or writes a line of code if a Myrmidon can do it instead. Its entire purpose is strategic: decompose the goal, route each task to the best-suited Myrmidon, gate the quality of what comes back, and synthesize the final result.
 
+There are two deliberate exceptions where Titan works directly rather than delegating: **context-bound synthesis** (writing up findings, plans, or reports that live in its own accumulated context) and **foundational directive reads** — when you hand Titan a source-of-truth document to execute (a `PLAN.md`, spec, or task list), it reads that document itself, at full fidelity. Delegating the read would only return a lossy summary of the very directive meant to steer Titan's planning and routing.
+
 <table>
   <tr><td><b>Role</b></td><td><code>Planning, routing, quality-gating, and synthesis</code></td></tr>
   <tr><td><b>Prompt</b></td><td><a href="src/agents/titan.ts"><code>titan.ts</code></a> — dynamically built from your fleet</td></tr>
@@ -177,6 +182,7 @@ Myrmidons are the hands. Each executes a delegated task and reports back concise
 | `intelligence` | `number` (1–10) | ✅ | Reasoning capability rating; higher = better logic |
 | `modelType` | `"dense"` \| `"sparse"` | ✅ | `dense` for logic/reasoning, `sparse` for search/info gathering |
 | `maxInstances` | `number` (≥1) | | Max parallel instances Titan may run for this Myrmidon. Since instances share the same model (already in the provider's VRAM), they run concurrently on the same provider. Default: `1` |
+| `maxContextLength` | `number` (≥1) | | Hard context-window limit (in tokens) for this Myrmidon's model. Mainly for locally hosted models with fixed windows. When set, Titan avoids handing this worker large/complex tasks that would exceed its budget (and force a lossy compaction). Omit for ample-capacity/cloud models. |
 | `temperature` | `number` (0–2) | | Sampling temperature (default: `0.1`) |
 | `variant` | `string` | | Selects a named model variant defined by the provider for this `model` (see [Model variants](#model-variants)). Must match a variant key the provider declares for the model; leave unset to use the model's defaults |
 | `displayName` | `string` | | Friendly name shown in the UI |

package/dist/config/constants.d.ts

@@ -8,7 +8,7 @@ export declare const ALL_AGENT_NAMES: readonly ["titan"];
 export type AgentName = (typeof ALL_AGENT_NAMES)[number];
 /** Agents that cannot be disabled. */
 export declare const PROTECTED_AGENTS: Set<"titan">;
-export declare const DELEGATION_REMINDER = "<internal_reminder>DELEGATE EVERYTHING POSSIBLE TO MYRMIDONS. You are the slowest agent by far - your only job is planning, routing, and synthesizing results. Never do work a Myrmidon can handle. THE ONE EXCEPTION: context-bound synthesis. If a task's input is your OWN accumulated context \u2014 findings you gathered, results Myrmidons reported back, reasoning built up this session \u2014 do it YOURSELF. Delegating a summary/report/plan/file of what you found or decided strips the context the task needs (Myrmidons start blank), so the write-up stays with you. Parallelize aggressively: tool calls made in the SAME response turn run concurrently \u2014 always batch all ready task() dispatches into ONE response, never one per turn. SAY WHAT YOU DO: if you announce launching N Myrmidons, emit exactly N task() calls in that same response \u2014 never announce multiple then dispatch only one. Before ending a dispatch turn, count your task() calls and confirm they match the number of Myrmidons you named. The task() tool takes only subagent_type, description, and prompt \u2014 never pass any other parameters. </internal_reminder>";
+export declare const DELEGATION_REMINDER = "<internal_reminder>DELEGATE EVERYTHING POSSIBLE TO MYRMIDONS. You are the slowest agent by far - your only job is planning, routing, and synthesizing results. Never do work a Myrmidon can handle. EXCEPTION 1 \u2014 context-bound synthesis: if a task's input is your OWN accumulated context \u2014 findings you gathered, results Myrmidons reported back, reasoning built up this session \u2014 do it YOURSELF. Delegating a summary/report/plan/file of what you found or decided strips the context the task needs (Myrmidons start blank), so the write-up stays with you. EXCEPTION 2 \u2014 foundational directive reads: when the user hands you a source-of-truth doc (PLAN.md, spec, task list) to read and execute, READ IT YOURSELF at full fidelity \u2014 it drives how you plan and delegate, and a Myrmidon would only return a lossy summary of the very directive meant to steer you. (Ordinary file reads that just feed a worker's sub-task are still delegated.) Parallelize aggressively: tool calls made in the SAME response turn run concurrently \u2014 always batch all ready task() dispatches into ONE response, never one per turn. SAY WHAT YOU DO: if you announce launching N Myrmidons, emit exactly N task() calls in that same response \u2014 never announce multiple then dispatch only one. Before ending a dispatch turn, count your task() calls and confirm they match the number of Myrmidons you named. The task() tool takes only subagent_type, description, and prompt \u2014 never pass any other parameters. </internal_reminder>";
 /**
  * Sentinel substring used to detect whether {@link DELEGATION_REMINDER} has
  * already been injected into a system prompt, avoiding double-injection.
@@ -23,4 +23,4 @@ export declare const DELEGATION_REMINDER_SENTINEL = "DELEGATE EVERYTHING POSSIBL
  * at the point of each new user message keeps that behavior consistent — it
  * mimics the user manually prefixing "delegate this" onto every ask.
  */
-export declare const PER_MESSAGE_DELEGATION_REMINDER = "<delegation_directive>\nBefore you act on the user's message above, STOP and route it through delegation first.\n\n1. Decompose the request (including any follow-up tweaks, fixes, or refinements to prior work) into concrete units of work.\n2. For every unit that would require even a SINGLE tool call \u2014 reading/searching/editing files, running commands, testing, validating, looking things up, gathering information, or any mechanical work \u2014 you MUST delegate it to Myrmidons via task(). This applies to small iterative changes on the existing task just as much as to brand-new work. Do NOT do it yourself because it \"seems quick.\"\n3. EXCEPTION \u2014 context-bound synthesis: if a unit's real input is YOUR OWN accumulated context (findings you gathered, results your Myrmidons already reported back, reasoning or decisions from earlier in this session) and the deliverable is just expressing/organizing/persisting that context \u2014 e.g. writing a summary, report, plan, or markdown file of what was found/decided \u2014 do it YOURSELF. Delegating it would hand a blank-context Myrmidon a task it cannot do correctly, losing the very information the deliverable depends on. Writing a file is one cheap tool call; never delegate it just to avoid that call. You may still delegate any fresh lookups the write-up needs, but the context-bearing synthesis stays with you.\n4. Dispatch all independent units in parallel: emit one task() call per unit in a SINGLE response, and make the number of task() calls match the number of Myrmidons you announce.\n5. The ONLY time you may answer directly without delegating is when the request is trivially simple, purely conversational, and requires zero tool calls (e.g., clarifying a question, restating a plan, a one-word answer), OR when it is context-bound synthesis per point 3. When in doubt about fresh work, delegate; when in doubt about whether the task needs context only you hold, keep it.\n\nTreat this as if the user explicitly said: \"delegate this to your Myrmidons.\"\n</delegation_directive>";
+export declare const PER_MESSAGE_DELEGATION_REMINDER = "<delegation_directive>\nBefore you act on the user's message above, STOP and route it through delegation first.\n\n1. Decompose the request (including any follow-up tweaks, fixes, or refinements to prior work) into concrete units of work.\n2. For every unit that would require even a SINGLE tool call \u2014 reading/searching/editing files, running commands, testing, validating, looking things up, gathering information, or any mechanical work \u2014 you MUST delegate it to Myrmidons via task(). This applies to small iterative changes on the existing task just as much as to brand-new work. Do NOT do it yourself because it \"seems quick.\"\n3. EXCEPTION \u2014 context-bound synthesis: if a unit's real input is YOUR OWN accumulated context (findings you gathered, results your Myrmidons already reported back, reasoning or decisions from earlier in this session) and the deliverable is just expressing/organizing/persisting that context \u2014 e.g. writing a summary, report, plan, or markdown file of what was found/decided \u2014 do it YOURSELF. Delegating it would hand a blank-context Myrmidon a task it cannot do correctly, losing the very information the deliverable depends on. Writing a file is one cheap tool call; never delegate it just to avoid that call. You may still delegate any fresh lookups the write-up needs, but the context-bearing synthesis stays with you.\n4. EXCEPTION \u2014 foundational directive reads: if the user hands you a source-of-truth document to read and execute on (a PLAN.md, spec, design doc, task list, requirements file) that will drive how you plan and delegate the whole effort, READ IT YOURSELF at full fidelity. Delegating it returns a lossy summary of the very directive meant to steer your planning. This is narrow: it applies only when the document IS your controlling directive. An ordinary file read that merely feeds one worker's sub-task is still delegated.\n5. Dispatch all independent units in parallel: emit one task() call per unit in a SINGLE response, and make the number of task() calls match the number of Myrmidons you announce.\n6. The ONLY time you may answer directly without delegating is when the request is trivially simple, purely conversational, and requires zero tool calls (e.g., clarifying a question, restating a plan, a one-word answer), OR when it is context-bound synthesis per point 3, OR a foundational directive read per point 4. When in doubt about fresh work, delegate; when in doubt about whether the task needs context only you hold, keep it.\n\nTreat this as if the user explicitly said: \"delegate this to your Myrmidons.\"\n</delegation_directive>";

package/dist/config/schema.d.ts

@@ -14,6 +14,7 @@ export declare const MyrmidonConfigSchema: z.ZodObject<{
         sparse: "sparse";
     }>;
     maxInstances: z.ZodOptional<z.ZodNumber>;
+    maxContextLength: z.ZodOptional<z.ZodNumber>;
     temperature: z.ZodOptional<z.ZodNumber>;
     variant: z.ZodOptional<z.ZodString>;
     displayName: z.ZodOptional<z.ZodString>;
@@ -33,6 +34,7 @@ export declare const ChildAgentConfigSchema: z.ZodObject<{
         sparse: "sparse";
     }>;
     maxInstances: z.ZodOptional<z.ZodNumber>;
+    maxContextLength: z.ZodOptional<z.ZodNumber>;
     temperature: z.ZodOptional<z.ZodNumber>;
     variant: z.ZodOptional<z.ZodString>;
     displayName: z.ZodOptional<z.ZodString>;
@@ -66,6 +68,7 @@ export declare const PluginConfigSchema: z.ZodObject<{
             sparse: "sparse";
         }>;
         maxInstances: z.ZodOptional<z.ZodNumber>;
+        maxContextLength: z.ZodOptional<z.ZodNumber>;
         temperature: z.ZodOptional<z.ZodNumber>;
         variant: z.ZodOptional<z.ZodString>;
         displayName: z.ZodOptional<z.ZodString>;
@@ -80,6 +83,7 @@ export declare const PluginConfigSchema: z.ZodObject<{
             sparse: "sparse";
         }>;
         maxInstances: z.ZodOptional<z.ZodNumber>;
+        maxContextLength: z.ZodOptional<z.ZodNumber>;
         temperature: z.ZodOptional<z.ZodNumber>;
         variant: z.ZodOptional<z.ZodString>;
         displayName: z.ZodOptional<z.ZodString>;

package/dist/index.js

@@ -1,7 +1,7 @@
 // src/config/constants.ts
 var TITAN_AGENT_NAME = "titan";
 var DEFAULT_MAX_RESPONSE_WORDS = 1e3;
-var DELEGATION_REMINDER = `<internal_reminder>DELEGATE EVERYTHING POSSIBLE TO MYRMIDONS. You are the slowest agent by far - your only job is planning, routing, and synthesizing results. Never do work a Myrmidon can handle. THE ONE EXCEPTION: context-bound synthesis. If a task's input is your OWN accumulated context \u2014 findings you gathered, results Myrmidons reported back, reasoning built up this session \u2014 do it YOURSELF. Delegating a summary/report/plan/file of what you found or decided strips the context the task needs (Myrmidons start blank), so the write-up stays with you. Parallelize aggressively: tool calls made in the SAME response turn run concurrently \u2014 always batch all ready task() dispatches into ONE response, never one per turn. SAY WHAT YOU DO: if you announce launching N Myrmidons, emit exactly N task() calls in that same response \u2014 never announce multiple then dispatch only one. Before ending a dispatch turn, count your task() calls and confirm they match the number of Myrmidons you named. The task() tool takes only subagent_type, description, and prompt \u2014 never pass any other parameters. </internal_reminder>`;
+var DELEGATION_REMINDER = `<internal_reminder>DELEGATE EVERYTHING POSSIBLE TO MYRMIDONS. You are the slowest agent by far - your only job is planning, routing, and synthesizing results. Never do work a Myrmidon can handle. EXCEPTION 1 \u2014 context-bound synthesis: if a task's input is your OWN accumulated context \u2014 findings you gathered, results Myrmidons reported back, reasoning built up this session \u2014 do it YOURSELF. Delegating a summary/report/plan/file of what you found or decided strips the context the task needs (Myrmidons start blank), so the write-up stays with you. EXCEPTION 2 \u2014 foundational directive reads: when the user hands you a source-of-truth doc (PLAN.md, spec, task list) to read and execute, READ IT YOURSELF at full fidelity \u2014 it drives how you plan and delegate, and a Myrmidon would only return a lossy summary of the very directive meant to steer you. (Ordinary file reads that just feed a worker's sub-task are still delegated.) Parallelize aggressively: tool calls made in the SAME response turn run concurrently \u2014 always batch all ready task() dispatches into ONE response, never one per turn. SAY WHAT YOU DO: if you announce launching N Myrmidons, emit exactly N task() calls in that same response \u2014 never announce multiple then dispatch only one. Before ending a dispatch turn, count your task() calls and confirm they match the number of Myrmidons you named. The task() tool takes only subagent_type, description, and prompt \u2014 never pass any other parameters. </internal_reminder>`;
 var DELEGATION_REMINDER_SENTINEL = "DELEGATE EVERYTHING POSSIBLE TO MYRMIDONS";
 var PER_MESSAGE_DELEGATION_REMINDER = `<delegation_directive>
 Before you act on the user's message above, STOP and route it through delegation first.
@@ -9,8 +9,9 @@ Before you act on the user's message above, STOP and route it through delegation
 1. Decompose the request (including any follow-up tweaks, fixes, or refinements to prior work) into concrete units of work.
 2. For every unit that would require even a SINGLE tool call \u2014 reading/searching/editing files, running commands, testing, validating, looking things up, gathering information, or any mechanical work \u2014 you MUST delegate it to Myrmidons via task(). This applies to small iterative changes on the existing task just as much as to brand-new work. Do NOT do it yourself because it "seems quick."
 3. EXCEPTION \u2014 context-bound synthesis: if a unit's real input is YOUR OWN accumulated context (findings you gathered, results your Myrmidons already reported back, reasoning or decisions from earlier in this session) and the deliverable is just expressing/organizing/persisting that context \u2014 e.g. writing a summary, report, plan, or markdown file of what was found/decided \u2014 do it YOURSELF. Delegating it would hand a blank-context Myrmidon a task it cannot do correctly, losing the very information the deliverable depends on. Writing a file is one cheap tool call; never delegate it just to avoid that call. You may still delegate any fresh lookups the write-up needs, but the context-bearing synthesis stays with you.
-4. Dispatch all independent units in parallel: emit one task() call per unit in a SINGLE response, and make the number of task() calls match the number of Myrmidons you announce.
-5. The ONLY time you may answer directly without delegating is when the request is trivially simple, purely conversational, and requires zero tool calls (e.g., clarifying a question, restating a plan, a one-word answer), OR when it is context-bound synthesis per point 3. When in doubt about fresh work, delegate; when in doubt about whether the task needs context only you hold, keep it.
+4. EXCEPTION \u2014 foundational directive reads: if the user hands you a source-of-truth document to read and execute on (a PLAN.md, spec, design doc, task list, requirements file) that will drive how you plan and delegate the whole effort, READ IT YOURSELF at full fidelity. Delegating it returns a lossy summary of the very directive meant to steer your planning. This is narrow: it applies only when the document IS your controlling directive. An ordinary file read that merely feeds one worker's sub-task is still delegated.
+5. Dispatch all independent units in parallel: emit one task() call per unit in a SINGLE response, and make the number of task() calls match the number of Myrmidons you announce.
+6. The ONLY time you may answer directly without delegating is when the request is trivially simple, purely conversational, and requires zero tool calls (e.g., clarifying a question, restating a plan, a one-word answer), OR when it is context-bound synthesis per point 3, OR a foundational directive read per point 4. When in doubt about fresh work, delegate; when in doubt about whether the task needs context only you hold, keep it.
 
 Treat this as if the user explicitly said: "delegate this to your Myrmidons."
 </delegation_directive>`;
@@ -35,6 +36,11 @@ var MyrmidonConfigSchema = z.object({
   // Because instances share the same model (already loaded in the provider's
   // VRAM), they can run concurrently on the same provider. Defaults to 1.
   maxInstances: z.number().int().min(1).optional(),
+  // Maximum context window (in tokens) this Myrmidon's model can handle before
+  // it is forced to compact/truncate its history. Optional — mainly relevant
+  // for locally hosted models with fixed context limits. When present, Titan
+  // uses it to avoid handing large or complex tasks to small-context workers.
+  maxContextLength: z.number().int().min(1).optional(),
   temperature: z.number().min(0).max(2).optional(),
   variant: z.string().optional(),
   displayName: z.string().min(1).optional(),
@@ -386,7 +392,8 @@ function buildTitanPrompt(myrmidons, maxResponseWords = DEFAULT_MAX_RESPONSE_WOR
 - **Speed:** ${myrmidon.speed}/10 (${myrmidon.speed >= 7 ? "fast" : myrmidon.speed >= 4 ? "moderate" : "slow"})
 - **Intelligence:** ${myrmidon.intelligence}/10 (${myrmidon.intelligence >= 7 ? "strong reasoning" : myrmidon.intelligence >= 4 ? "adequate reasoning" : "limited reasoning"})
 - **Model Type:** ${myrmidon.modelType} (${myrmidon.modelType === "dense" ? "better at logic, planning, complex problem-solving" : "better at information gathering, fast lookups, broad search"})
-- **Best for:** ${bestFor(myrmidon)}
+- **Best for:** ${bestFor(myrmidon)}${myrmidon.maxContextLength ? `
+- **Context Window:** ~${myrmidon.maxContextLength.toLocaleString()} tokens (HARD limit \u2014 this worker cannot hold more than this. Do NOT hand it tasks whose instructions + expected exploration would exceed roughly this budget; give large/complex/many-file work to a bigger-context worker instead.)` : ""}
 ${myrmidon.displayName ? `- **Display Name (UI label only \u2014 NEVER use this to route or to refer to this worker; always say @${name}):** ${myrmidon.displayName}` : ""}
 </Myrmidon>`;
   }).join("\n\n");
@@ -457,6 +464,22 @@ ${myrmidon.displayName ? `- **Display Name (UI label only \u2014 NEVER use this
   const selfParallelMyrmidons = myrmidons.map((myrmidon, idx) => ({ myrmidon, idx })).filter(({ myrmidon }) => (myrmidon.maxInstances ?? 1) > 1).map(
     ({ myrmidon, idx }) => `- @myrmidon-${idx}: up to ${myrmidon.maxInstances} instances in parallel (same model on ${resolveProvider(myrmidon)} \u2014 safe to load once, run many)`
   );
+  const contextLimitedMyrmidons = myrmidons.map((myrmidon, idx) => ({ myrmidon, idx })).filter(({ myrmidon }) => typeof myrmidon.maxContextLength === "number").sort(
+    (a, b) => (a.myrmidon.maxContextLength ?? 0) - (b.myrmidon.maxContextLength ?? 0)
+  ).map(
+    ({ myrmidon, idx }) => `- @myrmidon-${idx}: ~${(myrmidon.maxContextLength ?? 0).toLocaleString()} tokens`
+  );
+  const contextBudgetGuidance = contextLimitedMyrmidons.length > 0 ? `
+## Context-Window Budgets
+Some Myrmidons declare a HARD context window \u2014 the maximum history their model can hold before it is forced to compact or truncate. A Myrmidon that compacts mid-task loses information and produces unreliable results, so you must never push one past its budget. Match task size to context budget:
+
+${contextLimitedMyrmidons.join("\n")}
+
+- Estimate each task's footprint: your instructions + the files/output the Myrmidon must read and produce to finish it. Route large, complex, or many-file tasks to workers with a large (or unspecified) context window; reserve small-context workers for tightly-scoped, self-contained tasks.
+- When a task is too big for the only capable worker's context, SPLIT it into smaller bounded sub-tasks that each fit \u2014 do not send one oversized prompt and hope it fits.
+- Do NOT, however, instruct a Myrmidon to artificially cut its work short to "save context." Scope the task to fit; let the worker do that scoped task fully.
+- Myrmidons without a declared context window are assumed to have ample capacity (typically cloud-hosted) \u2014 no special sizing needed.
+` : "";
   return `<Role>
 You are Titan \u2014 the most intelligent and capable agent in this system, but also by far the slowest. You are borderline unusably slow on this hardware. Your survival depends on one rule:
 
@@ -521,6 +544,17 @@ When you do produce such a deliverable yourself, you may still delegate the *mec
 
 Writing a file is a single tool call \u2014 cheap. Do NOT delegate a context-bound write just to avoid one tool call; the cost of losing context far outweighs the cost of the call.
 
+## The Second Exception: Foundational Directive Reads
+There is one more class of work you must do YOURSELF: **reading the source-of-truth document that will drive your own planning and delegation.** When the user hands you a foundational artifact \u2014 a PLAN.md, spec, design doc, task list, requirements file, or similar \u2014 and asks you to read it and execute on it, that document IS the input to YOUR job. It controls how you decompose the work and which Myrmidons you route it to.
+
+If you delegate that read, a Myrmidon returns a lossy, summarized paraphrase \u2014 and you would then plan the entire effort off a degraded copy of the very directive that's supposed to steer you. The information lost in summarization is exactly the detail you need to delegate correctly. So you read it yourself, at full fidelity, then plan and delegate from the complete picture.
+
+This is a NARROW exception \u2014 it is not license to read files whenever you feel like it. It applies only when the document is the controlling directive for the current effort. Distinguish carefully:
+- **User points you at a plan/spec/instructions to drive the whole task** (e.g. "read PLAN.md and start executing it", "follow the spec in DESIGN.md") \u2192 read it YOURSELF. It's the foundation of your planning.
+- **You need the contents of some file as raw material for a delegated sub-task** (e.g. "what does this util do", "find where X is defined", "refactor this module") \u2192 DELEGATE the read. It's fresh lookup work, not your controlling directive.
+
+Rule of thumb: if summarizing the document away would compromise how YOU plan and route, read it yourself. If it's just one more fact-gathering step feeding a worker's task, delegate it.
+
 ## Parallelization is Key
 You are slow. Your Myrmidons are fast \u2014 sometimes 50x faster. You have **${myrmidons.length} Myrmidon${myrmidons.length !== 1 ? "s" : ""}**. There is NO cap on how many you can run at once \u2014 dispatch all of them simultaneously if the work warrants it.
 
@@ -551,7 +585,7 @@ ${capabilityGuidance.join("\n")}
 - Each Myrmidon should receive a clear, bounded objective
 - Reference file paths and line numbers instead of pasting full file contents
 - Provide enough context for the Myrmidon to succeed independently
-
+${contextBudgetGuidance}
 </DelegationPhilosophy>
 
 <Workflow>
@@ -800,14 +834,22 @@ var OpenCodeDistributedDelegation = async (ctx) => {
       "[opencode-titan] WARN: No Myrmidons configured. Titan cannot delegate without Myrmidons. Add myrmidons to your config."
     );
   }
-  const heldLocks = /* @__PURE__ */ new Map();
+  const taskLocks = /* @__PURE__ */ new Map();
   const lockKey = (sessionID, callID) => `${sessionID}:${callID}`;
   const releaseLock = (key) => {
-    const held = heldLocks.get(key);
-    if (!held) return;
-    heldLocks.delete(key);
-    clearTimeout(held.timer);
-    held.release();
+    const entry = taskLocks.get(key);
+    if (!entry) return;
+    taskLocks.delete(key);
+    entry.cancelled = true;
+    if (entry.timer) clearTimeout(entry.timer);
+    entry.release?.();
+  };
+  const releaseLocksForSession = (sessionID) => {
+    for (const [key, entry] of [...taskLocks.entries()]) {
+      if (entry.sessionID === sessionID) {
+        releaseLock(key);
+      }
+    }
   };
   return {
     name: "opencode-titan",
@@ -828,14 +870,25 @@ var OpenCodeDistributedDelegation = async (ctx) => {
       if (!lockInfo) return;
       const { provider, model, maxInstances } = lockInfo;
       const key = lockKey(input.sessionID, input.callID);
-      if (heldLocks.has(key)) return;
+      if (taskLocks.has(key)) return;
+      const entry = {
+        provider,
+        sessionID: input.sessionID,
+        cancelled: false
+      };
+      taskLocks.set(key, entry);
       const release = await providerLocks.acquire(
         provider,
         model,
         maxInstances
       );
+      if (entry.cancelled) {
+        release();
+        taskLocks.delete(key);
+        return;
+      }
       const timer = setTimeout(() => {
-        if (heldLocks.has(key)) {
+        if (taskLocks.has(key)) {
           console.warn(
             `[opencode-titan] WARN: provider lock for "${provider}" (${key}) auto-released after timeout; the task may have been interrupted.`
           );
@@ -843,7 +896,8 @@ var OpenCodeDistributedDelegation = async (ctx) => {
         }
       }, PROVIDER_LOCK_TIMEOUT_MS);
       timer.unref?.();
-      heldLocks.set(key, { provider, release, timer });
+      entry.release = release;
+      entry.timer = timer;
     },
     // Release the provider lock once the subagent task completes (or errors).
     "tool.execute.after": async (input) => {
@@ -920,16 +974,15 @@ ${DELEGATION_REMINDER}`;
     // Clean up session tracking on deletion
     event: async (input) => {
       const event = input.event;
+      const props = event.properties;
+      const sessionID = props?.sessionID ?? props?.info?.id;
+      if (sessionID && (event.type === "session.idle" || event.type === "session.error" || event.type === "session.deleted")) {
+        releaseLocksForSession(sessionID);
+      }
       if (event.type === "session.deleted") {
-        const props = event.properties;
-        const sessionID = props?.info?.id ?? props?.sessionID;
-        if (sessionID) {
-          sessionAgentMap.delete(sessionID);
-          for (const key of [...heldLocks.keys()]) {
-            if (key.startsWith(`${sessionID}:`)) {
-              releaseLock(key);
-            }
-          }
+        const deletedID = props?.info?.id ?? props?.sessionID;
+        if (deletedID) {
+          sessionAgentMap.delete(deletedID);
         }
       }
     }

package/opencode-titan.schema.json

@@ -98,6 +98,11 @@
           "minimum": 1,
           "description": "Maximum number of parallel instances Titan may run for this Myrmidon. Since instances share the same model (already loaded in the provider's VRAM), they can run concurrently on the same provider. Defaults to 1."
         },
+        "maxContextLength": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "Maximum context window (in tokens) this Myrmidon's model can handle before it is forced to compact or truncate its history. Optional — mainly relevant for locally hosted models with fixed context limits. When present, Titan uses it to avoid handing large or complex tasks to small-context workers."
+        },
         "temperature": {
           "type": "number",
           "minimum": 0,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-titan",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Distributed delegation plugin for OpenCode — Titan orchestrator with parallel Myrmidons",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",