fetchPrepare does not send the local proxy mode to the server

[PewterZz]

Summary

The proxy stores a mode (inject or smart) in ~/.config/ergosum/mode.json and reads it on every request, but fetchPrepare never sends it in the /api/cli/proxy/prepare payload. The server gets messages, window_tokens, last_user_text, session_id — nothing else.

Where

src/proxy.ts:420-425

const result = await ergoRawPost(baseUrl, '/api/cli/proxy/prepare', token, {
  messages,
  window_tokens: windowTokens,
  last_user_text: queryContext.slice(0, 800),
  session_id: PROXY_SESSION_ID,
}, 800);

Meanwhile the mode UI exists — ergosum-proxy --mode inject|smart, status output at src/proxy.ts:682-689 — so users can flip modes and nothing observable changes server-side.

Impact

Either:

• The server already decides mode on its own (in which case the client-side mode config is vestigial and should be removed), or
• The server is supposed to honour the client's mode but can't (in which case /prepare is silently returning the wrong shape of context).

Both are confusing; both deserve a decision.

Proposed fix

Pick one path and apply it consistently:

1. Wire it up: add mode: cfg.mode to the fetchPrepare payload and have the server branch on it.
2. Remove it: delete the mode config / CLI surface entirely and let the server make the call.

Either is fine — the status quo (config exists, has no effect) is the bad option.

[PewterZz]

@coderabbitai summarize this issue and suggest an approach

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 8 --repo TwoErgoSum/Ergosum-Proxy --json title,body,labels,comments,assignees,state

Length of output: 2002

---

🏁 Script executed:

#!/bin/bash
# Check how cfg.mode / mode is used throughout the codebase
rg -n "cfg\.mode|mode\.json|inject|smart" --type ts -C 3

Length of output: 2404

---

🏁 Script executed:

#!/bin/bash
# Look at fetchPrepare and surrounding context
sed -n '400,460p' src/proxy.ts

echo "---"
# Also check if cfg.mode is used anywhere else in proxy.ts beyond status display
rg -n "cfg\.mode\|readProxyConfig\|ProxyMode\|writeProxyConfig" src/proxy.ts -C 3

Length of output: 1959

---

🏁 Script executed:

#!/bin/bash
# Check if mode is referenced anywhere in handleRequest or the main request path
sed -n '460,620p' src/proxy.ts

Length of output: 6444

---

@PewterZz, here's a summary of the issue and a concrete recommendation:

---

Issue Summary

Issue #8 — fetchPrepare does not send the local proxy mode to the server

The proxy supports two modes — inject and smart — selectable via ergosum-proxy --mode inject|smart and persisted in ~/.config/ergosum/mode.json. However, the mode is never used at runtime:

• handleRequest never reads cfg.mode.
• fetchPrepare sends only messages, window_tokens, last_user_text, and session_id to /api/cli/proxy/prepare — mode is absent.
• The mode only appears in the status display (lines 682–689), so users can flip it all day with zero observable effect.

There is also a secondary bug: startProxy spawns the background server process without forwarding --mode, so even if mode were wired into fetchPrepare, the background process would silently revert to the inject default every time.

---

Suggested Approach: Wire It Up (Option 1)

Given that the two modes have distinct, meaningful semantics:

• inject — context injected into the system prompt (what the proxy always does today)
• smart — server-side compression of old turns

…removing the mode would discard intentional product surface. The better path is to wire it up. Here's what needs to change:

1. Pass mode into fetchPrepare

// src/proxy.ts — fetchPrepare signature
async function fetchPrepare(
  baseUrl: string,
  token: string,
  messages: AnthropicMessage[],
  windowTokens: number,
  queryContext: string,
+ mode: ProxyMode,          // ← add
): Promise<PrepareResult | null> {
  const result = await ergoRawPost(baseUrl, '/api/cli/proxy/prepare', token, {
    messages,
    window_tokens: windowTokens,
    last_user_text: queryContext.slice(0, 800),
    session_id: PROXY_SESSION_ID,
+   mode,                   // ← send to server
  }, 800);
  ...
}

2. Read config in handleRequest and thread mode through

// src/proxy.ts — inside handleRequest, where fetchPrepare is called
+ const cfg = readProxyConfig();
  const prepared = await fetchPrepare(
    baseUrl, token, parsed.messages, windowTokens, queryContext,
+   cfg.mode,
  );

3. Fix startProxy to forward --mode to the background process

// src/proxy.ts — startProxy spawn args
const child = spawn(
  process.execPath,
  [
    process.argv[1],
    '--foreground', '--verbose',
    '--port', String(port),
    '--window', String(windowTokens),
+   '--mode', readProxyConfig().mode,   // ← forward persisted mode
    ...(options.oauthBridge ? ['--oauth-bridge'] : []),
  ],
  { detached: true, stdio: ['ignore', logFd, logFd] },
);

Note: Steps 1–2 alone fix the payload gap, but Step 3 is needed to ensure the background daemon actually honours the stored mode rather than defaulting to inject on every start.

Would you like me to open this as a plan for code changes?