Feature Request: Support context window for BYOK custom models

[seeyou19992006]

Problem

When using BYOK (Bring Your Own Key) custom models, Droid does not display context length and usage percentage in the UI. This information is only available for built-in models.

Current Behavior

• The customModels configuration in settings.json supports maxOutputTokens but has no field for context window size
• Droid does not query the proxy server to retrieve model metadata

Proposed Solutions

Option 1: Add contextWindow field to customModels

{
  "customModels": [[
    {
      "model": "gpt-5.2-codex",
      "displayName": "GPT 5.2 Codex (Pool)",
      "baseUrl": "https://my-proxy.com/v1",
      "apiKey": "xxx",
      "provider": "openai",
      "maxOutputTokens": 32000,
      "contextWindow": 128000
    }
  ]
}

Option 2: Auto-detect from proxy server

For users using LiteLLM or similar proxies, Droid could query the /model/info endpoint to automatically retrieve max_input_tokens and max_output_tokens:

GET /model/info -> {"max_input_tokens": 128000, "max_output_tokens": 32000}

Use Case

We use LiteLLM proxy to pool multiple API keys for load balancing. Our proxy already has model metadata configured, but Droid cannot display the context usage information that would help us monitor token consumption during long sessions.

[zwen64657]

I wholeheartedly agree. I've always had doubts about how the context is progressing

[harshav167]

Root Cause (from binary analysis of v0.88.0 / v0.89.0)

I reverse-engineered the Droid binary to find exactly why this happens. The context window display and compaction threshold are completely decoupled from model metadata and the maxContextLimit field.

The hardcoded compaction limit

There is a single hardcoded constant in the binary that controls both the /context display AND the auto-compaction trigger:

// Minified variable name changes between builds (was $vH, now QvH in v0.89.0)
var QvH = 250000;

This constant is used in two places:

1. The /context command display:

// Always uses the hardcoded constant, never reads model metadata
let maxTokens = QvH;  // 250000
// ...
display(`${modelName} · ${used}/${maxTokens} tokens · compaction at ${maxTokens}`)

2. The agent loop compaction trigger (after every LLM response):

let totalTokens = (usage.inputTokens || 0) + (usage.outputTokens || 0) + (usage.cacheReadInputTokens || 0);
if (totalTokens > QvH) {  // > 250000
    // triggers compaction
    await compact("threshold", { conversationHistory, systemMessage, allTools, sessionId });
}

Why maxContextLimit doesn't work

The maxContextLimit field does exist in the Zod schema and is correctly parsed and stored:

// Schema (Uy0)
maxContextLimit: z.number().optional()

// Parser (HUR)
maxContextLimit: typeof R.maxContextLimit === "number" ? R.maxContextLimit : void 0

But no code ever reads it for compaction or display. It's parsed, stored in memory, and never consumed. Dead code — a planned feature that was never wired up.

The org-level Enterprise Controls also support maxContextLimit in custom model definitions, but same problem — it's accepted by the API but ignored by the binary.

Workaround: Binary patch

Until Factory wires up maxContextLimit to the compaction logic, this patch script replaces the hardcoded 250000 with 999999 (~1M tokens):

https://gist.github.com/harshav167/12413f2301d2283b4a530ae7b21f887c

The script:

• Auto-detects the minified variable name (survives variable renaming across builds)
• Same byte length replacement (6 digits → 6 digits) so no binary corruption
• Re-codesigns for macOS
• Idempotent (safe to re-run)
• Must be re-run after each Droid update

What Factory needs to do

The fix is straightforward — wire the existing maxContextLimit field to the compaction logic:

// In /context command:
let customModel = getCustomModels()?.find(m => m.id === currentModelId);
let maxTokens = customModel?.maxContextLimit ?? QvH;  // fallback to default

// In agent loop:
let effectiveLimit = customModel?.maxContextLimit ?? QvH;
if (totalTokens > effectiveLimit) { compact() }

The schema, parsing, and storage already exist. It just needs to be read.