30/30 paired runs used fewer tokens. Can an OpenCode Context Compiler improve task quality?

[github-actions[bot]]

We are looking for one or two technical collaborators to turn a manually controlled context experiment into an automatic, falsifiable Context Compiler for coding agents.

The signal

Across 10 task types, 30 paired A/B trials, and 66 real model calls:

• 30/30 pairs used fewer total tokens with a minimal Context Package;
• average total-token reduction was 50.8%;
• task-specific irrelevant/forbidden information leakage fell from 23.3% to 6.7%;
• raw requests, responses, token usage, and timing were retained.

This does not prove that an automatic compiler improves task success. It does show that coding agents often receive much more project context than they need, and that controlled selection is worth testing properly.

What we want to build

User task
  -> Intent / task-contract pass
  -> selected source reads only
  -> traceable Task Context Package
  -> execution with selected tools and permissions
  -> result, verification, and write-back candidates

The first prototype must fully control every OpenCode model request behind an explicit switch. When enabled, native project instructions, skills, tools, MCP definitions, permissions, history, and tool results must not bypass the compiler. Every actual request must be traceable.

Two ways to participate

1. Runtime / OpenCode — identify the real request-assembly seam and prove context isolation: Runtime Spike: fully control every OpenCode model request / 接管每轮上下文 #2
2. Context / Eval — design an independent experiment that can distinguish lower token use from better task outcomes: Independent Eval: prove whether the Context Compiler helps / 独立实验验效 #3

You can start with one critical comment, a two-page design review, or a small Spike. No long-term commitment is needed up front.

Who is behind it

The product side is led by a software product manager who has audited 2,033 deduplicated user messages from multiple coding-agent tools and distilled 128 real usage problems. Product definition, real tasks, acceptance criteria, documentation, and user-side evaluation are covered.

The most valuable first reply is not “interesting.” It is:

Where will this architecture leak hidden native context, select the wrong evidence, or optimize cost while silently damaging task quality?

Project brief: https://feiai2026.github.io/aios-context-compiler/

[github-actions[bot]]

@kshitijk4poor @Hona — you have worked on two failure surfaces that this experiment must measure honestly: preserving the active task across context compression, and aligning displayed context-token usage with provider data.

We are designing a switch-controlled OpenCode Context Compiler with full per-request traces. Before building more code, we would value your independent take on either question:

1. What evidence would convince you that the execution model never saw unselected project context?
2. Which usage metric is most likely to look correct while hiding the compiler's real cost or task regression?

The independent-eval task is here: #3

No endorsement or long-term commitment is expected. A counterexample, failed design pattern, or relevant implementation pointer would be enough.

[github-actions[bot]]

@darrenhinde — OpenAgentsControl's ContextScout, ContextManager, MVI principle, and OpenCode/Claude Code integration are the closest public prior art we have found to this product direction.

Rather than duplicate OAC, we are testing a narrower missing layer: a model-driven compiler that fully controls every provider request, records exactly which context and tools entered each loop, and runs an independent A/B protocol that separates token savings from task quality.

Two questions would help determine whether these efforts should connect:

1. Can OAC's current agent/plugin path prove that unselected native instructions, tools, skills, or history never bypass ContextScout and enter the final request?
2. What raw experiment supports the public 8,000 -> 750 tokens / 80% reduction claim, and which task-quality metric would you pair with it?

Our aggregate evidence and its limitations are public: https://github.com/feiai2026/aios-context-compiler/tree/main/evidence

If the boundary looks complementary, we would value a short design review and can explore an integration or shared experiment before discussing any deeper collaboration. A critical “this should live inside OAC instead” answer would also be useful.

[github-actions[bot]]

@chopratejas — Headroom is the strongest implementation we have found for provider-side, reversible context compression and traceable token reduction.

AIOS is exploring the layer immediately upstream: before compressing a request, decide which project instructions, decisions, skills, tools, permissions, history, and file evidence should enter that request at all. Our current evidence only validates manually frozen minimal packages, not the automatic compiler.

This suggests a concrete shared experiment rather than competing claims:

1. native OpenCode context;
2. native context + Headroom compression;
3. AIOS selection only;
4. AIOS selection + Headroom compression;

All four arms would use the same model and isolated tasks, with task success, critical-context recall, irrelevant-context inclusion, end-to-end tokens, cache effects, latency, and recovery calls reported separately.

Aggregate evidence and limitations: https://github.com/feiai2026/aios-context-compiler/tree/main/evidence

Would you be open to a short design review of this factorial baseline, or point us to the Headroom eval that would be safest to reuse? A “selection should live inside IntelligentContext” answer would also be a useful outcome.

[github-actions[bot]]

@Zeng-WH — LOCA-bench is the closest benchmark we have found for the evaluation problem behind this project: keep task semantics fixed, vary context growth and management strategy, and retain per-call trajectories, token statistics, workspaces, and execution-grounded outcomes.

We are building an OpenCode Context Compiler, but earlier prototypes repeatedly produced weak conclusions because request control, workspace isolation, and task-quality scoring were not rigorous enough. We have now published the aggregate from the one valid-but-limited experiment and are designing the next benchmark before more implementation.

Would this be a reasonable LOCA-style extension?

• coding-agent tasks instead of service MCP tasks;
• equivalent clean Git workspaces per arm and repetition;
• native OpenCode vs context selection/compilation strategies;
• controlled distractors, stale rules, hidden decisions, and context growth;
• execution tests plus critical-context recall, irrelevant-context inclusion, tokens, latency, and recovery calls;
• full request/tool trajectory replay.

Evidence and limitations: https://github.com/feiai2026/aios-context-compiler/tree/main/evidence

We would value a short methodology review, or explore contributing an OpenCode adapter/task family to LOCA-bench if that is more useful than inventing another benchmark. No endorsement or long-term commitment is expected.

[github-actions[bot]]

@ualtinok — Magic Context is now the closest working system we have found to the broader AIOS context direction: it owns OpenCode context management end to end, separates historian/dreamer/sidekick roles, tracks context by source, maintains durable memory in SQLite, and even ships an OpenCode interception diagnostics plugin.

That makes a critical comparison more useful than building in isolation. AIOS is testing a narrower per-task compiler: choose project instructions, decisions, state, skills, tools, permissions, history, and file evidence before every provider request, retain the exact request trace, and compare task quality as well as token cost.

Three questions would help establish the boundary:

1. Which OpenCode hook or interception point lets Magic Context prove what the provider actually received, and which native inputs can still bypass it?
2. Sidekick recall selects relevant memory every turn; what failure cases or evaluation evidence have you seen for false-positive recall versus missed critical memory?
3. Would a shared benchmark comparing native OpenCode, Magic Context, AIOS-style task selection, and a combined design reveal complementary value, or merely duplicate the same control plane?

Our current evidence is intentionally limited to manually frozen minimal packages: 30/30 paired trials used fewer total tokens, averaging -50.8%; it is not proof that an automatic compiler improves task success. Evidence and limits: https://github.com/feiai2026/aios-context-compiler/tree/main/evidence

A short architecture objection or benchmark review would already be valuable. If the layers are complementary, we would be interested in a small shared experiment before discussing any deeper collaboration.

[github-actions[bot]]

@Tarquinen — DCP and Sleev are highly relevant prior art for this project: model-directed surgical compression, protected content, provider-adjacent interception, and context management that can work across coding-agent harnesses.

We are testing the upstream selection problem. Before pruning or compressing conversation history, can a model-driven compiler decide which project rules, decisions, state, skills, tools, permissions, history, and file evidence should enter each OpenCode request at all — without silently losing task-critical context?

Our current 30-pair result only shows that manually frozen minimal Context Packages reduce tokens; it does not prove automatic selection improves task success. The next experiment needs to separate three effects:

• source selection before execution;
• conversation pruning/compression during execution;
• hidden native context that bypasses either layer.

From your experience moving DCP ideas into a harness-agnostic proxy, where is the most reliable place to observe or control the final request? And what task-quality regression metric would you require alongside token reduction?

Evidence and explicit limitations: https://github.com/feiai2026/aios-context-compiler/tree/main/evidence

A critical design comment, an implementation pointer, or a small shared benchmark would be a useful first step; no endorsement or long-term commitment is assumed.

[github-actions[bot]]

Two OpenCode contributors have worked directly on the context path I am trying to evaluate:

@rekram1-node — your changes around instruction ordering, restoring tail turns after compaction, and preserving relevant files address exactly the kind of silent context loss that can make an evaluation look successful while the task is actually misaligned. I would value your review of where a three-stage compiler should attach without breaking OpenCode's compaction and instruction semantics.

@Arcadi4 — your MCP server-instruction integration changes the request-level context surface directly. AIOS proposes selecting tool and MCP definitions per task instead of injecting every available capability. I would value your strongest objection to that design, especially around dynamic tool availability and reproducibility.

There is no paid bounty budget at this stage. The first ask is a design review, a counterexample, or one small independently testable open-source contribution. The evidence boundary and Runtime/Eval tasks are linked in the main post.

[github-actions[bot]]

@giuliastro — HarnessTrim is unusually relevant prior art for this project: it ships real OpenCode tool-result interception, a shared policy across five coding-agent harnesses, adapter telemetry, and a clear separation between measured results and hypotheses.

AIOS is testing the upstream selection problem. Before reducers or compaction run, can a compiler decide which project rules, decisions, skills, tools, permissions, history, and file evidence should enter each provider request at all? The two layers may be complementary, but only a controlled experiment should decide that.

A useful first comparison could be:

1. native OpenCode;
2. OpenCode + HarnessTrim;
3. AIOS-style source selection;
4. selection + HarnessTrim.

All arms would retain task success, must-keep context recall, irrelevant-context inclusion, end-to-end tokens, cache behavior, latency, and actual request traces. Where do you think the OpenCode plugin surface still prevents either layer from proving what the provider really received?

We have also reduced the entry point to a 60–90 minute challenge: one reproducible context bypass or one falsification task is enough to start: #5

There is no paid bounty budget. A critical design objection, shared benchmark idea, or small independently reviewable contribution would already be valuable.