Just to get the free version, I ended up ruining several paid accounts.

[asdzxc252 (TXT)]

Source Code Remediation Plan

1. Fix Loss of Request Semantics (Highest Priority)

Modify internal/web/protocol_compat.go:

• Fully receive and process:
  • instructions
  • max_output_tokens
  • parallel_tool_calls
  • tool_choice
  • reasoning
  • include
  • temperature
  • text
  • service_tier
  • context_management
  • previous_response_id
• Send instructions to the upstream as the highest-priority instruction on every turn; it must not be lost during conversion.
• Explicitly return unsupported_parameter for unsupported parameters; silently ignoring them is prohibited.

This is the main source-code problem behind the current behavior of “acting stupid, not doing the work, and repeatedly asking questions.” The official Responses specification also clearly states that previous_response_id does not automatically inherit the previous turn’s instructions; they must be handled correctly on every turn. Responses API documentation

2. Refactor the Tool-Call State Machine

Modify:

• internal/web/model_tool_router.go
• internal/web/server.go
• internal/web/tool_state.go

Use a fixed state machine:

Receive request
→ Restore session and task state
→ Determine whether tools are needed
→ Output function_call
→ Wait for the result corresponding to the call_id
→ Merge tool evidence
→ Continue reasoning
→ Continue calling tools when necessary
→ Validate the result
→ Final answer

The following must be guaranteed:

• Do not compress a long task into the last approximately 3,000 characters before making a judgment.
• The tool router must receive the system instructions, current task, tool definitions, and task progress.
• call_id must match strictly; calls must not be mixed across turns or accounts.
• Do not call a tool again after its result has already been submitted.
• When parallel_tool_calls=false, generate only one call.
• Set a maximum number of tool rounds, duplicate-call detection, and idempotency protection.
• Long tasks must not restart from the beginning when switching accounts.

3. Add a Server-Side “Task Ledger”

Add a unified task-state structure to store:

• The original user goal
• Non-negotiable constraints
• Steps already executed
• Tool results already obtained
• Remaining steps
• Current account
• Upstream conversation/session
• Failure and switching records

This ensures that even after context trimming, a connection drop, or an account switch, the model still knows “what needs to be done and how far it has gotten” and does not suddenly ask about the task again.

4. Redesign Context Management

Modify:

• internal/web/prompt_budget.go
• internal/web/response_session.go
• internal/web/sessions.go

Divide the context into three levels:

1. Permanent task instructions and user constraints
2. The current task ledger and tool evidence
3. Ordinary conversation history

When trimming, remove ordinary history first; the task goal and tool evidence must not be removed.

Also:

• Limit the number of response aliases retained per session.
• The stable session key must not participate in ordinary alias eviction.
• Retain old previous_response_id values within a reasonable window.
• Prevent sessions.json from growing without limit with each tool round.
• Session-write failures must be recorded and explicitly reported; the system must not appear to answer successfully only to lose continuity on the next turn.

5. Strict Account Ordering, Session Stickiness, and Isolation

Modify the account-scheduling code:

• Use a fixed 1 → 2 → 3 → 4 order; random selection is prohibited.
• Normal conversations must remain bound to the current account.
• Unused accounts must not establish upstream sessions or send warm-up requests.
• Switch to the next account only for failures that are eligible for switching.
• After a successful switch, migrate the current task ledger and session mapping as a whole.

Errors must be categorized; do not “randomly switch accounts for every error”:

• 429/quota exhausted: switch to the next account in order.
• Authentication failure, proxy/network connection failure, or upstream 5xx: switch accounts in order before the first output.
• Parameter errors, tool-result errors, or an invalid previous_response_id: do not switch accounts; return a clear error.
• Once output to the client has begun: do not switch accounts and replay the request, to avoid executing tools repeatedly.
• Client cancellation: do not switch accounts or penalize the account.

6. Correct Misrepresented Model Capabilities

The current source code maps gpt-5.6-sol to Microsoft 365’s ChatHub tone; it is not the actual OpenAI GPT-5.6 Sol.

Remediate as follows:

• Retain the gpt-5.6-sol compatibility alias to prevent client configurations from breaking.
• Clearly identify the following in /v1/models:
  • backend=microsoft-365
  • compatibility_alias=true
  • Actual effective context size
• Manage the server according to the actual input budget of approximately 96K; it must not claim 1.05M to clients while internally processing only about 96K.
• If genuine GPT-5.6 Sol is needed in the future, add an independent OpenAI upstream; do not disguise it by merely changing the name. The official model does support a 1.05M context window and native tool calling, but the M365 mapping layer does not automatically acquire these capabilities. GPT-5.6 Sol documentation

7. Perform Complete Acceptance Testing Instead of Testing Only One Sentence

Before deployment, testing must cover:

• The Hermes, OpenCode, and Codex clients.
• Multi-turn plain-text conversations.
• Context retention over 30 and 100 turns.
• Serial and parallel tool calls.
• Continuation after more than 50 rounds of tool results.
• Long-running tasks lasting 5–15 minutes.
• Connection drops and recovery mid-request.
• 429, 401, 5xx, network timeouts, and malformed JSON.
• Ordered account switching and isolation of unused accounts.
• Error correction after tool failures.
• Prevention of duplicate execution of tools with side effects.
• Overly long instructions.
• Valid and invalid previous_response_id scenarios.
• End-to-end tasks that actually complete files, run tests, and read results.

Acceptance criteria:

• Clear tasks must not trigger unnecessary follow-up questions.
• Tool success must not be fabricated.
• Completed tools must not be executed again.
• Account switching must preserve the original task context.
• Unused accounts must generate zero requests.
• Long tasks must not end silently.
• All failures must return structured errors.
• Compare the old and new versions using the same batch of tasks in an A/B test.

[James]

The expert is a person of few words. Is this a guide for modifying sub2api? Is there a repository with the changes already made?

[xiaoyi669 (1)]

Awesome.

[LazyChara (Matsuki_LazyChara)]

Got it,

[Mike123]

All hail the legend

[Jarvis-d]

Ah​Ah

[user80 (贺煦修)]

Thanks for your hard work, boss!