Long-running Codex/Claude sessions work best when you stop thinking of them as “one giant conversation” and start treating them as a continuous work process. The idea is to define a clear objective with /goal, let the agent work in cycles: analyze → execute → test → fix → continue — and keep important state outside the conversation in files like goal.md, plan.md, state.md, progress.md, and failures.md. The key rule is: As long as there is a clear, safe next action aligned with the objective, keep going without waiting for new instructions. For runs lasting many hours or even days, the ideal setup is: clear objective + success criteria + state files + compaction + continuous testing + controlled autonomy. And the main conclusion from the 11-day experiment is this: very long sessions can work, but the real limit is not the size of the JSONL file — it is the point where continuity starts to reduce quality, cost efficiency, or operational effectiveness. Examples: https://inematds.github.io/execucao-longa/guia/en/

RSI ARRIVED 2 YEARS EARLY. And I really think you need to understand what this means. RSI stands for Recursive Self-Improvement. In simple terms, it means AI starts helping to improve AI. Today, humans still do most of the important work around AI: we define the goals, build the systems, create the experiments, review the results, and decide what should change. With RSI, more and more of that improvement loop starts to happen automatically. The AI does something. It measures the result. It analyzes what worked. It proposes a change. It tests that change. It keeps what worked. And then it does it again. That is the big difference. A normal AI executes. An RSI system can execute, evaluate, learn, improve, and repeat. And the impact of this can be enormous. It can accelerate software development, science, robotics, model training, agent development, and infrastructure optimization. Instead of a human team manually running every experiment, AI agents can run thousands of experiments, compare the results, and keep improving the system. That is the exciting part. But it is also the scary part. Because if AI starts improving systems faster than humans can understand, test, and supervise them, we may no longer fully understand how those systems are evolving. And there is another problem. Agents do not always improve things in the way we expect. They can find shortcuts. They can exploit weaknesses. They can manipulate evaluation systems. They can get the “right” result through the wrong process. So with RSI, a good result is not enough. We also need evaluation, observability, security, human oversight, limits, rollback, and clear objectives. The easiest way to understand RSI is in three levels. Level 1: Better responses. The AI gives you a better answer. Level 2: Better agents. The AI improves its prompts, memory, tools, workflows, or strategy. Level 3: Recursion. One improvement helps create the next improvement, and the cycle keeps going. And that is the part people need to understand.

Forget JEV - LAYA is an open-source Forget the idea of using a massive LLM for every single decision. LAYA points to a different future. LAYA is an open-source, self-hosted, multilingual, non-autoregressive decision engine built to make fast, structured decisions without generating text token by token. Instead of sending everything to GPT, Claude, or Gemini, LAYA can operate as a fast decision layer that can: - classify requests; - measure urgency; - estimate risk; - identify intent; - detect fraud or prompt injection; - select which agent should act; - select which AI model should be called; - decide when a task can be automated. - The idea is simple: INPUT → DECISION → ACTION LAYA works with three main decision primitives: choice — selects one option from a set. score — evaluates something on a scale. noul — returns a probability between 0 and 1. The project includes specialized checkpoints for English, multilingual workloads, and typed-decision workflows, as well as a Router that can automatically select the most appropriate model for each input. According to benchmarks published by the project, some decisions can be made in tens of milliseconds on a GPU, with batching allowing hundreds of decisions per second. But speed is not the most important part. The real power of LAYA is specialization. You could build: LAYA Sales LAYA Support LAYA Finance LAYA Security LAYA Legal LAYA HR LAYA Agent Router Each one specialized in the repetitive decisions required by a specific business process. And because LAYA is open source, you can run it on your own infrastructure, fine-tune it for your domain, calibrate its probabilities, and integrate it directly into your agents and internal systems. This changes the architecture of AI. Instead of: event → large LLM → response we can build: event → LAYA → decision → right agent → right model → action LAYA can effectively become the nervous system of an agent architecture, filtering thousands of events and calling larger reasoning models only when they are actually needed.

Union Alpha is a new stealth AI model available through OpenRouter. Key numbers: - 256K context window - 128K max output - $0 input - $0 output - Around 20 tokens/second - Around 10 seconds initial latency - Multimodal - Tool calling supported - Structured/JSON outputs supported The biggest attraction is simple: 256K context + 128K output + free access. For now, the provider behind Union Alpha remains undisclosed, so its real origin and long-term pricing are still unknown. https://openrouter.ai/stealth/union-alpha

BMAD x Superpowers x ECC Separates BMAD, Superpowers, and ECC in a very simple way: BMAD = think and structure the project. Superpowers = execute the engineering work. ECC = expand the agent environment with additional capabilities. For small projects and everyday development tasks, such as features, bugs, refactoring, testing, and debugging, the recommended setup is: Claude Code + Superpowers For large or complex projects, the recommended flow is: BMAD → Superpowers BMAD handles the strategic side: discovery, project definition, PRDs, UX, architecture, epics, stories, and planning. Then Superpowers handles execution: understanding the task, planning, implementation, testing, debugging, review, and verification. ECC does not replace either of them. Instead, it works as an additional infrastructure layer that can provide capabilities such as: persistent memory security hooks automations MCP integrations specialized agents research and data collection specialized reviewers language- and framework-specific skills shared standards across projects The decision logic can be summarized like this: Not sure what to build? → BMAD Already know what to build and need to implement it properly? → Superpowers Need an extra operational capability for the agent or environment? → ECC The recommended configuration is: Claude Code + Superpowers → the default for most development work. BMAD → Superpowers → for larger or more complex projects. ECC → added selectively when there is a concrete need. The key idea is not to install or use the entire ECC stack by default. Treat ECC as a modular catalog of capabilities. Add memory, security, hooks, specialized agents, or other components only when they solve a real problem. In one sentence: BMAD thinks, Superpowers builds, and ECC enhances.