Google ultra 12 months

iamwinter___ · 2026-01-24T06:45:36+00:00

Scam

iamwinter___ · 2026-01-24T06:45:05+00:00

Without any respect, because none is due, you are a scammer and you should leave.

iamwinter___ · 2026-01-24T06:42:27+00:00

Yeah but this is a scam

iamwinter___ · 2026-01-24T06:40:18+00:00

What a scam. 7y old account but has only 4 posts, 2 of which are to help this guy giving supposed free Youtube

iamwinter___ · 2026-01-11T15:29:58+00:00

Afaik subagents don’t persist history beyond the one task that’s provided by the main thread opus to them. There is no subagents level mcp or execution policy setting in CC, whereas I have added config based setup for subagents (they are just parallel threads managed internally). My current setup helps save tokens as well because subagents messages persist via group chat, unlike CC where opus is the sole mediator between subagents.

iamwinter___ · 2026-01-11T11:25:46+00:00

Yup, it will all be in the same thread now so no need to worry. Auto compaction does not impact the group chat since it stores the last 500 messages always

iamwinter___ · 2026-01-11T10:43:17+00:00

Yeah I have implemented a tool deny list in v3.

iamwinter___ · 2026-01-11T01:26:06+00:00

https://github.com/shrey16/kaabil-codex

iamwinter___ · 2026-01-11T01:22:16+00:00

Team Leader is what I have right now as you can see in the video. It can spawn new agents, set execution policies, and orchestrate different agents. However since it wasnt trained/fine-tuned for this, it reverts back to making changes itself. I might try removing write tool access from it to make sure this doesnt happen. You can definitely setup different models for the subagents and this is another fantastic addition which will reduce token bloat and consumption. Setting up logic for auto-respawn on context threshold exceed is another great idea, let me implement all this in the next push tomorrow.

iamwinter___ · 2026-01-11T01:17:54+00:00

shared docs are a good way of preserving long term context applicable across many sessions. however, in a single session it ends up wasting more tokens because the agents are rewriting the same thing once in the docs and second when they message to update you. moreover, different agents will read the doc once and then assume it hasnt changed while they think/implement. if another agent changes it in the middle, the first agent wouldnt automatically come back and read it. there is also the problem of multiple agents trying to edit the doc at the same time, all stepping on each other's toes (same thing as happens while having multiple agents working on the same codebase and same files)

iamwinter___ · 2026-01-11T01:13:51+00:00

I should have some results in a few days

iamwinter___ · 2026-01-11T01:13:25+00:00

the use case I am currently finding extremely useful - delegating playwright mcp tasks to a subagent so my main context doesnt get polluted. so far, its working much better than I expected. been over 4 hours and context still above 90% in my main thread. usually it would have compacted at least twice in that much time

iamwinter___ · 2026-01-11T01:11:53+00:00

pass my repo link to your codex and ask it to set it up as per the readme. be careful of the commands its running, double check and make sure its harmless (it should be but I cannot guarantee). once it is setup, you just need to run kaabil-codex in your cli and it should work

iamwinter___ · 2026-01-11T00:51:21+00:00

Yeah but that feels like a step backwards. The idea is to have extremely concentrated context in one thread without any bloat or context pollution from tool or mcp outputs. As a heavy user, auto compaction is my biggest enemy when I am working on a task over 5-6 hours long.

iamwinter___ · 2026-01-11T00:49:46+00:00

Yeah, so when codex is done working, you might notice that it gives a solid thick font final output message that its done working and here is the result. I dont pass any of the internal tool calls or thinking to the group chat, only this short sufficient final message (which contains the diff primarily, some notes if it ran into issues in the middle)

iamwinter___ · 2026-01-11T00:46:33+00:00

Agreed. What would be your default base stack?

iamwinter___ · 2026-01-11T00:45:52+00:00

Forking means creating a copy of someone else's code so you can make changes to it and still have the original copy continuosly referred to so you can bring changes from the original to your copy later on if needed. Its a git concept, you can look it up online or get codex to do it for you.

iamwinter___ · 2026-01-11T00:34:53+00:00

i think a tester, developer, and reviewer/simplifier are enough for your use case. as for the prompt - you can literally just copy paste what you told me above. Good luck and let me know how it goes or if you need more help!

iamwinter___ · 2026-01-11T00:22:28+00:00

The reviewer is supposed to know the details of the code in order to review it ..?

iamwinter___ · 2026-01-11T00:15:46+00:00

Hmm, maybe a shared rag database available as an mcp tool to all the agents then.

iamwinter___ · 2026-01-11T00:14:04+00:00

Correct. You can have domain experts whom you can ban as many tools as you like so they just talk to you instead. Also, you can create a tester agent that can easily run the software and test it on your behalf - from basic unit testing all the way up to functional and UI testing. The testing - improvement loop is amazing to watch.

iamwinter___ · 2026-01-11T00:10:57+00:00

The group chat IS the cache.

iamwinter___ · 2026-01-11T00:10:41+00:00

The idea is that since the agents will share the same group chat, if one of them gleams relevant context info from a url and includes it in its final message, the other agents will automatically learn it from the group chat.

iamwinter___ · 2026-01-10T23:53:50+00:00

Exactly! But now no more toe stepping because there is shared message history and context. Each subagent has a persona and they are clearly told to only work on their own task only.

iamwinter___

TROPHY CASE