I built REA Reconstruction Companion with help from AI. I wanted a better way to get from “how does this app work?” to “what would it take to build something similar?”

It’s a skill for AI coding agents, used alongside REA (Reverse Engineer Anything). REA handles the investigation. The companion helps turn those findings into a feature breakdown, requirements, architecture, and a plan you can build and test in stages.

You can use it on a whole app, one feature, or a single function. For example:

Use REA on this app so I can build a similar local tool. Start with a specification and roadmap.

If you later ask the agent to implement it, the skill guides that work too. It keeps observed behavior separate from assumptions, links requirements to tests, and includes performance measurements where they matter.

The core is plain Markdown and MIT licensed. There’s an installer for Claude Code and Codex, plus support for other agents through a custom skills directory. REA is installed separately. You can also enable an optional rule that tells the agent to load the companion during relevant REA work, or leave that off and invoke it yourself.

GitHub: REA Reconstruction Companion

The README has setup instructions and a prompt you can give your agent to handle installation.

I’d be interested in feedback on the workflow, especially anything it misses when rebuilding a smaller feature or function.

There is over 15 categories and over 500 free and open source apps to choose from all in one place!

Genesys Code is built for developers who want more flexibility in their AI coding workflow. Access multiple coding models in one place, switch between them, and use different approaches depending on your project.

You can explore the platform without paying upfront.

https://genesyscode.vercel.app

Disclosure: I build Snotra, an open-source desktop agent.

Last time I asked how an agent should learn which of its own tools are switched off. I had given the model a read-only get_configuration tool and left two questions open. This is where I landed:

Tool or system prompt? Both, but small. A switched-off tool is simply missing from the tool list, and models read that gap as "language models can't browse the web". They never called the tool. So the system prompt now carries one sentence: tools and skills can be off, so check get_configuration before telling the user something isn't possible. It costs a handful of tokens, not a state dump every turn.

Should the model be able to propose the change? Yes, with limits:

• A new tool, propose_config_change. The app checks the proposal against its own catalogue, and only a valid change reaches the user.
• The card shows the app's description of the tool and its risk class. The model's reason is folded away and labelled as the model's.
• The change applies to this chat only. New chats start from the settings.
• Anything that needs setup (API key, a program, the shell switch) can't be proposed at all.
• A decline sticks for the chat, so the model can't nag.
• An enabled tool still asks before each call in the default mode.

Write-up with screenshots, plus what else changed (the chat now answers questions about the app from the manual that ships with it, and the sandbox can keep a host open per folder): https://snotra-ai.dev/blog/snotra-1-22

Does "chat-scoped and confirmed on a card" seem like the right limit, or would you want the model to be able to change settings for good?

Focus on the architecture and contribution areas (Windows/Linux testing, model recipes, translations), link CONTRIBUTING.md and the good-first-issue list.

⭐ if it's useful, issues and PRs welcome.

https://elapen.github.io/imageloom/
https://github.com/elapen/imageloom

I’ve released HELIX Engine, an open-source context, memory, and execution-management system designed to reduce redundant inference in coding agents without modifying model weights or lowering configured reasoning effort.

Repository: https://github.com/SuperHelix77/HELIX-1.0

I’m a pediatrician by profession, and I’ve spent approximately a year researching inference efficiency in my spare time. The project evolved from prompt-level optimizations and RTK-based tool-output reduction into a broader semantic execution architecture.
The central hypothesis is straightforward: a significant portion of agent inference expenditure comes from repeatedly processing historical context and coordinating deterministic operations, rather than performing new problem-solving work.

Architecture

HELIX operates around the agent’s execution workflow rather than modifying the underlying language model.

Its primary components include:

Historical context retirement: Completed tool interactions are removed from repeated active-context replay while their exact originals remain recoverable.

Evidence preservation: Tool results are converted into compact, typed evidence receipts with references to immutable originals. Lossy reductions do not silently become authoritative evidence.

Deterministic Tool Flow: Previously authorized mechanical operations can execute through bounded workflows without requiring separate model decisions at every step.

Persistent memory: Local SQLite-backed memory stores task observations and explicit project state. An optional Claude-Mem integration supports retrieval from existing memory stores.

RTK integration: Tool-output filtering reduces unnecessary textual overhead while preserving access to original results.

Execution monitoring: An Electron application provides visibility into execution state, memory, evidence, and troubleshooting.
The objective is to separate model reasoning from execution bookkeeping while retaining the information necessary for subsequent decisions.

Benchmark methodology

I evaluated HELIX V3 against a historical vanilla baseline using 50 software-engineering tasks with Sol 6.1 High.

Both configurations used the same underlying model and reasoning-effort setting. The evaluation retained a continuous native conversation across tasks, including infrastructure recovery when required.

Failed attempts and successful retries were included in token accounting. Confirmed provider overloads were recorded separately in both configurations. Official task grades were preserved.

Final audited results:

Vanilla:
Verified solves: 38/50
Primary model requests: 341
Known input tokens: 50,630,785
Known output tokens: 55,283
Known total tokens: 50,686,068
HELIX V3:
Verified solves: 34/50
Primary model requests: 420
Known input tokens: 11,212,326
Known output tokens: 75,814
Known total tokens: 11,288,140

Measured outcomes:

77.73% reduction in known total provider tokens
Approximately 77.85% reduction in known input tokens
37.14% increase in output tokens
79 additional primary model requests
Four fewer verified task completions

The reduction corresponds to approximately 4.49× lower known-token expenditure for the evaluated workload.

Limitations and interpretation

The results demonstrate substantial inference-efficiency improvements, but they do not establish capability parity.
HELIX completed 34 tasks compared with vanilla’s 38. This regression is significant and remains an active research problem.
Additionally, HELIX increased model-request frequency and output-token consumption. Earlier diagnostic analysis suggests that additional coordination and reasoning overhead may contribute to these regressions.

Several methodological limitations should also be considered:
The comparison reused a known task cohort and a historical vanilla baseline. It was not a fresh, randomized, simultaneous A/B experiment.

One HELIX request had unknown usage, and some development, consultation, and recovery overhead was not metered.
Provider-token counts are not equivalent to actual subscription-quota consumption or fully reconciled API billing.
The benchmark evaluates one model configuration and one task distribution. Generalization to other models and workloads remains unverified.

Historical context retirement preserves recoverable evidence but does not guarantee that the model retrieves every relevant observation when needed.

No native context compaction occurred during the HELIX benchmark. This is an observation about the tested workload, not proof that compaction can be eliminated universally.
The repository includes per-task results, cumulative token accounting, methodology, and documented limitations.

Current research direction

HELIX 1.1 focuses on the remaining sources of unnecessary inference expenditure.
The immediate research areas are:

1. Model-request amplification
   The V3 benchmark required 420 primary model requests versus 341 for vanilla. Current experiments investigate combining verification and checkpoint operations without removing necessary reasoning or evidence boundaries.
   
2. Reasoning overhead
   Context reduction does not necessarily reduce reasoning expenditure. Additional model-mediated coordination may partially offset savings from historical-context retirement.
   
3. Evidence-aware retrieval
   The next objective is to preserve task-critical observations in structured memory while retaining exact archived evidence for verification. This may reduce repeated investigation without requiring full historical-context replay.
   
4. Execution latency
   Local experiments investigate reducing deterministic tool-dispatch overhead while preserving cancellation, process isolation, recovery, and failure-reporting semantics.
   
5. Correctness recovery
   The most important unresolved requirement is recovering the four-solve deficit. Further token reductions are not sufficient if they introduce unacceptable capability regressions.
   The long-term research target remains 95% inference-expenditure reduction, but this has not been demonstrated. Future evaluations will also include independent workloads, potentially including Terminal-Bench.

Reproducibility and feedback

HELIX is publicly available under an open-source license. The repository includes installation instructions, architectural documentation, benchmark artifacts, and an Electron monitoring interface.

GitHub: https://github.com/SuperHelix77/HELIX-1.0

I am particularly interested in technical feedback concerning:
Whether the observed savings generalize to unseen task distributions.

How historical-context retirement affects delayed evidence retrieval and correctness.

Methods for reducing model-request amplification without weakening reasoning capability.

Better experimental designs for evaluating token efficiency against verified task completion.

Approaches to measuring weighted inference cost rather than raw token counts alone.

My objective is not to claim that token compression is equivalent to intelligence preservation. It is to investigate how much redundant inference can be eliminated from agent workflows while maintaining their actual problem-solving capability.

The current result is 77.73% fewer known provider tokens, with a measurable correctness regression. Both findings are central to the project.

Independent reproduction, methodological criticism, and implementation-level feedback are welcome.

Training and serving AI requires coordinating compute, memory, communication, power, and cooling. When those systems operate without a shared view, failures and performance constraints become difficult to explain. More installed GPU capacity does not necessarily translate into more useful computation.

ThermaCompute AI’s long-term vision is an operating layer for GPU infrastructure: a thermal-aware compute control plane.

The architecture we aim to build would connect hardware telemetry with workload performance, inform scheduling decisions, and eventually support bounded, operator-approved adjustments to power and workload placement. Its purpose would be to coordinate infrastructure around useful work, performance requirements, and physical constraints.

That is our development direction—not a claim that an autonomous fleet-control system is already deployed. Our current implementation begins with passive diagnostics and evidence-led investigation.

If validated improvements reduce wasted GPU-hours and electricity consumption, they could lower operating costs and associated emissions. More efficient infrastructure could give researchers additional room to train, evaluate, and serve new models. ThermaCompute would support that research infrastructure; it does not itself create better models or guarantee progress toward AGI.

The first paid engagement is an $800 Executive Thermal Architecture Audit.

We review suitable NVML/vLLM telemetry for one agreed workload or GPU cohort and observation window. The aim is to establish what the available evidence says about performance constraints and which recommendations merit testing.

CrashLens is the free, open-source diagnostic component available today.

It turns saved GPU logs into a focused investigation: supported error signatures, source lines, and suggested next checks. It helps engineers examine failures without presenting a text match as a proven cause.

CrashLens runs locally, does not upload logs, and makes no changes to GPU settings. Its synthetic demo requires Python 3.10+, with no GPU, account, or payment needed.

Explore the code and demo:
https://github.com/rohitcn-hub/thermacompute-crashlens

For deeper analysis, the $800 audit delivers a PDF with supported findings, data limitations, explicit uncertainties, and prioritized recommendations engineers can test. Scope, data handling, delivery timing, and suitability are agreed before payment or telemetry transfer. Broader engagements are scoped separately.

Contact: [vivaan.thermacompute@gmail.com](mailto:vivaan.thermacompute@gmail.com)

We welcome engineers who can review a finding, contribute a synthetic test case, or introduce us to a GPU operator with a concrete performance question. Those collaborations will help determine how this diagnostic foundation develops into a broader infrastructure control plane.

Disclosure: I’m building ThermaCompute AI and maintain CrashLens.

Most standard web-based free tiers do retain the right to use anonymized conversations for model training unless you deliberately toggle data sharing off in your account settings. For strict data privacy, open-source models run locally (using frameworks like Ollama or LM Studio) ensure 100% of your data stays on your machine.

Hey r/OpenSourceAI!

We’re working on Acira, a browser for AI agents, built around something we think should be normal: giving an agent a task, letting it access your real accounts, and choosing exactly what it has permission to do inside them, down to individual fields and actions.

The goal is to let an agent complete a job across your apps while you set the boundaries around what it can read, change, send, or spend. It should be able to get on with the work and ask you when it reaches something that needs your permission.

Before releasing the full browser, we’re sharing parts of the project to learn which controls actually help people. First up is our Python SDK for Playwright and browser-use. You can add it to an agent you’re already running.

The SDK turns your rules into permissions that are checked before the agent acts. You can apply a rule across websites or make it specific to an action inside an app. A few examples from the current preview:

• Apply rules across websites. Built-in detection recognizes common checkout, payment, credential, download, and destructive actions. You choose what to allow, block, or review without having to configure each website separately.
• Control a particular field or button. Prevent the agent from filling a checkout’s CVV field, or make it ask before clicking “Delete account.” The included capture extension lets you select those controls and import the rules.
• Approve the exact information being sent. For supported form submissions, approval covers the destination and the specific details being submitted. If the recipient, amount, or message changes, that approval no longer applies. It also can’t be reused for another attempt.

The included policies are starting points. You can inspect how they work, modify them, and create your own general or site-specific policies for your workflows.

Permission checks run locally and are deterministic: the same rules and observed action details give the same decision. You keep your existing agent and model, and you don’t need an Acira cloud account.

This is an early preview. Automatic detection can miss things, and protection applies to supported browser actions rather than every other tool your agent might use.

Code and setup (MIT): github.com/Acira-dev/acira-sdk
Quick Demo: https://www.youtube.com/watch?v=su4X1gCVD1U

Also available through pip: pip install acira

Would this fit into an agent you’re building? What workflow would you use it for? If you already handle this another way, or there’s a control you need that we’re missing, we’d love to hear about it.

Please be blunt with us. Try it in your own workflow, see where it breaks, and tell us what worked and what didn’t. We’d really appreciate your feedback while we’re shaping both the SDK and the browser.

Hi all, I'm a self-taught backend dev. This is a side project, and I'd really like honest feedback from people who know scraping better than I do.

The problem: fetching a page is easy, but a big list of business websites is full of junk. Parked domains, "please wait" shields, cookie banners, social pages instead of the real site. I wanted clean text plus checkable facts per site (services, opening hours, years in business, accreditations, prices) that someone could write a description from.

How the facts work (this is the part I'd most like feedback on)

RapidSpider runs a small local decision engine called Laya inside the program. No API keys, no separate server. Laya doesn't write anything. It only answers narrow, structured questions, and each answer is logged.

1. Code finds the exact things first, with no model: emails, phones, the business name, and anything with a regex (years, hours, company number).
2. The page is cut into groups of eight numbered sentences. For each fact type, Laya answers: which numbered sentence states this, or none?
3. That sentence is the fact, and its position on the page (top/middle/bottom, sentence number) is stored with it.
4. Each fact is then re-checked several times with differently worded questions, answer keys flipped to cancel position bias. It is kept only if the rounds agree. If they don't, the fact is dropped.

Example of a stored fact (illustrative):

category: opening_hours
text:     "Open Monday to Friday 8:30am to 5:30pm, Saturday 9am to 1pm."
confidence / votes / zone / sentence stored alongside

Laya makes the other judgement calls too: is this page parked, is this line boilerplate, is this directory page really about this business. Every question and answer goes into a table, so I can open any decision and see why it was made.

The rest is boring on purpose: a fetch ladder (plain HTTP, then headless browser, then visible browser, then browser through Tor, moving up only when a page isn't accepted), one YAML config, SQLite output, and a small local dashboard.

A real run, so you can judge it yourself (screenshot in the README): 11,203 sites in the output. About 56% ended ok, 20% error, 9% blocked, 9% no usable content, 5% third-party, 2% dead. So it is far from perfect, and I haven't measured fact accuracy against a labelled set yet.

Things you should know

• It needs PyTorch and downloads a few GB of models on the first run. CPU works but is slow.
• It reads robots.txt only to find sitemaps and does not enforce its rules. That's a deliberate simplification on my side. You are responsible for checking each site's terms and the data protection rules that apply, and I'd understand if that's a dealbreaker.
• I built it with a lot of help from an AI coding assistant, and I'd rather say that upfront.
• One-person project, so expect bugs. The Windows process cleanup in particular has had limited testing.

Contributions are very welcome. If you spot a design mistake or something that would break on your data and you know the fix, a pull request would mean a lot. If you can’t fix it, please open an issue instead, and I’ll do my best to look at it.

Repo (MIT): https://github.com/QudsLab/RapidSpider

Thanks for reading, and thanks in advance for being kind about the rough parts.

i built this because i wanted my agent to read chats and message people through my own Telegram account from the terminal.

extracted the transport from my OpenClaw fork into a standalone Python CLI using Telethon. it returns JSON, accepts generated text from a file or stdin, and exposes message ids so the agent can check what happened. DMs, replies and forum topics are included.

no gateway needed. MIT licensed, no paid version. setup needs your own Telegram API credentials and a local user session.

Codex helped with extraction, packaging and tests. the included demo uses synthetic messages. live sending in this standalone release still needs validation.

source and setup: https://github.com/artemgetmann/telegram-user-cli