TENSA Engineering @TENSAEng

Your AI coding tool says a bug is still there, but you fixed it an hour ago on your computer? It may be reading a different copy of the project. tensaengineering.dev/knowledge-base… When you edit files locally and the AI reads the project through a GitHub connection, there are three copies: 1. The files on your computer (your edits land here first). 2. Your local Git commits (saved, but still only on your machine). 3. What’s on GitHub (the copy a connected cloud AI actually reads). A GitHub connector usually can’t see edits you haven’t committed, or commits you haven’t pushed. It also can’t see files never added to the repo, or terminal output unless you paste it. So it can answer confidently about an older version of the project. Two habits fix most of this: - Commit and push before you ask the AI to review or change anything. - Ask it which repository, branch, and commit it looked at. If that doesn’t match what you’re working on, its answer is about something else.

Moved to Claude Opus 5.5 in Claude Code and noticed your usage climbing faster than before? Check the effort setting. Effort controls how hard the model thinks before it answers, and that thinking counts against your usage. code.claude.com/docs/en/model-… Anthropic says Opus 5.5 at medium matched or beat the previous Opus 5 at high on their coding and knowledge-work tests. It also tends to think more per turn than Opus 5 at the same effort level. Opus 5.5 starts at medium by default. If you ever saved a different default effort in your settings, that saved level wins, and you may be paying for extra thinking you don’t need. What to do: - Run /effort to see your current level. /effort medium sets it directly. - /effort auto clears any saved level for the model you’re on. - Use high when the work needs careful checking, like bug fixes in an existing codebase. Low is fine for quick back-and-forth where you review every answer. - Skip max unless the problem is really hard. Anthropic says it can overthink and give diminishing returns. On the 5.5 models you can’t turn thinking off, so effort is the main dial you have.

This is interesting because I've spent much of this year building toward a similar goal, although I'm approaching it from a slightly different direction. My project started with a simple problem. I was using AI to learn Linux and build systems, and one day it lost the context of everything we'd been working on. That led me to start building NeuroCore. NeuroCore is a local-first AI runtime with a control plane between the model and the systems it interacts with. The model can reason and request tools, but the control plane governs what it can access and execute. Requests are traced, and the underlying evidence is preserved so results can be checked rather than simply trusted. The next major piece is NeuroCore Continuum, which I'm designing as the system's long-term brain. The goal is persistent, system-owned memory that survives conversations, model changes, and restarts. Rather than relying on a model to remember everything, Continuum will assemble relevant context from documented decisions, project state, previous work, and verified evidence. It will also capture new information provisionally, identify conflicts, and propose what deserves to become permanent knowledge. That's where the dreaming concept gets particularly interesting. I absolutely want the system learning from previous work, but I don't want an AI automatically turning a mistaken conclusion into a permanent instruction. Memory needs its own authority and validation rules. The other piece is Agent Operations, my model-agnostic coding orchestration system. It already supports approved task packets, validation, evidence collection, and supervised coding workflows. I'm expanding it toward multiple isolated workers running Claude Code, Codex, and Grok Build, with dependency-aware scheduling, independent reviews, and recovery from interruptions. The longer-term plan is for Agent Operations to become part of NeuroCore, with Continuum providing the shared context and the control plane governing execution. Much of that integration is still being designed and built, but the foundations are real and evolving. I agree that the future isn't just smarter models. It's building systems around them that preserve knowledge, learn from evidence, recover from failures, and carry useful work forward without constantly starting over. That's the direction I'm working toward.

This is actually very close to how I'm building my Agent Operations system. I use Proxmox to run isolated Ubuntu worker VMs on a dedicated VLAN, separated from my network and management infrastructure. Each worker has its own environment for running AI coding tasks. My design keeps the trusted controller separate from the workers. The controller handles authorization, task scope, permissions, and evidence collection. Workers only get access to what an approved task requires. For GitHub, Slack, or other services, I'd put a credential broker on the trusted side. The worker would request an action, and the broker would verify that it's authorized before making the API call. Credentials would never be passed into generated code. Network isolation matters just as much. If the worker can bypass the broker and reach sensitive services directly, you've defeated the purpose. I'd also test the boundaries by attempting unauthorized connections, credential access, and operations outside the approved task. I've already built and validated the isolated worker infrastructure. The automated controller and permission handling are still being developed. My approach is simple: don't rely on the model to respect security boundaries. Enforce those boundaries outside the model, where its own code can't change them.

I think we're overlooking something important in this debate: how efficiently people are actually using AI. I have three AI subscriptions in the $20–30/month range: ChatGPT, Claude, and Grok. I've used them to build and develop a substantial amount of software without paying $200/month for any single model. What made the difference for me wasn't chasing benchmark scores or buying more usage. It was changing how I work. I plan the architecture and requirements before I start coding. I keep project history, decisions, and documentation in Git repositories so new AI sessions don't have to reconstruct everything. I break implementation into smaller, testable tasks instead of asking a model to build an entire system in one conversation. That approach has helped me develop NeuroCore, a local-first AI runtime, Argus ACLI for Linux diagnostics, Argus Lab for validation, and Agent Operations for coordinating AI-assisted development. I'm now upgrading Agent Operations to manage multiple coding models, independent reviews, and eventually dependency-aware scheduling across projects. I'm not saying a $200 subscription isn't worth it for someone whose workload justifies it. But spending more doesn't automatically mean you're getting more useful work done. A benchmark tells you something about a model's capabilities. It doesn't tell you how effectively someone will use it. I'd rather build a better workflow around several capable models than depend on one expensive subscription to compensate for an inefficient process.

@ethanbroke_ Thinkers and problem solvers. Always has been, always will be. Now we we have AI to force multiply our abilities.

Did you know that ChatGPT chat, not Codex or work, doesn't count against your usage limits? You can plan for days in the same thread, (not recommended) and none of your Codex limits are used. It writes code too. Not the best at it but its 100% covered under a $20 subscription. I use it heavily!

My journey started with learning Linux, networking, and virtualization with the help of AI. I was building a home lab, learning as I went, and relying on AI to help me figure things out. Then one day, the AI forgot everything we'd been working on. The project, the decisions, the progress. Gone. That frustration started something much bigger than I ever expected. I began building NeuroCore, a local-first AI platform designed around long-term memory, real system awareness, and controlled access to tools. The idea was simple: what if AI could actually grow with you and your environment instead of starting over every conversation? That led to Argus ACLI, a read-only Linux diagnostics tool built on NeuroCore, and Argus Lab, where I can test and validate those capabilities against real systems. Along the way, I needed a better way to build all this software. So I developed Agent Operations, a system for managing AI coding work across different models while preserving project context, decisions, testing, and human oversight. Now I'm working toward automating much of that development workflow, allowing multiple AI coding models to work on separate tasks and projects while I focus on architecture, direction, and decisions. The longer-term vision for NeuroCore goes even further: persistent memory, continuity across models, and AI that understands the environment it's operating in. A lot of this is still under development. Some parts are working, others are being tested, and some of the bigger ideas are still on the drawing board. But that's what makes it exciting to me. I didn't start out trying to build an AI engineering company. I started out trying to solve a problem I personally experienced. Each problem I solved exposed another opportunity to build something useful. I'm still learning every day, and I have a long way to go. The possibilities are enormous. I'm just going to keep building and see how far I can take it.

I'm actually building a system to do exactly this. I use ChatGPT for planning, architecture, and making decisions. Those plans get documented in the project repositories. Then Agent Operations (AO), my model-agnostic orchestration system, takes the approved work and hands bounded tasks to Claude Code, Codex, or Grok Build. Each coding model runs through its own harness and subscription. AO manages the common workflow: task instructions, permissions, context loading, validation, independent AI reviews, and keeping track of what was done. The important part is that no individual model owns the project. The plans, decisions, task history, and evidence live in the repositories. I can switch models or start fresh sessions without losing the work. I'm upgrading AO now to manage multiple workers across multiple projects, with dependency-aware queues, priority scheduling, and a single dashboard to monitor everything. The manual workflow already works. Automated worker management and scheduling are still being built. My goal is to spend my time designing software and making decisions, not managing three different AI coding tools all day.

I don't use Claude in the terminal to impress anybody. I use it because of how I've structured my projects. I started with simple repo maps generated by the Linux "tree" command. Over time, I built a metadata and stable ID system into my repositories. Documents identify what they are, where they belong, what other documents they depend on, and when the AI needs to read them. Now Claude can navigate a project using terminal commands, follow dependencies, find the right files, and even pull relevant context from other repositories without me manually directing every step. It doesn't need to read thousands of lines of unrelated documentation just to answer a question. It loads what the task actually needs. I've also built in rules for which documents are authoritative, what's current versus planned, and what the model is allowed to change. The terminal isn't about looking like a hacker. It's about giving the model direct access to a structured environment where it can do useful work without me babysitting file navigation. A button can start a task. How much the model can accomplish after that depends on the tools and systems behind it.

Your AI coding tool is more than the model. A lot of whether it gets your project right comes down to the system around the model: what it gets to see, what it gets handed, and what gets checked. tensaengineering.dev/projects/neuro… Some well-known engineers have been saying this for a while: - @karpathy called it context engineering: filling the context window with the right information for the next step. Too little and the model is missing what it needs. Too much and it costs more and can do worse. - @mitchellh calls it engineering the harness. Every time the agent makes a mistake, you build something so it doesn't make that mistake again. - An OpenAI team that built a product written entirely by Codex landed in the same place: give the AI a short map that points to the right docs, not one giant instruction file. One way people are building that map is a code graph. Tools like CodeGraph index your code ahead of time: every function, what calls it, what it depends on. Instead of searching file by file, the AI asks one question and gets the connections back. The author's own tests on seven open-source projects show far fewer tool calls. But a code graph only maps the code. It can't tell the AI which of your docs is current, what you already decided, or what's only planned. That takes a second map, one over your project knowledge, where each doc knows what replaced it and which source wins when two disagree. That's the part I'm designing for NeuroCore, the local-first AI runtime I'm building. The planned piece is called Continuum. The idea: you ask a question, and the answer comes with which docs it's based on, whether they're current, and what's missing. The model reasons over what it's handed. It doesn't decide what's true. What exists today: the NeuroCore runtime and the read-only Argus ACLI tools that run on it. Continuum is in design only. It isn't built. Until it is, my AI does this with plain project docs: a short resume doc that points to the rest, and old docs marked with what replaced them. What's in your setup: a code graph, project docs, or both?

If your Codex limit is running out way faster than you expected, check which model you're using. On the Plus plan, OpenAI says GPT-6 Astra gets about 5 to 45 messages every five hours. GPT-6 Luna gets about 350 to 3,000. learn.chatgpt.com/docs/pricing That's a huge difference just from picking a model. Those numbers are OpenAI's estimates, not hard limits, and they're for Codex running on your own computer. Tasks you send to run in OpenAI's cloud use more. Bigger projects and longer sessions use more too. OpenAI's own advice when usage runs high is to try a smaller model. So use the heavy one when you're planning something or stuck on a hard bug, and switch to a lighter one for small edits and simple fixes. Also leave Fast mode off unless you really need it. OpenAI says it uses 2.5 times as much on the same model. You can check where you're at with /status in the Codex CLI, or on the usage dashboard, which also shows when your limits reset. Same idea on Claude Code. Anthropic says Sonnet handles most coding for less than Opus, and you can switch with /model.

Linux admins: a service that dies with nothing useful in its own logs often didn't crash. Linux may have killed it. (A service is a program that runs in the background on a Linux server, like a web server or a database.) When a Linux machine runs out of memory, its out-of-memory killer picks a running program, called a process, and ends it on the spot to keep the rest of the system alive. The process gets no warning and no chance to write a last log line, which is why the app's own logs just stop. How it picks: each process gets a score, mostly based on how much memory it's using at that moment. Bigger means more likely to go. So the process that gets killed isn't always the one that caused the problem. A well-behaved service can lose because something else filled up the memory. The evidence is in the kernel's log, not the app's. The kernel is the core of Linux, and it keeps its own record of problems. To search it, run: sudo journalctl -k -g 'out of memory|killed process' A hit names the process and its ID. If the server has rebooted since, add -b -1 to search the previous boot. Two other places to look. systemctl status on the service can show the failure reason as oom-kill. And some systems run a separate service, systemd-oomd, that steps in earlier, when memory is getting tight, and logs under its own name. If the kernel log is empty, check there. Once you've confirmed it, the real question is why memory ran out. Usually it's one of three things: a leak that grows until something gets killed, a service set up to use more than the machine has, or too much running at once. Watch free -h over time and read the "available" column. Then you can decide between fixing the leak, trimming the workload, putting a limit on the service, or adding RAM. One thing that doesn't help: making a service harder to kill doesn't free any memory. Linux just picks something else.

AI chat assistants like Claude, ChatGPT and Grok now have memory and past-chat search, so it can feel like they remember everything you've ever told them. They don't. What they do is carry a few saved details, or search your old chats for pieces that look relevant. OpenAI says it plainly: "Memory does not retain every detail from every conversation." Anthropic says Claude's chat search uses retrieval, which means it pulls up relevant pieces of old chats, not all of them. And xAI's Grok help page warns that Grok "may confidently provide factually incorrect information, missummarize, or miss some context." Here's the catch. The AI doesn't tell you which parts it has and which it's missing. A partial memory sounds the same as a complete one, and the gaps can get filled with a confident guess. So for anything that matters, don't treat memory as the record. Keep the facts in a project doc you can read, with the date and how they were checked, and have the AI load that doc before it answers. If it can't load the doc, it should say so instead of guessing. Memory is fine for preferences and background. It isn't a source of truth.

Linux output is a lot to read. Most of it is fine, and the part that matters is buried somewhere in the middle. Argus ACLI is a diagnostic tool I'm building to dig that part out for you. tensaengineering.dev/projects/argus… Here's what it's meant to do. It reads the complicated output from your system. It cuts out what doesn't matter and organizes what does. Then it tells you how serious the problem is, what the output most likely means, and what to check next. The goal is to get the admin to the fix faster, so the server spends less time down. Where it stands today: collecting the data, sorting it, rating how serious each finding is and suggesting what to check next are built. Explaining what it most likely means, in plain English, is planned. For that part, I'm adding a local AI model. ACLI will hand it the findings and the real data behind them, and nothing else. Since the model only sees the evidence that matters, there's less room for it to misread what's going on. It sends its answer back to ACLI, and ACLI shows it to you. The model won't have any access to the system. It can't run commands or change anything. You read the answer, make the call and type the commands yourself. And nothing gets sent to the cloud. It all stays on your machine. Argus ACLI is under active development. It is not available to download yet.

Not sure what's eating your Claude Code usage? Run /usage. On a paid plan it shows how much of your recent usage went to each skill, subagent, plugin and MCP server, as a percentage. Press d or w to switch between the last day and the last week. code.claude.com/docs/en/costs That turns a guess into a list. If one server or subagent is taking a bigger share than you expected, start there. What to do with it: - Run /mcp and turn off servers you aren't using. - Where a command-line tool exists, like gh for GitHub, Anthropic says it uses less context than an MCP server. - Run /context to see what's taking up space in the current session. - Big subagent share? Each subagent sends its own requests on top of your main conversation. Two limits worth knowing: the numbers are approximate, and they only cover this machine. Usage from claude.ai or another computer isn't counted. Using the VS Code extension? The same breakdown is in the Account & usage dialog.

If you keep project docs for your AI, two kinds pile up over time. Some say what's true right now. Others were true when you wrote them and aren't anymore. Your AI can't tell which is which unless you tell it. tensaengineering.dev/knowledge-base… The first kind is your source of truth: the one place that says what's true today. The second kind is history. History is worth keeping, because it shows what changed and why. But it isn't the current state, and an AI that reads both can treat an old doc as current without saying so. Here's how that played out for me. My home server has a remote management license. The top tier lets me see the server's screen from anywhere, which I need when it won't boot. The server came with a temporary top-tier license. It expired and dropped to the basic one. Later I installed a permanent top-tier license. Every doc I wrote along the way was right on the day I wrote it. The problem was that I'd copied those server facts into several projects, and when something changed, I updated one and not the others. Depending on which project an AI read, it got a different answer, and every answer sounded sure of itself. If it planned a server recovery from the wrong one, it would count on a remote screen I didn't have, or skip one I did. What I changed: 1. One place owns the facts. A single repo now holds my network and server setup. My other projects point to it instead of copying it. 2. Old docs stay as history. When the AI comes across one, it marks it with what replaced it. 3. Every time the AI records a fact, it adds the date and how it was checked. Then one rule for the AI: what it can check right now beats any doc. If it can't check, and two sources disagree, it tells me and stops. A confident guess isn't an answer. You don't have to set this up by hand. Commit or back up your project first, then give your AI this: "Read my project docs. Find facts that appear in more than one place, and docs that look out of date. Don't change anything yet. Show me a list: each fact, where it appears, which copy looks current, and how you could check it. Then propose one place to own each fact, a note on each old doc saying what replaced it, and a date and how it was checked next to each fact. Add this rule to my project docs: what you can check right now beats any doc, and if you can't check and two sources disagree, tell me and stop. Don't delete old docs, don't commit, and don't edit anything until I say yes." Read its list before you say yes. It can find the conflicts, but you're the one who knows which answer is right.

Your Linux server says the disk is full. You run du to find what's using the space, and the numbers don't add up. Or df says there's plenty of room, and you still get "No space left on device." Both are common, and both are confusing the first time you hit them. First, make sure you're looking at the right disk. If /var is its own mount, df -h / can look fine while /var is full. Run df -h on the actual path that's failing. If that's not it, two causes worth checking: 1. A deleted file that's still open. Someone deletes a huge log file, but the program writing to it is still running. The file is gone from the folder, so du can't see it. The space doesn't come back until that program lets go of it. Check with: sudo lsof +L1 Look for "(deleted)" and the size next to it. Restarting the service that's holding it frees the space. 2. Out of inodes. Every file uses an inode, and a filesystem only has so many. Millions of tiny files, like cache or session files, can use them all up while there's still plenty of space left. Check with: df -i If IUse% is at 100%, that's your problem. Find the folder with the most files and clean it out the way that app expects.

@devXritesh Don't give the model access to tools that can move money in the first place. The model should be able to reason about information and only have access to tools that can't cause real damage. Everything else is left up to human authority.

@Denche2005 Move it to AWS and click auto scale! 😄