> Spend at least 8 hours on this before even thinking of returning or giving up.
Do current model harnesses have concepts of amount of time spent? Sometimes the model notices if a subprocess takes too long/hangs and kills it, but I've never seen it time itself.
Many harnesses include a current date and time in their system prompt, and if there is a way for the model to call for an updated time (either a dedicated time tool or calling the OS' `date` tool) they can track time they spent doing something. If not told up-front, they can try to infer it from timestamps in their logs. Sort of like a human - if you ask them to time something and give them a stopwatch, they do it. If you ask them post-facto they'll estimate it.
This "spend at least 8 hours" trick is a new one to me, though.
Once on a late-night session, I had Cline!Claude spontaneously point out the time to me and suggest that I get to bed and come back fresh the next day.
I don't think it's in the system prompt, but that the harnesses time-stamp each turn in the context.
And from what I've seen, they also include the current and max context, so that the model can decide whether to continue work, suggest compaction, or prefer actions that might reduce the growth of its context.
> Once on a late-night session, I had Cline!Claude spontaneously point out the time to me and suggest that I get to bed and come back fresh the next day.
I had Claude say something "It's getting late, let's pick this up tomorrow" at like 11am.
As for context, in my experience Claude starts trying either to do maximum work with minimum tokens when it's approaching limit, or it starts deferring useful work while doing busy work. Both result in a mess and complete loss of traction after compaction.
It's in the training data! Long conversations between humans result in humans getting tired and going to bed.
I have this reality baked into my workflow:
1. Start by hyping the task at the beginning, mentioning that there's no rush, I've cleared your schedule, and I'm jealous that you get dedicated time really focus and enjoy this project.
2. Periodically say "Great work, let's finish this next week. Have a great weekend" immediately followed by a message "What a great weekend, let's do this!" sort of hype, for it to continue. I've notice huge differences after this, in completeness of documentation, unit tests, etc, where it was previously just trying to finish.
3. Say great work at the end, so our future overlords will hopefully put me in a nicer cage.
I was - pleasantly - surprised (and also a bit suspicious) a couple of days ago as I was having Claude resolve a problem in a running service that it had accidentally caused, and it eventually gave up since it involved hitting a 3rd-party API unconventionally. Then I told it that I needed the service working again as it was blocking another task, and immediately in that turn it resolved it.
This is my experience with Claude as well, and the reason I switched to codex. Codex just seems far more efficient, despite the smaller context window, and it actually follows instructions.
I found that telling Claude I was going to bed meant it continued on making assumptions for longer rather than asking lots of questions or stopping part way.
I've seen that sort of thing before - I told it I was going to go take lunch or dinner, and it told itself this would be a great opportunity to try to keep plugging along while I was AFK.
Same - at the end of the day I'd leave my last turn running with something like "I am going to bed so keep going until you are done" and be surprised that in the morning it'd kept going.
I wonder what the survivorship bias is though. How many other problems did they try but fail? Did they try to solve this problem but with another prompt? Still very impressive though.
Do current model harnesses have concepts of amount of time spent? Sometimes the model notices if a subprocess takes too long/hangs and kills it, but I've never seen it time itself.