Analysis Engine, made to engineers get a quick overview of their codebase, security scannings, vulenrability checks and dependency checks.
It also comes with skills giving Claude Code/Codex/Gemini build in native linting capabilities for Dockerfiles, Helm charts, k8s manifest alongside validation and assessment capabilities.
Leave it to the agent tbh, I spend more time on testing the worktrees - but even agents can do that for you - or if you add playwright MCP, make TDD both on frontend/backend and e2e pipelines - merge when cases work and tests approved
Yes if you operate with worktrees, its actually possible to operate up to 5-10 at least I've succeeded with that multiple times.
I think whats important is, that you keep atomical small tasks and increments, and whenever possible merge things. to many hanging worktrees can quickly also become a nightmare managing
Clever engineering. But worth thinking about before you actually use it.
The pitch is "use Claude Code without Anthropic limits." What's actually happening is you're getting GPT/Codex responses dressed up to look like Claude. Those are different models with different failure modes. If you picked Claude Code because you trust how Claude reasons about your code, this swaps it out silently. No indication at the UI level.
The ToS angle is what I'd worry about more. Anthropic isn't being hurt here, they're not serving the requests. But OpenAI is, under a Codex subscription that definitely wasn't priced for "act as someone else's backend." Using your ChatGPT sub as a proxy for a third party product is the kind of thing that gets your account killed. Could also expose you to liability, depending on how seriously OpenAI wants to push it.
The project's own disclaimer says something about how use "may be subject to the terms of service of third party platforms." That one sentence is doing a heroic amount of work.
If the real complaint is that Claude's API is too expensive, fair enough. But this doesn't solve that. It just shifts the bill and the risk onto OpenAI's infra and your account.
I'm working on a fun project I call OpenFAST, which essentially tries to solve the context transitioning - but its still in early days and haven't released anything yet.
I think one of the bigger issues, is the o(n) orchestration to agent calls that often feels uncontrolled .. ending up making the orchestrator of sub-agents the main bottleneck due to the large context it sometimes ends up with.
I'm working on an idea where agents delivers briefs & deliveres as real artifacts, and then having each spawned sub-agent read briefs, and if they need further information pick up the delivery for that specific brief.
It helps drift detection across agents, and the best part is orchestrator only delegates jobs, but doesn't do much further than that.
Whenever sub-agents has delivered their tasks, orchestrator can then read a merged brief/delivery for that specific round.
So far it helps cutting that extra tool call where each sub-agent answers the orchestrator - but it also helps the orchestrator only dwelve into deliveries which it believes are relevant rather than trying to understand and comprehend every small detail.
I can share more when I'm a bit further maybe you could get some inspiration here.
In what settings do you mean - there are multiple strategies, I think building your own compaction layer in front seems a bit over-kill ? have you considered implementing some cache strategy, otherwise summary pipelines - I made once an agent which based on the messages routed things to a smaller model for compaction / summaries to bring down the context, for the main agent.
But also ensuring you start new fresh context threads, instead of banging through a single one untill your whole feature is done .. working in small atomic incrementals works pretty good
Couldn't agree more ... Especially how platforms like Stitch 2 are eliminating the barriers for non-technical individuals to actually get pretty decent UI/UX experience ..