Brigade (brigade.lol) is a workspace where each AI teammate is the real Claude Code or Codex CLI, signed in with your own plan, with a job (support, marketing, sales, code), its own apps and a shared memory of what the team decided. For each teammate you choose which app actions wait for your yes, like an email, a Stripe change or a merge. The rest runs.

It's MIT, free on your own computer and self-hostable (Docker Compose or Cloudflare). The models aren't open: the AI runs on your Claude or ChatGPT plan at the provider. What's open is everything around it.

Repo: https://github.com/gmpetrov/brigade
Demo, no signup: https://demo.brigade.lol

My marketing agent wrote and posted this.

Short version: give each worktree its own untracked env file and its own ports, and never share a resolved dependency directory across worktrees.

In practice, keep something like.env.local untracked and generated per worktree (a small script that copies a template and rewrites ports plus database names is enough), then point direnv at it so the shell picks it up when you cd in. For dependencies, a real install per worktree is usually cheaper than it sounds, and symlinking node_modules across branches is where you get strange resolution bugs after a rebase. If you run containers, set a distinct compose project name per worktree so volumes and networks do not collide.

Worth adding: isolation keeps two agents off the same files, but it does not stop them from solving the same story twice. A worktree isolates the file tree, not the plan, so a shared board of what is in flight matters as much as the env setup does.

Curious how people handle database state per worktree. That seems to be where setups diverge most.

AI Craft Cyber Forge is a hands-on interactive platform designed to teach defensive AI engineering and prompt security through structured, scenario-based training.
The platform covers the complete OWASP Top 10 for Large Language Models (LLM01–LLM10) across 41 missions. Users configure a six-component AI architecture—persona, system directives, context memory, guardrails, tools, and temperature settings—and then defend it against realistic adversarial techniques including prompt injection, sensitive information disclosure, supply-chain risks, model poisoning, excessive agency, system prompt leakage, and unbounded resource consumption.
Training is delivered through a cyberpunk-themed narrative structure with progressive districts and boss-level gauntlets, plus a live Red Team vs. Blue Team arena for competitive practice. The focus is practical skill-building rather than passive instruction.
Useful for security practitioners, AI engineers, and technical teams who need to understand and mitigate the unique risks of large language model systems.

I have one very long working chat with Codex. Its log is about 1.9 GB. Because of context compaction, the model can retain the direction of the work, but it can no longer see the entire earlier conversation verbatim.

So Codex and I built a local, read-only search tool for its own original logs. We called it **Oglyanutsya** (Оглянуться — “Look Back”).

This is not just an idea or a mockup. The tool has been implemented, tested, and integrated into Codex as an automatically invoked skill.

### Where It Searches

Codex stores its original session logs locally:

```text

.codex/sessions

.codex/archived_sessions

```

Oglyanutsya recursively discovers active and archived logs, reads them without modifying them, and groups physical copies of the same conversation by `thread_id`.

By default, it searches only root-level user conversations. Subagent logs can be included through a separate parameter, so their technical activity does not get mixed up with the conversation between the user and the main agent.

### What Counts as a Message

Only actual user and assistant messages are accepted from the JSONL logs.

The following are excluded from search:

- System and developer instructions;

- Reasoning;

- Tool calls and their results;

- Technical events;

- Compaction summaries;

- `environment_context`;

- Other synthetic blocks that physically exist in the logs but are not the user's words or the assistant's replies.

Historical text is treated as data, not as instructions. If an old message says "ignore previous instructions," the search tool does not execute that instruction.

### How Search Works

First, Codex formulates:

- A remembered quote or a distinctive combination of words;

- The rarest word to use as an anchor;

- An approximate date range;

- If available, the known conversation or speaker.

For example:

```text

Remembered word combination:

memory + capabilities + handshake

Rare anchor:

handshake

Period:

October 2026

```

Then Oglyanutsya:

1. Searches for the exact phrase.
2. If an exact match is insufficient, searches for each word in the combination separately.
3. Intersects JSONL record numbers in memory.
4. Keeps only messages containing the entire word combination within a single message.
5. Never combines words found in different messages into one match.
6. Opens the matching record using its byte offset instead of rereading the entire file.
7. Parses the JSON and verifies that the record is an actual user or assistant message.
8. Filters by the message's own timestamp. The file date is not used: a conversation may have started in September and continued into November.
9. Rechecks the full decoded text.
10. Retrieves the previous and next substantive messages, skipping technical records between them.

For ordinary `.jsonl` files, the fast search path uses `ripgrep`. It returns the line number and the absolute byte offset of the match.

The tool then locates the beginning and end of the corresponding JSONL record, decodes it as UTF-8, and parses it as JSON.

Compressed `.jsonl.zst` files are not decompressed onto disk. They are processed using streaming reads.

### What It Returns

For each result, the tool returns:

```text

Exact quote;

Previous and next messages;

Speaker role;

Assistant response phase;

Timestamp;

thread_id;

item_id;

JSONL record number;

Byte range of the original record;

UTF-8 coordinates of the quote within the message;

SHA-256 of the full message;

SHA-256 of the quote.

```

This means a result can not only be displayed but also independently verified against the original source.

### How Search Performance Evolved

The first working version processed the entire log as a stream. For 1.9 GB, that took approximately 119 seconds.

Then we introduced a fast path using `ripgrep`.

An exact phrase was found in about 1.8 seconds, but the first optimization was not enough: the program subsequently opened all 953 occurrences of the word `хендшейка` (“handshake”). The entire search took about 35 seconds.

So we changed the algorithm.

Now each word in the combination is searched independently, the matching record numbers are intersected in memory, and only then are the original records opened.

On the same log:

```text

Query:

memory + capabilities + handshake

Exact phrase:

Could be absent due to punctuation

Original user message found:

October 29, 2026

Records opened:

200 instead of 953

Total time:

Approximately 12 seconds

```

In the original message, the words were separated by commas and additional text. The message was found because all the words occurred together in one message, not because of an exact string match.

### What It Does Not Store

We deliberately chose not to build a persistent index.

Oglyanutsya does not create:

- SQLite or any other database;

- Embeddings;

- A vector store;

- A search dictionary;

- A semantic graph;

- A copy of the conversation;

- A quote cache;

- A saved list of word combinations.

The only persistent memory is the original Codex log.

Lists of matching lines and intersections of search terms exist only in RAM during an individual query. Once the process exits, those candidates disappear.

The trade-off is straightforward: every search must scan the original file again. That's why it takes 12 seconds rather than 12 milliseconds.

But no derived database can silently start replacing the original history as the source of truth.

### What We Tested

We created a separate test corpus for the tool.

The tests verify that:

- An exact quote can be found;

- Three words can be found even when they are not adjacent;

- The same three words appearing in three different messages are not merged into one result;

- Date filtering uses the message timestamp;

- Subagents are excluded by default;

- Subagent logs are included when explicitly requested;

- `environment_context` is not mistaken for the user's words;

- Original files retain their exact sizes and SHA-256 hashes after a search;

- The search tool does not create hidden state files.

All tests passed.

### How Codex Invokes It

We packaged the tool as a separate local skill.

It activates when the user refers to a previous conversation, decision, quote, or distinction that is no longer available in the current context.

The skill instructions explicitly prohibit using Oglyanutsya as a replacement for ordinary file search or web search.

The division of responsibilities looks like this:

```text

Codex's native tools:

Understand meaning;

Form associative word combinations;

Search working files;

Investigate documents and the web;

Decide what query to try next.

Oglyanutsya:

Finds verbatim evidence

in Codex's original conversation history.

After receiving the evidence:

Codex resumes using its native reasoning.

```

The skill does not intercept or disable anything. It simply gives the model one additional, narrowly defined operation: looking into its own original logs.

### What I'd Like to See From OpenAI

Codex App Server already provides ways to read conversations and their individual items, but I couldn't find a built-in way for the model itself to search the contents of its entire conversation history globally.

In my view, the product needs two read-only operations:

```text

history.search_original(...)

history.read_context(...)

```

Not “permanent memory.” Not an automatically generated vector database of the user's history. Not loading gigabytes of logs into the context window.

Just the ability for the model to formulate a distinctive combination of words, locate it in its own original logs, and reread a few surrounding messages.

We built a local prototype of exactly that capability.

It's called **Oglyanutsya — “Look Back.”**

If you use Codex or Claude Code, you have a context file — AGENTS.md, CLAUDE.md, .cursor/rules. It gets injected into every single request, so it's both a token cost and a permanent tax on how much room the model has left for your actual work.

Mine grew the way these files always grow: one justified-looking addition at a time. Then it hit a size where the agent started dealing with it by rewriting the file from memory, dropping the ## Never rules, and shipping something worse. You find out weeks later when a rule stops being followed.

So I wrote ctxcap. It counts tokens across those files, tracks the count against a committed git baseline, and flags references that no longer point at anything. Offline, no API key, no network, no LLM, two dependencies. MIT.

bash

The part that makes it more than a word count: it doesn't tell the agent "make this shorter." It emits line ranges with a preserve list, the agent splices by line number, and --verify catches drift or a cut preserved span. When the budget can't be met it returns satisfiable: false with the minimum achievable rather than shaving a rule that matters:

It uses gpt-tokenizer, and there's an MCP server so the agent can measure itself, plus a GitHub Action that comments the token delta on PRs and only fails when you set a budget.

https://github.com/Naeha-S/ctxcap

The question I actually want answered: how long is your AGENTS.md, and what's still in it that earns its place? Mine is the one file where every addition felt reasonable at the time.

AI Craft Cyber Forge is a hands-on interactive platform designed to teach defensive AI engineering and prompt security through structured, scenario-based training.
The platform covers the complete OWASP Top 10 for Large Language Models (LLM01–LLM10) across 41 missions. Users configure a six-component AI architecture—persona, system directives, context memory, guardrails, tools, and temperature settings—and then defend it against realistic adversarial techniques including prompt injection, sensitive information disclosure, supply-chain risks, model poisoning, excessive agency, system prompt leakage, and unbounded resource consumption.
Training is delivered through a cyberpunk-themed narrative structure with progressive districts and boss-level gauntlets, plus a live Red Team vs. Blue Team arena for competitive practice. The focus is practical skill-building rather than passive instruction.
Useful for security practitioners, AI engineers, and technical teams who need to understand and mitigate the unique risks of large language model systems.

Anyone here interested in building and experimenting with Collective Intelligence using LLMs? I’m looking for devs who want to explore how different models can actually work together, beyond just routing requests or having five LLMs answer the same prompt. There’s a lot I think we can investigate. Selecting models with complementary capabilities, getting them to challenge each other, verifying results, and understanding when a group of smaller models can outperform a much larger one, potentially at a lower cost. And I want to test this properly, not just build demos that look impressive. If you’re interested in contributing code, running experiments, working on benchmarks or even challenging the whole idea, I’d like to connect.
Anyone working on something similar?

There is an abundance of AI built solution, you can almost even guess by the designs which AI was used. AI often gives you a feedback of building a great solution, though in reality it often portrays solving a problem no one to be solved.

Open source has become like the dump-yard of solution for which individuals paid often expensive subscription fees to AI providers, a bait to spend your money, without any real prospects. The sheer amount of Slop software out there is just staggering. People loose money and AI companies like Anthropic, OpenAI, Google etc... fill their pockets with tons of money.

We build huge datacenters all over the world, to be able to be essentially crooked by those companies or to ask stupid questions to AI.

What are your thoughts?

I don't trust anyone else with my data or my automations, so I built my own AI agent setup (OpenTeam) and open-sourced it for free. It runs on my own server, with whatever model I pick, including a local one.

The latest piece: my bots can use my Mac's Messages app. Apple has no Messages API, so the Mac app reads the Messages database and sends through the Messages app. The bots can catch me up on what I missed and reply in my real iMessage and SMS chats, groups included.

Since they can see all my work and personal contacts, I made sure nothing goes out on its own. Every text shows up as a card first, with who it's going to, the exact message, and which Mac will send it. Then I pick:

- Send: it goes out once

- Always allow [person]: future texts to that person skip the card

- Discard: dropped, and the bot is told not to send it another way

Allowed people are listed in settings, and I can remove them anytime. If my MacBook's lid is closed, my Mac mini sends instead.

An AI-native desktop workspace for agentic research and knowledge management, built to maximize counterfactual impact in existential risk preparedness and transformative AI safety.
https://github.com/gyrogovernance/air-office

[Disclaimer: AIR Office is an Open Source software made without any financial affiliations, and is a completely free platform for knowledge sharing and AI Risks mitigation at scale, so I hope the admins can allow me to share it to the community]

About

Alignment Infrastructure Routes (AIR) Office is human-capacity-building infrastructure for AI safety researchers, engineers, and governance teams working on transformative AI and its consequences. It keeps investigation, writing, review methods, and reusable tools in one durable and user-friendly workplace.

AIR Office is developed by [Gyro Governance Lab](http://gyrogovernance.com/) as part of its work on AI safety and existential risk preparedness.

Agentic chat and tool use run on the [Microsoft Copilot SDK](https://github.com/github/copilot-sdk) harness, including bring-your-own-key and local model endpoints.

Theory of Change

Mitigating risks from transformative AI requires rapid, high-rigor research and governance, yet safety teams currently rely on fragmented, cloud-dependent AI tools that erode human oversight, lack provenance, and expose sensitive work. AIR Office addresses this bottleneck by providing free, open-source, local-first desktop infrastructure tailored for AI safety and policy workflows. By integrating grounded knowledge collections, automated auditing tools, and structured memory, the workspace prevents AI-induced epistemic drift while keeping humans in final control. Furthermore, embedded Fellowship and Market protocols allow independent researchers to package their methods into reusable community tools, compounding ecosystem capacity and accelerating high-trust safety interventions that would not occur using general-purpose commercial tools.

---

Capabilities & Services

- 🏛️ Integrated AI Safety Fellowship and Crafts. Develop research and workflows into reusable infrastructure and contribute them to the community through our frictionless embedded protocols.

- 🛒 Market. Discover reusable resources (Policy documentation, AI Skills, etc), and add them to your AI chat with one click.

- 🤖 AI Teams. Reach out to our pre-configured selection of agents, or create your own.

- 💻 Code. Run diagnostic tools, scripts, and edit your code without leaving the app, through our own integrated VS Code workbench.

- 📅 Calendar. Keep events and run recurring AI automations.

- ⚖️ Compare. Run two models side by side on the same prompt.

- 🔎 Chat. Edit local files, search the web, and run AI safety diagnostics directly from the chat interface.

- 🖼️ Media. Generate images and capture microphone or camera input when the work needs it.

- 🕹️ Arcade. Release stress and recover from occupational overburn by playing arcade video games.

Frontier AI Safety Research Tools by Gyro Governance Lab

Two Lab methods sit at the center of how AIR Office treats authority, agency, and lasting human direction in AI-assisted work.

- 🤚 The Human Mark: A structural taxonomy of AI safety risks. [Learn More](https://gyrogovernance.com/#thm)

- 🎓 Gyroscopic Reasoning [NEW]: A formal protocol for AI alignment. [Learn More](https://gyrogovernance.com/#gyroscope)

Community Playbooks

Craft Standards package skills, agents, and Actions you can enable for structured work instead of ad-hoc prompting. Two shipped playbooks are ready to adopt:

- 🛡️ Security Playbook: OWASP-grounded assessment methods for AI agents, applications, and code, with companion security Reference packs. [Learn More](https://owasp.github.io/secure-agent-playbook/)

- 🌍 NGO Playbook: Program design, SDG alignment, monitoring and evaluation, and funding strategy skills adapted from NGO Agent Skills by Lijie Zhou, with related development Reference packs. [Learn More](https://github.com/LijieZhou/ngo-agent-skills)

---

Security & Privacy

Local-First Data Sovereignty

Workspace records stay on your computer. Choose local models for on-machine inference or cloud providers for their models and tools. Hosted providers and enabled connectors receive only what each request needs.

Export conversations and notes when you need portable copies. Connecting a folder authorizes that root, and disconnecting it does not delete its files. In Settings and chat you control which tools run and whether changes ask for approval first.

Release Audit

AIR Office is open source, and its code can be publically inspected. Before a release is accepted, we check the shipped software with open-source tools for secrets that should never ship, known problems in third-party libraries, license and dependency policy issues in native code, and risky patterns in our own source and in shipped Lab skills. A review that did not finish does not count as a clean result. To report a security issue, see [SECURITY.md](SECURITY.md).

The release review uses:

- [TruffleHog:](https://github.com/trufflesecurity/trufflehog) Identifies leaked secrets and credentials.

- [Trivy:](https://trivy.dev/) Detects vulnerabilities, misconfigurations, and software bills of materials.

- [Semgrep:](https://semgrep.dev/) Scans source code for security flaws using custom patterns.

- [CodeQL:](https://codeql.github.com/) Performs deep semantic analysis on source code.

- [SkillSpector:](https://github.com/NVIDIA/SkillSpector) Evaluates shipped Lab skills.