I usually copy paste snippet or function name that is affected and comment it. similar like you would sit next to coworker and tried to say where he/she messed up. agent is able to get location correctly

I know this is change of context, but I have full screen terminal toggled with keyboard shortcut and with middle mouse paste (Linux) I do not have to move cursor anywhere

Guake and Yakuake have this always-on-top terminal overlay mode which is really nice for this kind of workflow. Works exceptionally well with multiple workspaces I prefer one single big monitor with everything maximized and multiple workspaces.

iterm2 on mac also has a similar mode, but it is a bit finicky to set it up (it is really hidden in the settings).

Thanks for the reply. That makes sense. It’s sort of what I do too when I use codex/claude/t3 code, but usually via GUI.

The in-editor context review is something that does not seem long for first world. Sadly. Maybe I’ll be forced to make a zed extension or something, maybe on top of jujustu…

I use git diff and ctrl+click the file+linenumber which opens my IDE. Works well enough. I use this macro here when there are a lot of changes:

  gdf() { git diff '*'$1'*'; }

  gdf fileName (doesn't need full file name)

  gdf folderName (all files in a folder)

the compaction does not compact whole context, but keeps last ~20k tokens as is, I believe this helps a lot to model to not get confused what it is doing right now.

it also have soft/soft compaction limit, it tries to compact on turn boundary when possible. with combining with above this can get you about 35% more context (at least it looks like this with the sol)

codex when shell command is executed, will pull output with hard cap at max 30s, so for running compilation it will burn tokens without any benefit.

I have some tasks where agent will have to run some suite that can take over an hour, and codex burns about $20/h just waiting and reasoning every 30s "yep, that's still running". And what is going to happen after compaction, when whole context was just waiting? it will loose the plot and when I'm back it just does completely different thing that I asked it to do.

codex also have a bug, that opening refuses to resolve that adds your last steer after compaction, so imagine that you asked it to cleanup some tmp files or refactor/simplify something. it will do that again and again after each compaction, best case it just burns tokens and figures out, this is already done, or worse do it again and mess up everything and forget about it's task

in my experience pi does much better than codex for compaction and token use. And this is the main reason I switched to it.

migrating to the same compaction and exact tools as codex uses will make it at the same level as codex so what benefit will it have over codex? sure you can customize tui to your liking and add something on top, but the efficiency gains will be gone

there seems to be very big misunderstanding about what the "ultra" is, so let me explain it basing on the codex source code:

it's similar to Claude code ultracode.

there is no ultra effort level implemented on the backend. it's just alias in the codex to max effort setting and single line addition to prompt to use subagents proactively. that's all

as far as we know pro models work differently. for once those are backend implementations and they probably run multiple parallel reasonings for any chunk and use some judgement model to pick best version as persistent one. but that's what I believe is most popular guess, because this is openai secret sauce.

there is still no way to use pro models from codex, or at leat so far there is no trace of it anywhere.

> single line addition to prompt to use subagents proactively.

This misses an important detail. In Claude Code [1], ultracode suggests the agent create a JavaScript code to deterministically orchestrate sub agents. This is different from just having the main agent launch sub agents and (non-deterministically) manage them.

The resulting workflow is called “dynamic” because CC creates this orchestration script dynamically, “on the fly”.

[1] https://claude.com/blog/introducing-dynamic-workflows-in-cla...

Another useful thing about dynamic workflows is you can ask Claude to make them durable as skills (or slash command) that can be invoked later.

I believe inside Google they have a similar concept called “deterministic workflows”.

I find ultracode extremely useful. Of course you have to watch how your 5 hour and weekly session usage percentages are getting used. So I had Claude make a status-line with 3 progress bars: for context window, 5h session, 7d session:

https://pchalasani.github.io/claude-code-tools/tools/statusl...

Btw, the /loop “dynamic workflow” is so beyond broken/not working.

It’s sad to see folks like Karpathy make a big deal about looping, than to find that the loop command is broken and it’s crap vibe coded documentation isn’t even accurate on the Claude docs.

This whole dynamic workflow idea is on face bad. It’s all done as a massive cope for the fact that real determinism (I.e using structured outputs to enforce control flow of tools deterministically) is bad for alignment/safety so they can’t let you have access to those tools anymore…

Why is structured output a safety issue?

Can you explain what you find useful about ultracode? I've become wary of agent swarms since the early days and now just prefer to have a single agent spin for hours at time. Parallelism never got me anywhere worthwhile.

Not sure if it qualifies as "swarm" but they're useful for controlling context size. You can spin them off for context heavy things like research and analysis then only a much shorter summary gets passed back into the main context.

For instance, I was troubleshooting a 3rd party library issue and I spun a few off "check issue tracker for x", "check rust implementation for x", "check go implementation for x", "check Ruby implementation for x" to compare how different languages did or didn't handle http/2 for a service. They each returned a sentence or two worth of data to the main agent but consumed much more tokens in the process grepping code.

I got a security scan by route for one of our services that was pretty good and raised some useful results. Uses are few and far between for me tho tbh, also really expensive. I usually run a single agent with a subagent or two MAX

I feel like its only useful if the work you are doing doesn't have correctness as a high priority. If your work is okay with something only mostly being correct and it can just be slopped together over time then yes throw 500 agents at it. But otherwise you can't really review all that work as a single human and will quickly run out of capacity

I too used to be a skeptic of the whole "agent-swarms" hype. But I do find some patterns useful with ultracode:

- parallelism: "if it makes sense, use ultracode to do this thoroughly" Claude decides if this is the type of task that can benefit from a dynamic workflow. For example where there is a large number of similar independent sub-tasks, it can choose to set up a dynamic workflow, and it even sets up verifiers/tests etc to validate its work. In some cases it pushes back and decides not to set up a dynamic workflow and instead works on the task directly.

- verification loops: "Set up a dynamic workflow with adversarial checkers, and iterate until they are all green, up to some sensible limit". Similarly, I can include code-simplification steps and documentation-update steps.

These patterns help me leave it unattended for longer periods of time and return to a reasonable assurance of correct code.

Not parent but I find them great for analysis amongst other, to have each agent handle only its parts and bring back any issue even if it's clarified in other parts because that specific agent doesn't know about that, and the orchestrator is then on charge of handling that and making sure things are clarified in each parts that needs it without depending on side effect or side knowledge.

Same with code really but on a lower level, I find X agents working in concert on small task each and the orchestrator making sure of the overall coherence is better, focused better is usually a lot better.

I just wish Claude Code would give us more control over what kind of agent (in many case it would be great to have say Opus handle a bunch of Haiku agents but unless I'm blind you can't be decide what agent is what and you get all counted as opus anyway).

I'll sometimes use agent swarms for triaging quickly through a number of possible issues. For example, a single request for a code review to uncover all possible issues, followed by an agent swarm to dig deep into each issue to confirm or mark false positive.

sources for easy confirmation:

https://github.com/openai/codex/blob/98d28aab54ed86714901b66...

https://github.com/openai/codex/blob/98d28aab54ed86714901b66...

https://github.com/openai/codex/blob/98d28aab54ed86714901b66...

Very strange because in the TerminalBench benchmark Ultra does better than Sol. They didn’t add the reasoning level to the chart.

The nomenclature in this industry is all over the place.

That's strange. One can easily steer their session to use agents proactively.

Many features of the cli tooling of these providers can be achieved by prompting.

The way I see it is that they try to normalize and ease the use of practices established by the community.

ultracode in Claude Code kicks off a dynamic workflow.

It's similar in that it also pins you at xhigh effort _combined_ with the workflows (which one might say isn't far off from proactive use of agents)

big misconception

open source != open weights

open weights model is like... Winamp for example. it's free, you can download it and use it however you like, you could also do some binary patching or dll injections to alter it functionality but it's not enough to develop next version.

the same is with ai models, weights are the binary final artifacts. for development and improvements you need to have training data, pipelines, RL harnesses, etc.

also of you believe Chinese companies will be releasing weights indefinitely, you are not understanding motivations.

Chinese companies spend significant amounts of money to train a model so why they are releasing it for free? they basically provide researchers starting point for developing tooling and optimizations for serving the model in return. and also get some PR. They also do not have to pay for inference of those models that much, as they probably serve them with loss anyways to gain market. they are gov sponsored so money are not issue there, so they try to speedrun their way to what US companies have. And guess what happens when they reach it. they will stop releasing weights and increase pricing or will use them for gov purposes.

now, that should teach him to sell those on black marked instead

I'm mostly joking here, but Microsoft is one of few companies that handle cyber security in a way that really incentive people to not report them.

it's either by downplaying impact and not paying or paying very little or doing other researcher hostile activities.

especially that someone here mentioned some time ago that black market pays about 3x for the same class of vulnerability, so you need fairly high moral standards to go direct way

> but as far as I can tell those credit costs are an exact match for the API token costs listed for those models.

it is only true for USD. for example if you pay in euro, this is actually more expensive. kind of makes no sense, because it translates to $1 = €1

I'm assuming that right now all valves as computer controlled so why we cannot have best of both worlds? cannot we dynamically switch between Otto and Atkinson cycles by just changing valve profiles?

computer could use Otto cycle in case more power is needed in rare situations

> cannot we dynamically switch between Otto and Atkinson cycles by just changing valve profiles?

Toyota introduced this exact behaviour with their "Variable Valve Timing-intelligent Electric" (VVT-iE) system:

https://toyota-club.net/files/faq/16-01-01_faq_vvt_ie_eng.ht...

It uses an electric motor to control intake valve timing.

AFAIK all values are controlled by a camshaft. The computer doesn't get enough control. Solenoids seems like that are a possible replacement for CAMs, but they apparently have too many downsides.

Koenigsegg has an engine design that has a camless valve system based on their "Freevalve" technology. Its pretty cool.

https://en.wikipedia.org/wiki/Koenigsegg_TFG

huge red flag

> Non-technical teams are now shipping production code

if you vibe code financial systems this cannot mean anything good for your business

> Zero Electron imports remaining in the codebase

and you know that AI wrote all of it with minimal human supervision.

side note: last few days I noticed that vscode stopped leaking memory all over the place. when left idle it was taking all the ram I had + 20gb of swap space

and recently I noticed that I have half of the ram free.

I use insiders build btw, so stable might still not have those improvements