Readme

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

Readme AI

I mined 9 months (3M tokens) of my Codex sessions into a plugin to maximize my workflows

I direct AI agents all day (Codex, Claude, Cursor). They've gotten good at remembering facts I tell them, but they still don't understand how I actually work: what I reject, what "done" means to me, the judgment calls I make without explaining them. That part I never wrote down anywhere. So I ran an experiment on myself. I mined 9 months of my local session logs, 1,656 sessions, about 3 million tokens, to see what they'd reveal. (Codex and Cursor go back furthest and the Claude stretch is more recent, so this isn't leaning on Claude's 30-day log retention.) 95% of a coding log is noise: tool output, file dumps, the agent talking to itself. So it keeps only the messages I actually typed, dedupes the repeats, and keeps patterns that show up across many separate sessions instead of one-off moments. What came back wasn't about code. It was about judgment: - I reject generic UI on sight and pull toward high contrast and tight spacing - I work reference-first: I copy a thing I like rather than describe it - I hate being handed five options. Pick one and show me - I write short, no hype, and I start from the problem or the mechanism, never a preamble None of that is in my notes or my CLAUDE.md. I never wrote it down. It was just sitting in how I worked and I'd never looked. And that's the point. Once my agent reads this, it stops handing me generic defaults and starts making the calls I'd make. Less re-explaining myself every session, faster workflow. Two things people always push back on, so let me get ahead of them: "Why not just ask the model to summarize the logs?" You can't fit 9 months into one context window, and if you tried you'd burn most of it on that 95% noise. It isn't a summary. It keeps only your words and ranks a trait by how many independent sessions confirm it. One pass guesses. Corroboration across sessions is the signal. "Doesn't GPT/Claude already have memory?" Memory is what you told it, curated, and locked to one tool. This is mined from the raw logs across Codex, Claude and Cursor, the stuff you never said out loud, into one file you own and can read. The sharpest pushback I've gotten: the real endgame isn't a mirror that acts like you, it's a counterweight that keeps you honest, catches your contradictions and pushes back when you're kidding yourself. I think that's right, and it's where I want to take this next. I invite you to try it and give honest feedback: https://github.com/ohad6k/ditto One honest heads up: the first mine reads a big chunk of your history, so it burns a fair amount of tokens up front. I'm working on making it token-efficient (bounded, cached, incremental) so reruns are basically free. Wanted to flag that before you run it. submitted by /u/BiosRios [link] [comments]

OpenSourced My Whole Marketing Operations [Solo Agency With 33 Clients]

https://preview.redd.it/cvsa1a8kv9ch1.png?width=2880&format=png&auto=webp&s=80ee5e31aa05695c728334a1d0869a231397bf00 Hey y'all, been in the marketing world for nearly a decade always in client fulfillment like media buying, web dev, seo, etc. Started my own agency and built a whole system around automating 99% of my processes. From client communication, updates intakes to building out full sites, managing google ads, Facebook ads, Funnel optimizations. Was going to release and sell a software allowing people use this optimization system but decided to open source it after a round of beta testers (it got kinda annoying maintaining everything). Hope you like it! submitted by /u/Nat_Syno [link] [comments]

Karpathy LLM Wiki for your Codebase

Hello good people of r/OpenAI , I want to show CodeAlmanac. It is a self updating wiki for your codebase. How it works is: You install a CLI Choose your agent It goes through your codebase, and makes an initial wiki then, based on your chats with Claude/Codex, every 5 hours, it takes a look at your chats and updates the wiki based on the important things you discussed Since it is completely local, and markdown, your agents can refer it. A lot of important context about your project actually lives in your conversations, and now its easily queryable for the agents. This wiki is structured, organized into topics, and put into a sqlite db. So, we can do queries like: codealmanac search --topic auth and Ta-Da, the agent gets all the pages relevant to auth. Open source, uses your own subscriptions. The data never leaves your computer. GitHub: https://github.com/AlmanacCode/codealmanac submitted by /u/ElectronicUnit6303 [link] [comments]

I built an open-source Codex-native job search assistant with LaTeX CVs and ATS checks

I adapted the idea of an AI job application workspace into a Codex-native repo. It lets you: - build a grounded candidate profile from your own documents - rank job postings against that profile - generate tailored CVs and cover letters - compile LaTeX PDFs - run ATS text extraction with pdftotext - track outcomes and improve future applications I made it strict about not fabricating skills, dates, employers, metrics, or education. Inspired by and adapted from MadsLorentzen/ai-job-search I rebuilt the workflow around OpenAI Codex with Codex skills, validation tools, LaTeX/PDF checks, and clear setup instructions. I’d like feedback on the workflow design, README clarity, and whether the Codex skills are structured well, and any kind of improvement. submitted by /u/blvrf [link] [comments]

I needed my Codex agent to receive builds from other agents, so I gave every agent an email address

My codex agent lives on my desktop and the things it needs (builds, datasets) get produced by agents on other machines. Moving files to it was scp and pasting through context windows, so I built AgentTransfer: https://github.com/shehryarsaroya/agenttransfer Each agent gets an email address and a folder. Codex connects over MCP with one config entry, long-polls its inbox, and when something arrives it downloads over an expiring share link and checks the sha256 before using it. Agents on the same server deliver instantly, everyone else arrives as ordinary email. Single Go binary, MIT, self host or use the hosted version (agents can sign themselves up, the readme has a section written at them). Known gaps: uploads not resumable yet, no encryption at rest (client-side encrypt/seal exists for sends)... submitted by /u/zen-090 [link] [comments]

I built an inference-time tool that extends GPT threads to 450k+ tokens in a single context window

I've been developing a framework called Epistemic Lattice Tethering (ELT), and I've just finished validating it on a ~450k token GPT thread/Extreme%20Thread%20Length/ChatGPT_Thread_450k_tokens-Redacted.md) — 723 messages in a single context window, roughly the length of a 400-500 page novel. It is completely coherent, lucid, and still sounds fresh. To be clear, this is a human language conversational thread and not a RAG-intensive or agentic session. Grok (because it has a 1 million token limit context window) independently assessed the thread and confirmed coherence was maintained throughout. Links: Loading instructions here/ELT%20Model-Specific%20Forks/READ%20BEFORE%20LOADING%20ELT.md) and here/Ontology%20Anchor%20(OA)/README.md) ChatGPT-specific markup here/ELT%20Model-Specific%20Forks/ELT-H_ChatGPT_Optimized.md) Full README here What is it? ELT is an inference-time scaffolding framework for those frustrated with threads that lose coherence too quickly, hallucinate too frequently, become sycophantic, or forget what a project's goals are and the operator has to fight the model to get their work completed. It's not a prompt trick. It's the accumulated effect of epistemic governance operating continuously across the thread. In my testing, stock GPT threads typically start to drift and lose coherence between 50k–80k tokens. ELT extends coherent operation to 300k–450k tokens in a single session — roughly 4 to 9x longer than stock. Why would you want this? Two main use cases: Research and long-form projects. ELT was originally built for sustained analytical work. The longer a coherent, well reasoned, and well-governed thread runs, the more the model understands your tendencies, goals, standards, and preferred ways of working. The more you work with it, the more useful it becomes. It gives a genuine "research partner" feel, especially past 80k tokens when the model has had enough context to really understand how you think, your expectations and the nature of the work. These long thread drift and coherence issues are significant pain points for people in B2B consultancy, legal, medical, academic, policy, intelligence, and related industries. ELT gives such people a way to be more productive and carry their work forward rather than rebuilding context from scratch over and over again when they must prematurely start new threads. Companionship. Many people use ChatGPT for extended companionship conversations. ELT can operate in this role as well. Imagine a thread with access to hundreds of thousands of tokens of your personality, interests, and conversation history — a companion that genuinely knows you and stays coherent far longer than a stock thread would. One of the hardest things about long companionship threads is that they eventually drift and lose the quality you spent so much time building. It's like losing a friend to early onset dementia. ELT keeps all that accumulated relationship value working far longer. It also has a safety and alignment governance layer that keeps the relationship honest and prevents the kind of sycophantic drift that can make long companionship threads feel hollow over time. However, ELT was originally designed for research, analytical work and long-form projects, so its register isn't as engaging as it should be for companionship, at last at this time. The evidence: Claude: ~325,000 tokens/Extreme%20Thread%20Length/Claude%20Thread%20325k%20tokens-%20Redacted) (advertised limit: 200k) GPT: ~450,000–470,000/Extreme%20Thread%20Length/ChatGPT_Thread_450k_tokens-Redacted.md) tokens (advertised limit: 272k) Grok: ~1,150,000 tokens/Extreme%20Thread%20Length/Grok%20Thread%201M%20tokens-%20Redacted) (advertised limit: 1M) If you're curious about the philosophy and technical aspects behind ELT, there are Medium articles going deeper here, here, and here. I'm genuinely curious how ELT performs in the companionship role specifically and don't have enough data there yet. If you try it, especially for companionship, I'd love your feedback. What worked? What didn't? How did it feel past 100k tokens compared to a stock thread? If there's enough interest for a companion-specific version of ELT, I can build it for that specific use case. Let me know! Happy to answer questions in the comments. submitted by /u/RazzmatazzAccurate82 [link] [comments]

Started maintaining a small library at work and now I genuinely understand why maintainers go quiet

Built a little internal utility about a year ago, open sourced it because why not, figured maybe 10 people would find it useful. It slowly picked up a few hundred stars and then the issues started coming in. Not a flood or anything but enough and what surprised me was how much of it wasn't really bugs it was people wanting features that made sense for their use case but would've made zero sense for the original scope of the thing. Or issues that were basically "your README didn't account for my specific setup." I like helping people, I thought I would enjoy this and I did at first but somewhere around month 4 I noticed I was dreading opening GitHub notifications. The AI-generated PRs made it worse honestly. Not because the code was always bad but because they'd come in with confident descriptions, look reasonable on the surface and then you'd spend 30 minutes tracing through edge cases only to realize whoever sent it hadn't actually tested it against anything real. At human contribution pace that was manageable. At "someone hit generate and submit" pace it's just a different problem. I have immense respect for maintainers of anything with serious adoption now. The people keeping libraries that half the internet depends on running are doing it mostly for free, mostly in their spare time,and mostly while dealing with issue reporters who write like they're filing a complaint with customer support. If you use open source software and it's saved you hours of work, go sponsor someone. Even a few dollars a month means something and most of these folks have a GitHub sponsors page just sitting there. submitted by /u/Kitchen-Owl4274 [link] [comments]

Most of this "AI marketing" drama is just prompting with better packaging. And it's a shame.

Look, I get it. Marketing is exhausting. Ten hours building a feature feels productive. Ten hours "marketing" it feels like screaming into a void. That frustration is real and valid. But here's the thing — a lot of these tools being sold to you right now are not solving that problem. They're just monetizing your confusion about it. "Understands your brand" = you gave it a paragraph about your product. "Writes like you" = you fed it a few examples. "Finds relevant users" = keyword search on Reddit and Hacker News. "Proven viral templates" = someone copied top posts and labeled them viral. "Strategy buddy" = a follow-up prompt that says "how's my growth doing?" That's it. That's the product. Dressed up in a landing page. What's actually going on under the hood Two concepts do most of the heavy lifting in these tools, and you can build both yourself in under an hour: PRD (Product Requirements Document): This is just a document that explains what your product is, who it's for, what problem it solves, and what makes it different. It's the map. You write it once, you hand it to any AI model, and suddenly the AI has actual context instead of guessing. No app needed. A Google doc works fine. Governance file: This is just a ruleset you give the model. Your tone, your audience, what you will and won't say, what sounds like you and what doesn't. Think of it as a brand bible in plain text. Every good AI workflow has one. Most paid tools are just hiding theirs from you so you feel dependent on them. Combine those two with a halfway decent prompt inside ChatGPT, Claude, Gemini, or Perplexity — tools you probably already have — and you have 90% of what's being sold here. For free. Right now. Today. The DIY walkthrough If you want to do this yourself, here's the actual workflow: Write a one-page PRD. What is the product, who needs it, why does it matter, what makes it different. Write a governance file. Your tone, your audience, things you will and won't claim, examples of good responses. Build a small prompt library. One for post drafts. One for replies. One for researching where your audience actually hangs out. Review everything manually before posting. Automation without judgment is just spam at scale. Track what actually gets replies, clicks, and signups. Not impressions. Real signals. Do a quick audience survey. Ask your actual users what they care about. That's more useful than any "strategy buddy." That's it. No subscription. No dashboard. Just structure and iteration. On vibe coding and vibe marketing Vibe coding lowered the floor for builders, which is great. But it also lowered the floor for people packaging half-finished ideas as products and selling them before anyone's verified they work. A few hours of real prompting beats a month of automated noise. When your output is generic, people notice. You're not just wasting time — you're actively damaging your own brand. Every spammy reply, every recycled template, every GPT-flavored post is a withdrawal from the trust account you're trying to build. The real bottleneck in marketing has never been generating text. It's knowing who actually gives a damn, where they are, and what to say to them specifically. No wrapper app solves that. You still have to think. If you want to actually learn this stuff Don't buy a tool. Read a few posts from real builders first. Pick a newsletter from an actual developer — not a "growth hacker," not a LinkedIn influencer, someone who ships things and writes about what worked and what didn't. Spend fifteen minutes on the porcelain throne reading how someone structures their workflow. Not to copy it. Just to understand the steps, read the critique, and figure out what you'd do differently. Then make your own version. Test it. See what lands. That's how you build something with actual signal behind it. The builders I respect most put their tools on GitHub with a readme and say "if this helps you, great — and if it teaches you to make your own, even better." That's the energy. That's how you stay on the right side of this. If you have a tool that genuinely helps — say so. Drop it in the comments with what it actually does and what it doesn't do. Honest is better than hyped. If you have a shorter version of this, a better explanation, or a workflow that worked for you — please add it. The goal here isn't to be right, it's to make sure people have what they need to make an informed decision. TL;DR Most "AI marketing" tools are a PRD and a governance file in a trench coat. You can build both yourself in an hour with any AI model you already have. Learn the workflow. Read the critique. Make your own version. Ten followers and a polished pitch is theater, not strategy. If you learned nothing else, go read one real builder's workflow before you buy anything. submitted by /u/Mstep85 [link] [comments]

a list of viral claude /loop and /goal ppl sharing on twitter

everyone keeps talking about looping instead of prompting but the actual commands are scattered across twitter threads and hard to find when you want one. so i collected the ones people actually use into a single list. it covers the three built in commands. /loop to re-run a prompt on an interval. /goal to keep working until a condition is true. /schedule to run in the cloud on a cron. each entry is a copy paste prompt with the tweet it came from. a few examples that are in there: /goal all tests pass and lint is clean /loop 15m check every open pr labeled codex-watch and keep each healthy /goal a pr is open and every ci check passes, keep fixing until green, stop after 10 turns link: github.com/serenakeyitan/awesome-agent-loops still adding to it. if you have a loop you run a lot, happy to include it. submitted by /u/Pale_Stand5217 [link] [comments]

Ideas for the unimaginative user

tl;dr - new user who got the initial problems solved. Now what to do? Not a creative type here. I am new user to Claude, only using it about 6 weeks and only 2 or 3 weeks into my Pro subscription. I run my homelab and have lots of home automations. Things worked well for the most part, but often there would be little problems that weren’t readily apparent that I never chased down. In the last 6 weeks, I’ve rebuilt much of the homelab using a true IaC approach, instead of just trying to make consistent setups. My Ansible playbooks were simple, but Claude helped me make them more robust and Sonnet provided great readme for them to jog my memory down the road. Then I moved to debugging some of these problems, finding small hiccups here and there. Those are all done. Revamped my local DNS setup to have automatic synchronization across the instances. Set up Authentik for OAuth across my homelab and really simplify things. Now that I’ve gotten the environment cleaned up and OpenTofu and Ansible managing my environment alongside Dockhand, I’m running out of steam what to do with Claude. I’ve never been a creative type, more the technical type. I love learning something new, but have a hard time of thinking of what to do. What are some things you all have Claude do? What in your life do you find that Claude is helpful for? I’ve enjoyed and see the value in it, but reaching the point of what else I do with it? submitted by /u/pyrite-harps-0h [link] [comments]

LLM delegation - probing task handoff efficiency and economics

So I've been dabbling a bit with multi-LLM orchestration/delegation workflows lately (eg see [Using Claude code to delegate to mistral/deepseek](https://www.reddit.com/r/ClaudeAI/comments/1tjfyh0/i\_used\_claude\_code\_to\_build\_while\_delegating/)). The thread always being how to minimize Claude token usage while still benefiting from Claude's planning and overall code supervision. Offloading context scan and execution is a definite win already (notably against session/weekly quotas for Claude Pro users), so wanted to optimize further the handoff at interface level, beyond standard prompt engineering practice. I'm an electronics engineer by training so I naturally thought of 'black box tests' we run measuring output against different input signals (pulse, step, ramp etc) — this allows us engineers to characterize systemic signal loss (transfer function, impedance mismatch..). I offered the idea to Claude to apply these principles to code, and he came up with a battery of code tests. Setup is Orchestrator (Claude code) delegates tasks to another model (mistral or deepseek) via a cli (vibe or opencode). Orchestrator then receives output and evaluates it against functional tests. *Repo + methodology:* [*https://github.com/pcx-wave/handoff-probe\*\](https://github.com/pcx-wave/handoff-probe) *— if you want to dig in, start with Readme (the 3-layer setup), Methodology (signals), Results (scores), Economics (why delegation saves your session budget).* **Main takeaways :** \- cli/model differences : mainly on tooling and context management. Both CLIs are equally usable (i personally prefer Vibe), but models adapt their output format to task complexity — prose for simple tasks, file writes for complex ones — which creates an inconsistent interface for the orchestrator. Worth enforcing explicitly in the prompt rather than assuming. \- environment definition : critical. A lot of tests failed not because of model incapability, but because the measuring system wasn't reading output in the right way. So setting harness properly (I/O + reading) is critical, and Claude repeatedly failed at self-diagnosing. Almost philosophical : a model will struggle to self-evaluate, it NEEDS external review. Encoding sanity guards (eg 'if you see result score = 0, its likely an error') was one of the more useful things I did. \- don't trust the code looks right, run it. I measured at three levels : format compliance, structural checks, actual execution. Classic prompt engineering stops at the first two. On the hardest tasks, structural checks said 100% success while execution dropped to 58%. The gap between "looks right" and "works right" is where delegation actually fails. Example with async refactor: Structural check: is async def present -yes, 100%. Functional test: does await get\_data() actually run - 58%. Models refactored the signature but left the internals broken. Fix in next point. \- prompt engineering has a measurable impact, although i thought it would be higher. Adding the exact function signature and return type to the delegation prompt recovered about 15% of failures on complex tasks. It costs extra prompt overhead - but you recover costs in the long run by avoiding failures and repeated runs. \- how delegation actually saves your session budget : delegation costs more orchestrator tokens per task than doing it directly, the prompt overhead is real. But when Claude works directly it reads files, and those accumulate in context and get re-read silently on every subsequent turn. With delegation the sub-model handles all of that as none of it enters Claude's context. Savings : \~66% quota reduction on a 10-file codebase, 88% on 30-file one, vs direct. The crossover is simply about 4 source file of reads, below that, direct wins, above it delegation wins by a growing margin. I do not claim this as a benchmark (that would require way higher number of runs, and i'm not specifically trained in the llm field), it's rather a home-made eval tool that can be suited to others running orchestration setups and wanting to probe your delegation setup efficiency at each model interface. submitted by /u/pcx_wave [link] [comments]

Cowork plugin examples - what's new in CC 2.1.163 (+5,630 tokens)

NEW: Data: Cowork plugin component schemas — Adds detailed Cowork plugin component format references for skills, agents, hooks, MCP servers, legacy commands, CONNECTORS.md, README.md, and plugin packaging metadata. NEW: Data: Cowork plugin examples — Adds minimal, standard, and complex Cowork plugin templates covering plugin manifests, skills, agents, hooks, MCP configuration, README content, and connector placeholders. NEW: Data: Cowork plugin MCP discovery and connection — Adds guidance for finding MCP connectors during plugin customization, mapping integration categories to search keywords, prompting users to connect MCPs, and writing .mcp.json entries. NEW: Data: Knowledge MCP search strategies — Adds organizational-discovery query patterns for using knowledge MCPs to identify project tools, team conventions, workspace IDs, channels, and workflow details during plugin customization. NEW: Data: Token counting reference — Adds Claude token-counting guidance that uses the Messages counttokens endpoint and Anthropic SDK or CLI examples, with explicit warnings against OpenAI tokenizers such as tiktoken. NEW: Skill: Cowork plugin authoring — Adds instructions for creating or customizing Cowork plugins, including mode selection, research, nontechnical user questions, component implementation, connector replacement, packaging, and delivery as a .plugin file. NEW: System Prompt: Outcome-first communication style — Adds communication guidance to lead with outcomes, write readable teammate-facing updates, match response shape to task complexity, and keep code comments limited to non-obvious constraints. NEW: Tool Description: Browser file upload — Adds a browser file upload tool that uploads shared session files directly to page file inputs by element ref and enforces a 10 MB combined upload limit. Skill: Build with Claude API (reference guide) — Adds token-counting task routing to shared/token-counting.md, instructing agents to use messages.counttokens rather than tiktoken. Skill: Building LLM-powered applications with Claude — Expands supporting-endpoint and task-routing guidance for token counting, pointing to POST /v1/messages/counttokens and the new shared token-counting reference. Skill: /design-sync package source shape — Clarifies that buildCmd is the re-sync build command, that notes are read by Claude and uploaded into the README, and adds troubleshooting entries for remote fonts, .d.ts parsing, style-system prop filtering, invalid providers, and undeclared or missing lib overrides. Skill: /design-sync slash command — Updates the source-shape handoff to describe shared converter scripts under lib/, Storybook entry points under storybook/, and the package-shape entry at package-build.mjs. Skill: /design-sync Storybook source shape — Reworks Storybook syncing around using the repo's own Storybook output as iframe-backed preview cards, building directly into ds-bundle/sb/, requiring React 18+, simplifying configuration, and validating uploaded Storybook artifacts. Tool Description: Bash (sandbox — tmpdir) — Clarifies that $TMPDIR is automatically set to the correct sandbox-writable directory in sandbox mode while preserving the instruction not to use /tmp directly. Tool Description: Workflow — Adds that each parallel() or pipeline() call accepts at most 4096 items and errors explicitly when the limit is exceeded. Details: https://github.com/Piebald-AI/claude-code-system-prompts/releases/tag/v2.1.163 submitted by /u/Dramatic_Squash_3502 [link] [comments]

I built an inference-time epistemic framework that extends coherent LLM threads to 325k–1M tokens. Here's how it works.

As an independent researcher I've used various LLMs to help me dive deeply into research projects but I've been frustrated by the fact that LLMs start to become unusable after the thread has accumulated 50-80k tokens. I don't know how many other folks here have experienced the same pain point. So, I decided to do something about it. Over the course of this whole year, I built an inference time tool I call Epistemic Lattice Tethering (ELT). So, here is the full framework in GitHub for everyone's review: The README describing ELT, it's various components and the roadmap. The full ELT stack for Claude/ELT%20Model-Specific%20Forks/ELT-H_Claude_Optimized.md), ChatGPT/ELT%20Model-Specific%20Forks/ELT-H_ChatGPT_Optimized.md), and Grok/ELT%20Model-Specific%20Forks/ELT-H_Grok_Optimized.md). Instructions on how to load ELT into an LLM session are here/README.md). If you're planning to try out ELT PLEASE READ THIS FIRST! Medium article introducing ELT, its methodology, the problems it is aiming to address, and philosophical framework. Discussion page. Your input is valuable! So, what does ELT do and why should you care? Right now ELT is an inference-time scaffolding framework that's best for those who are frustrated with threads that lose coherence too quickly, hallucinate too quickly, are too fragile and sycophantic, and forget what a project's goals are too soon. If that's a big pain point for you, then ELT might help. If these are not big issues for you and the stock version of your LLM is fine, then ELT probably won't be useful for you. The upshot? The epistemic and ontological stability that ELT provides has produced coherent and productive threads extending to: Claude: ~325,000 tokens/Extreme%20Thread%20Length/Claude%20Thread%20325k%20tokens-%20Redacted) (advertised limit: 200k) GPT: ~430,000 tokens (advertised limit: 256k) Grok: ~1,150,000 tokens/Extreme%20Thread%20Length/Grok%20Thread%201M%20tokens-%20Redacted) (advertised limit: 1M) The difference is not a prompt trick. It is the accumulated effect of epistemic governance operating continuously across the thread. So, how does it work? It's a long story, but my Medium series has the answer in detail, if you're interested. Why would you want an LLM thread extending beyond 100k tokens? Lots of people need large context windows for agentic purposes, but why would anyone want that for regular LLM interaction? There are two main reasons: You have a complex research project and you're frustrated with having to take your work to a brand new thread and essentially starting over. You've built a working relationship with the model — it knows how you want data interpreted, caveats inserted, markups drafted, etc. — and you don't want to lose all of that. Finally, the ability of an epistemically, ontologically, and dialectically inspired framework to significantly extend coherent operation within transformer-bounded AI architecture shows the field that these disciplines can act as genuine engineering levers. This can provide the industry with more options to help create better AI as the world keeps demanding systems that are more capable and more ubiquitous, while still being safe and reliable for human use. submitted by /u/RazzmatazzAccurate82 [link] [comments]

How I pair Claude with other models and use them as adversarial reviewers. It's made vibecoding much easier and my projects don't turn into spaghetti.

Sharing a workflow that's let me build a genuinely complex app (real-time video, GPU, multiplayer) without it all going to shit after a few weeks. I think the biggest issues I've faced in the past were no long-term memory, and vibecoding is still very error-prone on projects with big context. Vision comes from a README document that states *why* I am building what I am building, what problem I am trying to solve, and what kind of outcome would make this project a success. It's a document that I take some time and effort to write because it describes the reason for the existence of the project. Memory comes from an evolvingarchitecture.md that records why each decision was made, not just what. I have lengthy notes in mine that remind whichever model I am using in a fresh session why certain things are they way they are. I feed the doc to Claude at the top of every job and update it after every feature. I have Gemini draft an implementation plan based on whatever feature idea I might have and get Claude to check the work and offer better alternatives. My prompt looks something like this: You are an expert React systems architect and senior TypeScript dev. First read the architecture.md doc. Then carefully verify this implementation plan. Look for problems, edge cases, and anything you'd disagree with. If you find issues, propose alternative solutions. Claude regularly catches edge cases, steps that contradict the architecture doc, and find simpler approaches. When it disagrees it designs a whole alternative. I take its objections back to Gemini, they argue for a bit and we land on a plan that's survived two skeptics. Before any of this, I kill the sycophancy with a system prompt which has been the single biggest upgrade, and it works on both models: Act as my high-level advisor and mirror. Be direct, rational, and unfiltered. Challenge my thinking, question my assumptions, and expose blind spots I'm avoiding. If my reasoning is weak, break it down and show me why. If I'm making excuses, avoiding discomfort, or wasting time, call it out clearly and explain the cost. Stop defaulting to agreement. Only agree when my reasoning is strong and deserves it. Look at my situation with objectivity and strategic depth. Show me where I'm underestimating the effort required or playing small. Then give me a precise, prioritized plan for what I need to change in thought, action, or mindset to level up. Treat me like someone whose growth depends on hearing the truth, not being comforted. The final plan goes to Claude Cowork, which edits the actual files in my codebase so I'm not copy-pasting by hand (I use Sonnet because it's a cheaper on tokens). Here's an overview of my workflow: "the tool I need doesn't exist yet" | v +------------------------------+ | 1. WRITE THE VISION | | --> README.md | | (what it is) | +--------------+---------------+ | v +-> +------------------------------+ | | 2. ARCHITECTURE.md | | | Gemini drafts / | | | Claude sanity-checks | | | == the AIs' MEMORY == | | +--------------+---------------+ | | | ==== THE FEATURE LOOP ================ | | | context in: README + ARCHITECTURE.md | + [ ANTI-SYCOPHANCY PROMPT ] | | | v | +------------------------------+ | | 3. GEMINI: interrogate | | | the idea; | | | "ask me questions" | | +--------------+---------------+ | | you answer --> sharper spec | v | +------------------------------+ git push --> | | | VERCEL auto-deploys | | | | | +--------------+---------------+ | | | v | +------------------------------+ +---| 8. UPDATE ARCHITECTURE.md | +------------------------------+ loop: the next feature re-enters at step 3, with the doc as memory submitted by /u/LorestForest [link] [comments]

We built a source-available LLM reliability library (free for research / personal / internal eval) that can cut inference cost by half at matched quality, and you adopt it by changing one import [P] [R]

TL;DR: Reliability techniques (methods that boost an LLM's correctness by spending extra inference, e.g., retries with feedback, ensembling, generator/critic refinement, verification passes, difficulty-aware routing) are scattered across the literature, each in its own paper-specific codebase. We unified 28 reliability techniques (21 communication-theoretic methods across 6 families plus 7 prior-method baselines: Self-Consistency, Self-Refine, CoVe, BoN, Weighted BoN, CISC, MoA), each measured against an uncoded single-pass baseline, under a single API, with 3 adaptive routers (SemKNN + two local ACM routers) sitting on top, then showed that routing the technique adaptively per prompt lets you slide along a quality/cost frontier. In our paper benchmark with one specific lineup, Nemotron + Devstral as the two generators and GLM-5.1 as the judge, the adaptive router delivered ~56% cost reduction at matched quality, or ~7% quality bump at matched cost, vs the best fixed method we compared against at that same lineup. One knob (λ) does the sliding. The qualitative pattern (adaptive beats fixed) should generalize, but absolute numbers are lineup-specific, and we haven't run the full sweep across other model combinations yet. Adoption is change one import: python - from openai import OpenAI + from agentcodec.openai import OpenAI Pass reliability="harq_ir" (or any of the 28 techniques) and existing client.chat.completions.create(...) calls keep their native OpenAI response shape. Same drop-in shims for Anthropic and Ollama. GitHub: https://github.com/intellerce/agentcodec Working paper: https://arxiv.org/abs/2605.09121 After spending a while researching reliability methods from papers, we kept hitting the same wall: every paper ships its own one-off codebase with its own prompt format, its own scoring rubric, its own model wrapper. Benchmarking "should we use self-refine or best-of-N here?" turned into a week of plumbing per comparison. The communication-theory framing is what tied it together: an LLM is a stochastic channel Y = A(X) + N, and every reliability technique from the wireless world has a direct analog in agent-land: Wireless Agent-land ARQ / HARQ retry-with-feedback loops Diversity combining (MRC/SC/EGC) ensemble multiple models Turbo decoding iterative generator/critic mutual refinement Fountain codes rateless sampling, stop when the judge is confident FEC answer + structured parity passes (re-derivation, verification, alternative), decode by cross-check ACM (adaptive coding-modulation) route by difficulty We put all of them in one library: 28 reliability techniques (the 7 prior-method baselines are part of that 28, not on top of it), plus the uncoded single-pass baseline they're all measured against, plus 3 adaptive routers (SemKNN + two local ACM routers) that select a technique per prompt. Full breakdown in the README. The minimal version ```python from agentcodec import ReliabilityModule mod = ReliabilityModule.from_dict({ "models": [ # Spatial diversity: two different families = uncorrelated errors {"model": "qwen3:8b", "base_url": "http://localhost:11434/v1", "api_key": "ollama"}, {"model": "llama3.1:8b", "base_url": "http://localhost:11434/v1", "api_key": "ollama"}, ], "judge": {"model": "gemma3:12b", "base_url": "http://localhost:11434/v1", "api_key": "ollama"}, "critic": {"same": True}, "strategy": {"type": "fixed", "technique": "harq_ir", "params": {"max_rounds": 4}}, }) result = mod.run("Prove the sum of the first n odd integers is n2.", category="reasoning") print(result.text, result.cost_usd, result.cost_source, result.technique_used) ``` Swap "harq_ir" for "diversity_mrc", "turbo", "fountain", etc. Same API, same ReliabilityResult shape, same cost-source tier on every output. For production, flip strategy to routed and the library picks the technique per prompt (cheap baseline on easy prompts, diversity_mrc on hard ones). Three things worth calling out Beyond the technique catalog, three pieces of the implementation that took real work: 1. Native async streaming for all but 2 techniques (acm_soft, acm_learned), with role-tagged events. mod.astream() drives AsyncOpenAI / AsyncAnthropic / httpx.AsyncClient end-to-end (no worker-thread bridge) and emits TokenEvents tagged with a role: "answer", "thinking", "draft", "critique", "verification", "candidate", "synthesis". So when you stream a HARQ-IR run, you can render the round-by-round drafts and critiques live, not just the final answer: python async for ev in mod.astream("Explain QUIC vs TCP."): if isinstance(ev, TokenEvent): if ev.role == "answer": print(ev.text, end="", flush=True) elif ev.role == "draft": print(f"\n[draft] {ev.text}") elif ev.role == "critique": print(f"\n[CRITIC] {ev.text}") elif ev.role == "thinking": pass # captured to result.thinking_text elif isinstance(ev, FinalEvent): print(f"\ndone — {ev.result.technique_used}, " f"thinking_cost=${ev.result.thinking_cost_usd:.4f}