[HN Gopher] 1M context is now generally available for Opus 4.6 a...
___________________________________________________________________
1M context is now generally available for Opus 4.6 and Sonnet 4.6
Author : meetpateltech
Score : 1097 points
Date : 2026-03-13 17:19 UTC (1 days ago)
(HTM) web link (claude.com)
(TXT) w3m dump (claude.com)
| dimitri-vs wrote:
| The big change here is:
|
| > Standard pricing now applies across the full 1M window for both
| models, with no long-context premium. Media limits expand to 600
| images or PDF pages.
|
| For Claude Code users this is huge - assuming coherence remains
| strong past 200k tok.
| MikeNotThePope wrote:
| Is it ever useful to have a context window that full? I try to
| keep usage under 40%, or about 80k tokens, to avoid what Dex
| Horthy calls the dumb zone in his research-plan-implement
| approach. Works well for me so far.
|
| No vibes allowed:
| https://youtu.be/rmvDxxNubIg?is=adMmmKdVxraYO2yQ
| ogig wrote:
| When running long autonomous tasks it is quite frequent to
| fill the context, even several times. You are out of the loop
| so it just happens if Claude goes a bit in circles, or it
| needs to iterate over CI reds, or the task was too complex.
| I'm hoping a long context > small context + 2 compacts.
| boredtofears wrote:
| All of those things are smells imo, you should be very
| weary of any code output from a task that causes that much
| thrashing to occur. In most cases it's better to rewind or
| reset and adapt your prompt to avoid the looping (which
| usually means a more narrowly defined scope)
| grafmax wrote:
| A person has a supervision budget. They can supervise one
| agent in a hands-on way or many mostly-hands-off agents.
| Even though theres some thrashing assistants still get
| farther as a team than a single micromanaged agent. At
| least that's my experience.
| not_kurt_godel wrote:
| Just curious, what kind of work are you doing where
| agentic workflows are consistently able to make notable
| progress semi-autonomously in parallel? Hearing people
| are doing this, supposedly productively/successfully,
| kind of blows my mind given my near-daily in-depth LLM
| usage on complex codebases spanning the full stack from
| backend to frontend. It's rare for me to have a
| conversation where the LLM (usually Opus 4.6 these days)
| lasts 30 minutes without losing the plot. And when it
| does last that long, I usually become the bottleneck in
| terms of having to think about design/product/engineering
| decisions; having more agents wouldn't be helpful even if
| they all functioned perfectly.
| avereveard wrote:
| I've passed that bottleneck with a review task that
| produces engineering recommendations along six axis
| (encapsulation, decoupling, simplification, dedoupling,
| security, reduce documentation drift) and a ideation
| tasks that gives per component a new feature idea, an
| idea to improve an existing feature, an idea to expand a
| feature to be more useful. These two generate constant
| bulk work that I move into new chat where it's grouped by
| changeset and sent to sub agent for protecting the
| context window.
|
| What I'm doing mostly these days is maintaining a goal.md
| (project direction) and spec.md (coding and process
| standards, global across projects). And new macro tasks
| development, I've one under work that is meant to
| automatically build png mockup and self review.
| not_kurt_godel wrote:
| What are you using to orchestrate/apply changes? Claude
| CLI?
| avereveard wrote:
| I prefer in IDE tools because I can review changes and
| pull in context faster.
|
| At home I use roo code, at work kiro. Tbh as long as it
| has task delegation I'm happy with it.
| chrisweekly wrote:
| weary (tired) -> wary (cautious)
| saaaaaam wrote:
| Wary, not weary. Wary: cautious. Weary: tired.
| dentalnanobot wrote:
| This is really common, I think because there's also
| "leery" - cautious, distrustful, suspicious.
| SequoiaHope wrote:
| Yep I have an autonomous task where it has been running for
| 8 hours now and counting. It compacts context all the time.
| I'm pretty skeptical of the quality in long sessions like
| this so I have to run a follow on session to critically
| examine everything that was done. Long context will be
| great for this.
| lukan wrote:
| Are those long unsupervised sessions useful? In the
| sense, do they produce useful code or do you throw most
| of it away?
| brookst wrote:
| I get very useful code from long sessions. It's all about
| having a framework of clear documentation, a clear multi-
| step plan including validation against docs and critical
| code reviews, acceptance criteria, and closed-loop
| debugging (it can launch/restsart the app, control it,
| and monitor logs)
|
| I am heavily involved in developing those, and then
| routinely let opus run overnight and have either flawless
| or nearly flawless product in the morning.
| MikeNotThePope wrote:
| I haven't figured out how to make use of tasks running that
| long yet, or maybe I just don't have a good use case for it
| yet. Or maybe I'm too cheap to pay for that many API calls.
| ashdksnndck wrote:
| My change cuts across multiple systems with many
| tests/static analysis/AI code reviews happening in CI.
| The agent keeps pushing new versions and waits for
| results until all of them come up clean, taking several
| iterations.
| tudelo wrote:
| I mean if you don't have your company paying for it I
| wouldn't bother... We are talking sessions of 500-1000
| dollars in cost.
| takwatanabe wrote:
| Right. At Opus 4.6 rates, once you're at 700k context,
| each tool call costs ~$1 just for cache reads alone. 100
| tool calls = $100+ before you even count outputs.
| 'Standard pricing' is doing a lot of work here lol
| brookst wrote:
| Cache reads don't count as input tokens you pay for lol.
|
| https://www.claudecodecamp.com/p/how-prompt-caching-
| actually...
| dimitri-vs wrote:
| It's kind of like having a 16 gallon gas tank in your car
| versus a 4 gallon tank. You don't need the bigger one the
| majority of the time, but the range anxiety that comes with
| the smaller one and annoyance when you DO need it is very
| real.
| scwoodal wrote:
| Except after 4 gallons it might as well be pure oil,
| mucking everything up.
| steve-atx-7600 wrote:
| It seems possible, say a year or two from now that context
| is more like a smart human with a "small", vs "medium" vs
| "large" working memory. The small fellow would be able to
| play some popular songs on the piano , the medium one plays
| in an orchestra professionally and the x-large is like
| Wagner composing Der Ring marathon opera. This is my
| current, admittedly not well informed mental model anyway.
| Well, at least we know we've got a little more time before
| the singularity :)
| twodave wrote:
| It's more like the size of the desk the AI has to put
| sheets of paper on as a reference while it builds a Lego
| set. More desk area/context size = able to see more
| reference material = can do more steps in one go. I've
| lately been building checklists and having the LLM
| complete and check off a few tasks at a time, compacting
| in-between. With a large enough context I could just
| point it at a PLAN.md and tell it to go to work.
| SkyPuncher wrote:
| Yes. I've recently become a convert.
|
| For me, it's less about being able to look back -800k tokens.
| It's about being able to flow a conversation for a lot longer
| without forcing compaction. Generally, I really only need the
| most recent ~50k tokens, but having the old context sitting
| around is helpful.
| hombre_fatal wrote:
| Also, when you hit compaction at 200k tokens, that was
| probably when things were just getting good. The plan was
| in its final stage. The context had the hard-fought nuances
| discovered in the final moment. Or the agent just
| discovered some tiny important details after a crazy 100k
| token deep dive or flailing death cycle.
|
| Now you have to compact and you don't know what will
| survive. And the built-in UI doesn't give you good tools
| like deleting old messages to free up space.
|
| I'll appreciate the 1M token breathing room.
| roygbiv2 wrote:
| I've found compactation kills the whole thing. Important
| debug steps completely missing and the AI loops back
| round thinking it's found a solution when we've already
| done that step.
| garciasn wrote:
| For me, Claude was like that until about 2m ago. Now it
| rarely gets dumb after compaction like it did before.
| 8note wrote:
| oh, ive found that something about compaction has been
| dropping everything that might be useful. exact opposite
| experience
| s900mhz wrote:
| I find it useful to make Claude track the debugging
| session with a markdown file. It's like a persistent
| memory for a long session over many context windows.
|
| Or make a subagent do the debugging and let the main
| agent orchestrate it over many subagent sessions.
| roygbiv2 wrote:
| Yeah I use a markdown to put progress in. It gets kinda
| long and convoluted a manual intervention is required
| every so often. Works though.
| saaaaaam wrote:
| That video is bizarre. Such a heavy breather.
| coldtea wrote:
| What a weird and inconsequential thing to focus on...
|
| He's just fucking closely miced with compression + speaking
| fast and anxious/excited speaking to an audience
| indigodaddy wrote:
| Most of that is just nervousness
| maskull wrote:
| After running a context window up high, probably near 70% on
| opus 4.6 High and watching it take 20% bites out of my 5hr
| quota per prompt I've been experimenting with dumping context
| after completing a task. Seems to be working ok. I wonder if
| I was running into the long context premium. Would that apply
| to Pro subs or is just relevant to api pricing?
| ricksunny wrote:
| Since I'm yet to seriously dive into vibe coding or AI-
| assisted coding, does the IDE experience offer tracking a
| tally of the context size? (So you know when you're getting
| close or entering the "dumb zone")?
| stevula wrote:
| Most tools do, yes.
| quux wrote:
| OpenCode does this. Not sure about other tools
| nujabe wrote:
| > Since I'm yet to seriously dive into vibe coding or AI-
| assisted coding
|
| Unless you're using a text editor as an IDE you probably
| have already
| MikeNotThePope wrote:
| The 2 I know, Cursor and Claude Code, will give you a
| percentage used for the context window. So if you know the
| size of the window, you can deduce the number of tokens
| used.
| brookst wrote:
| Claude code also gives you a granular breakdown of what's
| using context window (system prompt, tools, conversation
| history, etc). /context
| 8note wrote:
| Cline gives you such a thing. you dont really know where
| the dumb zone by numbers though, only by feel.
| jfim wrote:
| In Claude code I believe it's /context and it'll give you a
| graphical representation of what's taking context space
| furyofantares wrote:
| I'd been on Codex for a while and with Codex 5.2 I:
|
| 1) No longer found the dumb zone
|
| 2) No longer feared compaction
|
| Switching to Opus for stupid political reasons, I still have
| not had the dumb zone - but I'm back to disliking compaction
| events and so the smaller context window it has, has really
| hurt.
|
| I hope they copy OpenAI's compaction magic soon, but I am
| also very excited to try the longer context window.
| iknowstuff wrote:
| Hmm I've felt the dumb zone on codex
| nomel wrote:
| From what I've seen, it means whatever he's doing is
| _very_ statistically significant.
| mgambati wrote:
| 1m context in OpenAI and Gemini is just marketing. Opus is
| the only model to provide real usable bug context.
| hu3 wrote:
| Source? I ask because I use 500k+ context on these on a
| daily basis.
|
| Big refactorings guided by automated tests eat context
| window for breakfast.
| 8note wrote:
| i find gemini gets real real bad when you get far into
| the context - gets into loops, forgets how to call tools,
| etc
| girvo wrote:
| I find gemini does that normally, personally. Noticeably
| worse in my usage than either Claude or Codex.
| petesergeant wrote:
| I find Gemini to be real bad. Are you just using it for
| price reasons, or?
| baq wrote:
| yeah gemini is dumb when you tell it to do stuff - _but_
| the things it finds (and critically confirms, including
| doing tool calls while validating hypotheses) in reviews
| absolutely destroy both gpt and opus.
|
| if you're a one-model shop you're losing out on quality
| of software you deliver, _today_. I predict we 'll all
| have at least two harness+model subscriptions as a matter
| of course in 6-12 months since every model's jagged
| frontier is different at the margins, and the margins are
| very fractal.
| Bolwin wrote:
| How many big refactorings are you doing? And why?
| kimi wrote:
| How is that relevant? we are talking about models, now
| what you do with them.
| johnebgd wrote:
| Codex high reasoning has been a legitimately excellent
| tool for generating feedback on every plan Claude opus
| thinking has created for me.
| furyofantares wrote:
| I'm directly conveying my actual experience to you. I
| have tasks that fill up Opus context very quickly (at the
| 200k context) and which took MUCH longer to fill up Codex
| since 5.2 (which I think had 400k context at the time).
|
| This is direct comparison. I spent months subscribed to
| both of their $200/mo plans. I would try both and Opus
| always filled up fast while Codex continued working
| great. It's also direct experience that Codex continues
| working great post-compaction since 5.2.
|
| I don't know about Gemini but you're just wrong about
| Codex. And I say this as someone who hates reporting
| these facts because I'd like people to stop giving OpenAI
| money.
| sagarpatil wrote:
| This has been my experience too.
| genewitch wrote:
| Have any of you heard of map reduce
| throwthrowuknow wrote:
| I agree even though I used to be a die hard Claude fan I
| recently switched back to ChatGPT and codex to try it out
| again and they've clearly pulled into the lead for
| consistency, context length and management as well as
| speed. Claude Code instilled a dread in me about keeping
| an eye on context but I'm slowly learning to let that go
| with codex.
| HarHarVeryFunny wrote:
| Surely compaction is down to the agent rather than the
| model, so are you comparing Claude Code to Codex CLI?
| alex_sf wrote:
| It's both.
| karmasimida wrote:
| This is true.
|
| When I am using codex, compaction isn't something I fear,
| it feels like you save your gaming progress and move on.
|
| For Claude Code compaction feels disastrous, also much
| longer
| pjerem wrote:
| If you use OpenCode (open source Claude Code
| implementation), you can configure compaction yourself :
| https://opencode.ai/docs/en/config/#compaction
| comboy wrote:
| Not sure if it's a common knowledge but I've learned not
| that long ago that you can do "/compact your instructions
| here", if you just say what you are working on or what to
| keep explicitly it's much less painful.
|
| In general LLMs for some reason are really bad at
| designing prompts for themselves. I tested it heavily on
| some data where there was a clear optimization function
| and ability to evaluate the results, and I easily beat
| opus every time with my chaotic full of typos prompts vs
| its methodological ones when it is writing instructions
| for itself or for other LLMs.
| brookst wrote:
| You can also put guidance for when to compact and with
| what instructions into Claude.md. The model itself can
| run /compact, and while I try to remember to use it
| manually, I find it useful to have "If I ask for a
| totally different task and the current context won't be
| useful, run /compact with a short summary of the new
| focus"
| copperx wrote:
| I ofter wonder if I'm missing something, but shouldn't we
| be able to edit the context manually???
|
| In that way we could erase prompts and responses that
| didn't yield anything useful or derailed the model.
|
| Why can't we do that?
| genewitch wrote:
| so you have to garbage collect manually for the AI?
|
| also, i don't want to make a full parent post
|
| 1M tokens sounds real expensive if you're constantly at
| that threshold. There's codebases larger in LOC; i read
| somewhere that Carmack has "given to humanity" over 1
| million lines of his code. Perhaps something to dwell on
| furyofantares wrote:
| OpenAI has some magic they do on their standalone
| endpoint (/responses/compact) just for compaction, where
| they keep all the user messages and replace the agent
| messages or reasoning with embeddings.
|
| > This list includes a special type=compaction item with
| an opaque encrypted_content item that preserves the
| model's latent understanding of the original
| conversation.
|
| Some prior discussion here
| https://news.ycombinator.com/item?id=46737630#46739209
| regarding an article here
| https://openai.com/index/unrolling-the-codex-agent-loop/
| radicality wrote:
| Using Codex more for now, and there is definitely some
| compaction magic. I'm keeping the same conversation going
| and going for days, some at almost 1B tokens (per the codex
| cli counters), with seemingly no coherency loss
| twodave wrote:
| I mean, try using copilot on any substantial back-end
| codebase and watch it eat 90+% just building a
| plan/checklist. Of course copilot is constrained to 120k I
| believe? So having 10x that will blow open up some doors that
| have been closed for me in my work so far.
|
| That said, 120k is pleeenty if you're just building front-end
| components and have your API spec on hand already.
| bushbaba wrote:
| Yes. I've used it for data analysis
| kaizenb wrote:
| Thanks for the video.
|
| His fix for "the dumb zone" is the RPI Framework:
|
| * RESEARCH. Don't code yet. Let the agent scan the files
| first. Docs lie. Code doesn't.
|
| * PLAN. The agent writes a detailed step-by-step plan. You
| review and approve the plan, not just the output. Dex calls
| this avoiding "outsourcing your thinking." The plan is where
| intent gets compressed before execution starts.
|
| * IMPLEMENT. Execute in a fresh context window. The meta-
| principle he calls Frequent Intentional Compaction: don't let
| the chat run long. Ask the agent to summarize state, open a
| new chat with that summary, keep the model in the smart zone.
| girvo wrote:
| That's fascinating: that is identical to the workflow I've
| landed on myself.
| hedora wrote:
| It's also identical to what Claude Code does if you put
| it in plan mode (bound to <tab> key), at least in my
| experience.
| girvo wrote:
| My annoyance with plan mode is where it sticks the .md
| file, kind of hides it away which makes it annoying to
| clear context and start up a new phase from the PLAN
| file. But that might just be a skill issue on my end
| hedora wrote:
| Even worse, it just randomly blows away the plan file
| without asking for permission.
|
| No idea what they were thinking when they designed this
| feature. The plan file names are randomly generated, so
| it could just keep making new ones forever for free (it
| would take a _LONG_ time for the disk space to matter),
| but instead, for long plans, I have to back the plan file
| up if it gets stuck. Otherwise, I say "You should take
| approach X to fix this bug", it drops into plan mode,
| says "This is a completely unrelated plan", then deletes
| all record of what it was doing before getting stuck.
| girvo wrote:
| It's not just me then! Hah good to know. It's why I've
| started ignoring plan modes in most agent harnesses, and
| managing it myself through prompting and keeping it in
| the code base (but not committed)
| toddmerrill wrote:
| My experience also. The claude code document feature is a
| real missed opportunity. As you can see in this
| discussion, we all have to do it manually if we want it
| to work.
| kaizenb wrote:
| After creating the plan in Plan mode (+Thinking) I ask
| Claude to move the plan .md file to /docs/plans folder
| inside the repo.
|
| Open a new chat with Opus, thinking mode is off. Because
| no need when we have detailed plan.
|
| Now the plan file is always reachable, so when the
| context limit is narrowing, mostly around 50%, I ask
| Claude to update the plan with the progress, and move to
| a new chat @pointing the plan file and it continue
| executing without any issue.
| insane_dreamer wrote:
| better to instruct it to write a plan .md file that is
| appropriately named so that it can be easily
| referenced/updated in multiple sessions. I've found that
| effective.
| cortesoft wrote:
| It's the style spec-kit uses:
| https://github.com/github/spec-kit
|
| Working on my first project with it... so far so good.
| iamacyborg wrote:
| > RESEARCH. Don't code yet. Let the agent scan the files
| first. Docs lie. Code doesn't.
|
| I find myself often running validity checks between docs
| and code and addressing gaps as they appear to ensure the
| docs don't actually lie.
| silverlake wrote:
| I have Codex and Gemini critique the plan and generate
| their plans. Then I have Claude review the other plans
| and add their good ideas. It frequently improves the
| plan. I then do my careful review.
| ArtRichards wrote:
| This is exactly how I've found leads to most consistent
| high quality results as well. I don't use gemini yet
| (except for deep research, where it pulls WAY ahead of
| either of the other 'grounding' methods)
|
| But Codex to plan big features and Claude to review the
| feature plan (often finds overlooked discrepancies) then
| review the milestones and plan implementation of them in
| planning mode, then clear context and code. Works great.
| Huppie wrote:
| More recently I've been doing the implement phase without
| resetting the whole context when context is still < 60%
| full and must say I find it to be a better workflow in many
| cases (depends a bit on the size of the plan I suppose.)
|
| It's faster because it has already read most relevant
| files, still has the caveats / discussion from the research
| phase in its context window, etc.
|
| With the context clear the plan may be good / thorough but
| I've had one too many times that key choices from the
| research phase didn't persist because halfway through
| implementation Opus runs into an issue and says _" You know
| what? I know a simpler solution."_ and continues down a
| path I explicitly voted down.
| greenchair wrote:
| How is that Plan strategy not "outsourcing your thinking"
| because that's exactly what it sounds like. AI does the
| heavy lifting and you are the editor.
| brookst wrote:
| Is a VP of engineering "outsourcing their thinking" by
| having an org that can plan and write software?
| Filligree wrote:
| Yes.
| Eldt wrote:
| Delegation is generally all about outsourcing, so hard
| agree
| brookst wrote:
| Interesting take. Does that mean SWE's are outsourcing
| their thinking by relying on management to run the
| company, designers to do UX, support folks to handle
| customers?
|
| Or is _thinking about source code line by line_ the only
| valid form of thinking in the world?
| qualifck wrote:
| I mean yes? That's like, the whole idea behind having a
| team. The art guy doesn't want to think about code, the
| coder doesn't want to think about finances, the
| accountant doesn't want to worry about customer support.
| It would be kind of a structural failure if you weren't
| outsourcing at least some of your thinking.
| dahart wrote:
| Add a REFLECT phase after IMPLEMENT. I'm finding it's
| extremely useful to ask agents for implementation notes and
| for code reviews. These are different things, and when I
| ask for implementation notes I get very different output
| than the implementation summary it spits out automatically.
| I ask the agent to surface all design choices it had to
| make that we didn't explicitly discuss in the plan, and
| then check in the plan + impl notes in order to help
| preload context for the next thing.
|
| My team has been adopting a separation of plan & implement
| organically, we just noticed we got better output that way,
| plus Claude now suggests in plan mode to clear context
| first before implementing. We are starting to do team
| reviews on the plan before the implement phase. It's often
| helpful to get more eyeballs on the plan and improve it.
| Barbing wrote:
| Looking at this URL, typo or YouTube flip the si tracking
| parameter?
| youtu.be/rmvDxxNubIg?is=adMmmKdVxraYO2yQ
| MikeNotThePope wrote:
| I just cut & pasted the share URL provided by YouTube.
| Strip out the query param if you like.
| dev_l1x_be wrote:
| I never use these giant context windows. It is pointless.
| Agents are great at super focused work that is easy to re-do.
| Not sure what is the use case for giant context windows.
| hrmtst93837 wrote:
| Maxing out context is only useful if all the information is
| directly relevant and tightly scoped to the task. The model's
| performance tends to degrade with too much loosely related
| data, leading to more hallucinations and slower results.
| Targeted chunking and making sure context stays focused
| almost always yields better outcomes unless you're attempting
| something atypical, like analyzing an entire monorepo in one
| shot.
| wat10000 wrote:
| I've used it many times for long-running investigations. When
| I'm deep in the weeds with a ton of disassembly listings and
| memory dumps and such, I don't really want to interrupt all
| of that with a compaction or handoff cycle and risk losing
| important info. It seems to remain very capable with large
| contexts at least in that scenario.
| alecco wrote:
| Offtopic: I find it remarkable the shortened YT url has a
| tracking cost of 57% extra length. We live in stupid times.
| dahart wrote:
| I care about the privacy implications, but not the length.
| Out of curiosity, why do you care about the URL length at
| all? What is the cost to you?
| alecco wrote:
| My point is Google engineers go to the trouble of setting
| up a URL shortener service on one hand, but on the other
| hand it seems ad the business anti-privacy executives can
| override anything. This points out it's a dysfunctional
| company.
| inemesitaffia wrote:
| The point is whatever group controls the money controls
| the power.
|
| Also, only the domain is shorter
| alecco wrote:
| Actually, it's not just the domain:
|
| https://youtu.be/X
|
| https://www.youtube.com/watch?v=X
| dahart wrote:
| You'd rather have the video code and the tracking code
| baked into the same code just to save a couple of
| characters? Why? That would result in a longer code than
| the video code alone, you would save very few characters.
| It would not be nicer to look at or functionally any
| different, and it would obscure the fact that it's being
| tracked and prevent people from being able to edit the
| URL to remove the tracking. I appreciate the fact that I
| can see that the URL has a tracking ID and that I can
| edit the URL and remove the tracking ID. I do not want a
| shorter URL if I lose that ability. What you're
| complaining about and wishing for would be MUCH worse
| than what it currently is.
| alecco wrote:
| I didn't say that.
| dahart wrote:
| Then your point eludes me. You complained about the
| length. If you don't want it shorter, then what do you
| want?
|
| To me, the fact that the tracking code is visible and
| separate from the video code is evidence of the complete
| opposite of your conclusion - it's evidence the ad
| business does not get to override either engineering nor
| what's left of privacy control. Ad execs would surely
| prefer that the tracking code is not visible nor manually
| removeable.
| alecco wrote:
| I didn't complain about length per se. I pointed out
| Google's contradiction. As my previous comment clarified.
| Jesus.
| tarbyqualia wrote:
| For the same reason people use link shorteners at all.
| It's much more pleasant to look at and makes people more
| likely to press it compared to a paragraph-long URL full
| of tracking garbage.
| dahart wrote:
| Please. The URL above is pretty short, this is not the
| kind of URL link shorteners were made for, in fact it's
| already shortened, as @alecco pointed out.
|
| Pleasant? I could not care less about the pleasantness of
| the video code, but a shortened URL in this case would
| not be more pleasant, and it would be functionally worse,
| and barely shorter; all you'd be able to trim is the
| "?si=". I'm baffled by this thread.
| virtualritz wrote:
| I haven't hit the "dumb zone" any more since two months. I
| think this talk is outdated.
|
| I'm using CC (Opus) thinking and Codex with xhigh on always.
|
| And the models have gotten really good when you let them do
| stuff where goals are verifiable by the model. I had Codex
| fix a Rust B-rep CSG classification pipeline successfully
| over the course of a week, unsupervised. It had a custom STEP
| viewer that would take screenshots and feed them back into
| the model so it could verify the progress resp. the triangle
| soup (non progress) itself.
|
| Codex did all the planning and verification, CC wrote the
| code.
|
| This would have not been possible six months ago at all from
| my experience.
|
| Maybe with a lot of handholding; but I doubt it (I tried).
|
| I mean both the problem for starters (requires a lot of
| spatial reasoning and connected math) and the autonomous
| implementation. Context compression was never an issue in the
| entire session, for either model.
| islewis wrote:
| The quality with the 1M window has been very poor for me,
| specifically for coding tasks. It constantly forgets stuff that
| has happened in the existing conversation. n=1, ymmv
| robwwilliams wrote:
| Yes, especially with shifts in focus of a long conversation.
| But given the high error rates of Opus 4.6 the last few weeks
| it is possibly due to other factors. Conversational and code
| prodding has been essential.
| hagen8 wrote:
| Well, the question is what is contributing to the usage.
| Because as the context grows, the amount of input tokens are
| increasing. A model call with 800K token as input is 8 times
| more expensive than a model call with 100K tokens as input.
| Especially if we resume a conversation and caching does not
| hit, it would be very expensive with API pricing.
| a_e_k wrote:
| I've been using the 1M window at work through our enterprise
| plan as I'm beginning to adopt AI in my development workflow
| (via Cline). It seems to have been holding up pretty well until
| about 700k+. Sometimes it would continue to do okay past that,
| sometimes it started getting a bit dumb around there.
|
| (Note that I'm using it in more of a hands-on pair-programming
| mode, and not in a fully-automated vibecoding mode.)
| chatmasta wrote:
| So a picture is worth 1,666 words?
| jFriedensreich wrote:
| yeah it totally does not remain coherent past 200k, would have
| been too nice.
| __MatrixMan__ wrote:
| I bet it depends how homogenous the context is. I bet it
| works ok near 1M in some cases, but as far as I can tell,
| those cases are rare.
| Bombthecat wrote:
| If it's not coding, even with 200k context it starts to write
| gibberish, even with the correct information in the context.
|
| I tried to ask questions about path of exile 2. And even with
| web research on it gave completely wrong information... Not
| only outdated. Wrong
|
| I think context decay is a bigger problem then we feel like.
| reactordev wrote:
| That's not context decay, that's training data ambiguity. So
| much misinformation, nerfs, buffs, changes that an LLM can
| not keep up given the training time required. Do it for a
| game that has been stable and it knows its stuff.
| Bombthecat wrote:
| It didnt gave outdated, on some cases it did, and with two
| tries telling it to search for updated information it got
| it right ( shouldn't need to do that though) but it also
| gave wrong information about sockets ( support skills) ,
| which never existed or never were able to be socketed
| together in the first place. ( Ok maybe in 0.1, but that's
| what web search is for ... ) If it even can't handle easy
| versioned information from a game. How should it handle
| anything related to time, dates, news, science etc?
| serial_dev wrote:
| Please don't pop the AI bubble, bro. Stop asking
| questions, bro. Believe the hype, bro.
| reactordev wrote:
| Like any human would, 75% certain with 99% confidence.
| That's what you fail to realize. They aren't "god mode
| machine". They are "human-mode" machines and humans make
| mistakes in thinking just like you do. Some might say
| asking a powerful LLM for gaming tips is a waste of
| compute power. Others might say it gives you the
| knowledge of a new meta emerging. Either way, you both
| are going to get trained.
| turbostyler wrote:
| We need an MCP for path of building
| blueblisters wrote:
| I think ChatGPT has a huge advantage here. They have been
| collecting realistic multi-turn conversational data at a much
| larger scale. And generally their models appear to be more
| coherent with larger contexts for general purpose stuff.
| eric_cc wrote:
| It could also be a skill problem. It would be more helpful if
| when people made llm sucks claims they shared their prompt.
|
| The people I work with who complain about this type of thing
| horribly communicate their ask to the llm and expect it to
| read their minds.
| namr2000 wrote:
| I don't really understand what you mean by this. The claim
| is that the same prompt with the same question produces
| worse results when it's queried in a model that has more
| than 200k tokens in its context. That doesn't have to do
| much with the "skillfulness" of using a model.
| alwillis wrote:
| Totally agree the LLM sucks posts should be accompanied
| with the prompt.
| copperx wrote:
| I agree, but at the same time it feels like victim
| blaming.
| akersten wrote:
| I don't know. Is pointing out that someone holding a
| drill by the chuck won't get the results they expect that
| bad?
| theshrike79 wrote:
| Nah, it's a variant of the XY Problem:
| https://xyproblem.info
| AStrangeMorrow wrote:
| Prompt quality does matter, but at some point context side
| does matter.
|
| I've had thing like a system that has a collection of
| procedural systems. I would say "replace the following set
| of defaults that are passed all around for system X (list
| of files) and in the managed (file) by a config" and it
| would do that but I'd suddenly see it be like "wait mu and
| projection distance are also present in system Y and Z. Let
| me replace that by a config too with the same values". When
| system Y and Z uses a different set of optimized values,
| and that was clearly outside of the scope.
|
| Never had that kind of mistakes happen when dealing with
| small contexts, but with larger contexts (multiple files,
| long "thinking" sequences) it does happen sometimes.
|
| Definitely some times when I though "oh well my bad, I
| should have clarified NOT to also change that other part",
| all the while thinking that no human would have thought to
| change both
| trollbridge wrote:
| None of what has been described is a "skill issue". The
| problem is when an identical prompt produces poor results
| once the context window exceeds 200k tokens or so.
| Lord-Jobo wrote:
| Context decay is noticeable within 3 messages, nearly every
| time. Maybe not substantial, but definitely noticeable.
|
| It's lead to me starting new chats with bigger and bigger
| starting 'summary, prompts to catch the model up while
| refreshing it. Surely there's a way to automate that
| technique.
| nvardakas wrote:
| I've found the same thing. I build with Claude Code daily
| and the context decay is real by the end of a long session
| it starts forgetting decisions we made earlier. The 1M
| context window should help but I'm curious how coherence
| holds up at that scale.
|
| What's been working for me is keeping a CLAUDE.md file in
| my project root with key decisions and context. The model
| reads it at the start of every session so I don't have to
| re-explain everything. Not as elegant as automated
| compaction but it works.
| visarga wrote:
| > I build with Claude Code daily and the context decay is
| real by the end of a long session it starts forgetting
| decisions we made earlier
|
| I generate task.md files before working on anything, some
| are short, others are super long and with many steps. The
| models don't deviate anymore. One trick is to make a post
| tool use hook to show the first open gate "- [ ]" line
| from task.md on each tool call. This keeps the agent
| straight for 100s of gates.
|
| After each gate is executed we don't just check it, we
| also append a few words of feedback. This makes the
| task.md become a workbook, covering intent, plan,
| execution and even judgements. I see it like a
| programming language now. I can gate any task and the
| agent will do it, however many steps. It can even
| generate new gates, or replan itself midway.
|
| You can enforce strict testing policies by just leaning
| into gate programability power - after each work gate
| have a test gate, and have judges review testing quality
| and propose more tests.
|
| The task.md file is like a script or pipeline. It is also
| like a first class function, it can even ingest other
| task.md files for regular reflexion. A gate can create or
| modify gates, or tasks. A task can create or modify gates
| or tasks.
| AStrangeMorrow wrote:
| Yeah absolutely, at this point I also start new chats after
| 3-4 prompts. Especially with thinking models that produce
| so many tokens.
|
| Usually things go smoothly but sometimes I have situations
| like: "please add feature X, needs to have ABCD." -> does
| ABC correct but D wrong -> "here is how to fix D" -> fixes
| D but breaks AB -> "remember I also want AB this way, you
| broke it" -> fixes AB but removes C and so on
| wouldbecouldbe wrote:
| I feel like few weeks ago i suddenly had a week where even
| after 3 messages it forgot what we did. Seems fixed now.
| gorjusborg wrote:
| The question that comes to mind for me after reading your
| comment is how can a question about a game require that much
| context?
| Bombthecat wrote:
| Path of exile is complex, just check the skill tree ,
| skills and gems:)
|
| It could almost be used as a benchmark good models are in
| math, memory, updated information etc
| AnotherGoodName wrote:
| Fwiw put a copy of the game folder in a directory and tell
| claude to extract game files and dissasemble the game in
| preparation for questions about the game.
|
| As an example of doing this in a session with jagged alliance
| 3 (an rpg) https://pastes.io/jagged-all-69136
|
| Claude extracting game archives and dissasembling leads to
| far more reliable results than random internet posts.
| jnovek wrote:
| You're having Claude design builds for you by disassembling
| the game? Am I understanding that right? I guess I'm
| thinking too small.
| AnotherGoodName wrote:
| Yes exactly. Claude can just go in, extract the
| compressed game archives, decompile and read the game
| logic directly for how everything works. ie. You might be
| curious how certain stats translate into damage. Just do
| the above and ask Claude "in detail explain from the
| decompiled code in this folder for game X how certain
| stats affect damage and suggest builds to maximise damage
| taking into account character level <10.".
|
| I've found doing this for games to be far more reliable
| than trying to find internet posts explaining it. I
| haven't played POE but if it's anything like any other
| RPG system Claude will do a great job at this.
| heraldgeezer wrote:
| This will not work for an online game like PoE 2
|
| Or even one with DRM?
|
| Right?
|
| Or?
| AnotherGoodName wrote:
| DRM just stops you launching/connecting to servers if you
| modified the binary. It does nothing to stop the binary
| being pulled apart by a bot with no intention of running
| it.
|
| The place it may fail is obfuscation and server side
| logic. But generally client side logic, especially in a
| game with a scripted language backing it, is super easy
| for claude ot pick apart.
| __MatrixMan__ wrote:
| Agreed, there's no getting around the "break it into smaller
| contexts" problem that lies between us and generally useful
| AI.
|
| It'll remain a human job for quite a while too. Separability
| is not a property of vector spaces, so modern AIs are not
| going to be good at it. Maybe we can manage something similar
| with simplical complexes instead. Ideally you'd consult the
| large model once and say:
|
| > show me the small contexts to use here, give me prompts re:
| their interfaces with their neighbors, and show me which
| distillations are best suited to those tasks
|
| ...and then a network of local models could handle it from
| there. But the providers have no incentive to go in that
| direction, so progress will likely be slow.
| holoduke wrote:
| Number one thing you always need to accomplish are feedback
| loops for Claude so it's able to shotgun program itself to a
| solution.
| jnovek wrote:
| What were you asking about PoE 2? So far my _general_
| experience with asking LLMs about ARPGs has been meh. Except
| for Diablo 2 but I think that's just because Diablo 2 has
| been heavily discussed for ~25 years.
| staticman2 wrote:
| Adding web search doesn't necessarily lead to better
| information at any context.
|
| In my experience the model will assume the web results are
| the answer even if the search engine returns irrelevant
| garbage.
|
| For example you ask it a question about New Jersey law and
| the web results are about New York or about "many states"
| it'll assume the New York info or "many states" info is about
| New Jersey.
| j45 wrote:
| This might burn through usage faster too though.
| minimaxir wrote:
| Claude Code 2.1.75 now no longer delineates between base Opus and
| 1M Opus: it's the same model. Oddly, I have Pro where the change
| supposedly only for Max+ but am still seeing this to be case.
|
| EDIT: Don't think Pro has access to it, a typical prompt just hit
| the context limit.
|
| The removal of extra pricing beyond 200k tokens may be
| Anthropic's salvo in the agent wars against GPT 5.4's 1M window
| and extra pricing for that.
| auggierose wrote:
| No change for Pro, just checked it, the 1M context is still
| extra usage.
| zaptrem wrote:
| I have Max 20x and they're still separate on 2.1.75.
| convenwis wrote:
| Is there a writeup anywhere on what this means for effective
| context? I think that many of us have found that even when the
| context window was 100k tokens the actual usable window was
| smaller than that. As you got closer to 100k performance degraded
| substantially. I'm assuming that is still true but what does the
| curve look like?
| minimaxir wrote:
| The benchmark charts provided _are_ the writeup. Everything
| else is just anecdata.
| tyleo wrote:
| I mentioned this at work but context still rots at the same
| rate. 90k tokens consumed has just as bad results in 100k
| context window or 1M.
|
| Personally, I'm on a 6M+ line codebase and had no problems with
| the old window. I'm not sending it blindly into the codebase
| though like I do for small projects. Good prompts are necessary
| at scale.
| FartyMcFarter wrote:
| Isn't transformer attention quadratic in complexity in terms of
| context size? In order to achieve 1M token context I think
| these models have to be employing a lot of shortcuts.
|
| I'm not an expert but maybe this explains context rot.
| vlovich123 wrote:
| Nope, there's no tricks unless there's been major
| architectural shifts I missed. The rot doesn't come from
| inference tricks to try to bring down quadratic complexity of
| the KV cache. Task performance problems are generally a
| training problem - the longer and larger the data set, the
| fewer examples you have to train on it. So how do you train
| the model to behave well - that's where the tricks are. I
| believe most of it relies on synthetically generated data if
| I'm not mistaken, which explains the rot.
| FartyMcFarter wrote:
| A quick Google search reveals terms such as "sparse
| attention" that are used to avoid quadratic runtime.
|
| I don't know if Anthropic has revealed such details since
| AI research is getting more and more secretive, but the
| architectural tricks definitely exist.
| esperent wrote:
| > As you got closer to 100k performance degraded substantially
|
| In practice, I haven't found this to be the case at all with
| Claude Code using Opus 4.6. So maybe it's another one of those
| things that used to be true, and now we all expect it to be
| true.
|
| And of course when we expect something, we'll find it, so any
| mistakes at 150k context use get attributed to the context,
| while the same mistake at 50k gets attributed to the model.
| peacebeard wrote:
| My personal experience is that Opus 4.6 degrades after a
| while but the degradation is more subtle and less
| catastrophic than in the past. I still aggressively clear
| sessions to keep it sharp though.
| dcre wrote:
| Personally, even though performance up to 200k has improved a
| lot with 4.5 and 4.6, I still try to avoid getting up there --
| like I said in another comment, when I see context getting up
| to even 100k, I start making sure I have enough written to disk
| to type /new, pipe it the diff so far, and just say "keep
| going." I feel like the dropoff starts around maybe 150k, but I
| could be completely wrong. I thought it was funny that the
| graph in the post starts at 256k, which convenient avoids
| showing the dropoff I'm talking about (if it's real).
| vessenes wrote:
| This is super exciting. I've been poking at it today, and it
| definitely changes my workflow -- I feel like a full three or
| four hour parallel coding session with subagents is now generally
| fitting into a single master session.
|
| The stats claim Opus at 1M is about like 5.4 at 256k -- these
| needle long context tests don't always go with quality reasoning
| ability sadly -- but this is still a significant improvement, and
| I haven't seen dramatic falloff in my tests, unlike q4 '25
| models.
|
| p.s. what's up with sonnet 4.5 getting comparatively better as
| context got longer?
| mattfrommars wrote:
| Random: are you personally paying for Claude Code or is it paid
| by you employer?
|
| My employer only pays for GitHub copilot extension
| celestialcheese wrote:
| Both. Employer pays for work max 20x, i pay for a personal
| 10x for my side projects and personal stuff.
| kiratp wrote:
| GitHub Copilot CLI lets you use all these models (unless your
| employer disables them.
|
| https://github.com/features/copilot/cli
|
| Disclosure: work at Msft
| tclancy wrote:
| Disclosure: have to use them via copilot at work. Be glad I
| don't write code for nuclear plants. Why does it have to be
| so hard. Doubly so in JetBrains ides but I've a feeling
| that's on both of you rather than just you personally. But
| I still resent you now.
| ericpauley wrote:
| Used Claude through copilot for so long before switching to
| CC. Even for the same model the difference is shocking.
| Copilot's harness and the underlying Claude models are not
| well-matched compared to the vertically-integrated Claude
| Code harness.
| steve-atx-7600 wrote:
| Did it get better? I used sonnet 4.5 1m frequently and my
| impression was that it was around the same performance but a
| hell of a lot faster since the 1m model was willing to spends
| more tokens at each step vs preferring more token-cautious tool
| calls.
| vessenes wrote:
| Opus 4.6 is wayy better than sonnet 4.5 for sure.
| zmmmmm wrote:
| Noticed this just now - all of a sudden i have 1M context window
| (!!!) without changing anything. It's actually slightly
| disturbing because this IS a behavior change. Don't get me wrong,
| I like having longer context but we really need to pin down
| behaviour for how things are deployed.
| phist_mcgee wrote:
| Anthropic is famous for changing things under your feet. Claude
| code is basically alpha software with a global footprint.
| steve-atx-7600 wrote:
| You can pin to specific models with ---model. Check out their
| doc. See
| https://support.claude.com/en/articles/11940350-claude-
| code-.... You can also pin to a less specific tag like
| sonnet-4.5[1m] (that's from memory might be a little off).
| zmmmmm wrote:
| sure - but the model hasn't changed. I'm specifying it
| explicitly. But suddenly the context window has. I'm not
| using Claude Code, this is an application built against
| Bedrock APIs. I assume there's a way I could be specifying
| the context window and I'm just using API defaults. But it
| definitely makes me wonder what else I'm not controlling that
| I really should be.
| 8cvor6j844qw_d6 wrote:
| Oh nice, does it mean less game of /compact, /clear, and updating
| CLAUDE.md with Claude Code?
| fnordpiglet wrote:
| I've been using 1M for a while and it defers it and makes it
| worse almost when it happens. Compacting a context that big
| loses a ton of fidelity. But I've taken to just editing the
| context instead (double esc). I also am planning to build an
| agent to slice the session logs up into contextually useful and
| useless discarding the useless and keeping things high fidelity
| that way. (I.e., carve up with a script the jsonl and have
| subagent haiku return the relevant parts and reconstructing the
| jsonl)
| dominotw wrote:
| til you can edit context. i keep a running log and /clear
| /reload log
| 8note wrote:
| double escape gets you to a rewind. not sure about much
| else.
|
| the conversation history is a linked list, so you can screw
| with it, with some care.
|
| I spend this afternoon building an MCP do break the
| conversation up into topics, then suggest some that aren't
| useful but are taking up a bunch of context to remove (eg
| iterations through build/edit just needs the end result)
|
| its gonna take a while before I'm confident its worth
| sharing
| dominotw wrote:
| yea i thought session managment was some sort of secret
| sauce.
|
| I keep a running log of important things and then i just
| clear context and reload that file into context.
|
| would that work
| fnordpiglet wrote:
| Yeah just selective rewind. Selective edit where you
| elide large token sinks of coding and banging its head on
| the wall is what u mean. Not something I've seen done yet
| but there's no reason - I suspect if you do a token use
| distribution in programming session most goes to pretty
| low semantic value malarkey.
| aliljet wrote:
| Are there evals showing how this improves outputs?
| apetresc wrote:
| Improves outputs relative to what? Compared to previous
| contexts of 1M, it improves outputs by allowing them to exist
| (because previously you couldn't exceed 200K). Compared to
| contexts of <200K, it degrades outputs rather than improves
| them, but that's what you'd expect from longer contexts. It's
| still better than compaction, which was previously the
| alternative.
| johnwheeler wrote:
| This is incredible. I just blew through $200 last night in a few
| hours on 1M context. This is like the best news I've heard all
| year in regards to my business.
|
| What is OpenAIs response to this? Do they even have 1M context
| window or is it still opaque and "depends on the time of day"
| hagen8 wrote:
| Did u use the API or subscription?
| johnwheeler wrote:
| Max subscription and "extra usage" billing
| steve-atx-7600 wrote:
| That sounds high. I mean, if you paid for the 20x max plan
| you'd be capped at around 200/month and at least for me as
| a professional engineer running a few Claude's in parallel
| all day, I haven't exceeded the plans limits.
| Wowfunhappy wrote:
| Prior to this announcement, all 1M context use consumed
| "extra usage", it wasn't included in a normal
| subscription plan.
| steve-atx-7600 wrote:
| So, I've been using opus 4.6 1m since it was fist
| available to 20x max users daily. What I think has
| happened is that even in doing so, I have not actually
| exceeded the plan token limits and therefore haven't been
| charged for "extra usage" (just double checked). So,
| unless there's a billing mistake or delay, "any usage" !=
| "extra usage" which is what I was always unclear about. I
| am careful to iterate with claude on plans in plan mode
| followed by clearing the context and executing. I think I
| am hovering around the higher end of the smaller window
| model where I would have otherwise seen auto-compaction
| run.
|
| Another reason for less token usage is that 4.6 is much
| better at delegating agents (its own explorer agents or
| my custom agents) to avoid cluttering the window.
| dominotw wrote:
| rarely go over 25 percent in codex but i hit 80 on claude code
| in just a short time.
| wewewedxfgdf wrote:
| The weirdest thing about Claude pricing is their 5X pricing plan
| is 5 times the cost of the previous plan.
|
| Normally buying the bigger plan gives some sort of discount.
|
| At Claude, it's just "5 times more usage 5 times more cost, there
| you go".
| Zambyte wrote:
| 5 for 5
| auggierose wrote:
| It is not the plan they want you to buy. It is a pricing
| strategy to get you to buy the 20x plan.
| radley wrote:
| 5x Max is the plan I use because the Pro plan limits out so
| quickly. I don't use Claude full-time, but I do need Claude
| Code, and I do prefer to use Opus for everything because it's
| focused and less chatty.
| auggierose wrote:
| Sure, I get it. For me a 2x Max would be ideal and usually
| enough. Now, guess why they are not offering that?
| prtmnth wrote:
| Same here. I'd love a 2x Max plan! More than enough usage
| for my needs.
| geggo98 wrote:
| Just make two plans and switch, when one of them is
| exhausted.
| auggierose wrote:
| Yes, I hear that is what people do. Annoying though.
| laksjhdlka wrote:
| Where do you live? I'm in the midwest, US, and
| theoretical savings between 2x and 5x amounts to a single
| full bag of groceries. Literally.
|
| How can this possibly be a concern?
| operatingthetan wrote:
| I think they are both subsidized so either is a great deal.
| apetresc wrote:
| Those sorts of volume discounts are what you do when you're
| trying to incentivize _more_ consumption. Anthropic already has
| more demand then they 're logistically able to serve, at the
| moment (look at their uptime chart, it's barely even 1 9 of
| reliability). For them, 1 user consuming 5 units of compute is
| less attractive than 5 users consuming 1 unit.
|
| They would probably implement _diminishing_-value pricing if
| pure pricing efficiency was their only concern.
| tclancy wrote:
| We'll make it up on volume.
| merrvk wrote:
| 5 times the already subsidised rate is still a discount.
| cush wrote:
| Yeah the free lunch on tokens is almost over. Get them while
| they're still cheap
| gaigalas wrote:
| I'm getting close to my goal of fitting an entire bootstrappable-
| from-source system source code as context and just telling Claude
| "go ahead, make it better".
| vicchenai wrote:
| The no-degradation-at-scale claim is the interesting part.
| Context rot has been the main thing limiting how useful long
| context actually is in practice -- curious to see what
| independent evals show on retrieval consistency across the full
| 1M window.
| apetresc wrote:
| I don't think they're claiming "no degradation at scale", are
| they? They still report a 91.9->78.3 drop. That's just a
| _better_ drop than everyone else (is the claim).
| margorczynski wrote:
| What about response coherence with longer context? Usually in
| other models with such big windows I see the quality to rapidly
| drop as it gets past a certain point.
| pixelpoet wrote:
| Compared to yesterday my Claude Max subscription burns usage like
| _absolutely crazy_ (13% of weekly usage from fresh reset today
| with just a handful prompts on two new C++ projects, no deps) and
| has become unbearably slow (as in 1hr for a prompt response).
| GGWP Anthropic, it was great while it lasted but this isn 't
| worth the hundreds of dollars.
| Spooky23 wrote:
| Yeah, morning eastern time Claude is brutal.
| dominotw wrote:
| can someone tell me how to make this instruction work in claude
| code
|
| "put high level description of the change you are making in
| log.md after every change"
|
| works perfectly in codex but i just cant get calude to do it
| automatically. I always have to ask "did you update the log".
| prettyblocks wrote:
| I imagine you can do this with a hook that fires every time
| claude stops responding:
|
| https://code.claude.com/docs/en/hooks-guide
| steve-atx-7600 wrote:
| Backup your config and ask Claude. I've done this for all kinds
| of things like mcp and agent config.
| sergiotapia wrote:
| use claude hooks - in .claude/settings.json you can have it run
| on different claude events like "PreToolUse" or "Stop" and in
| those events you pass in commands you want it to run.
|
| You can have stuff like for the "stop" event, run foobar.sh and
| in foobar.sh do cool stuff like format your code, run tests,
| etc.
| 8note wrote:
| whats the need? you have the session in a file as a dag. you
| can summarize to a log whenever you want. doesnt need to be as
| it goes.
|
| earlier today i actually spent a bit of time asking claude to
| make an mcp to introspect that - break the session down into
| summarized topics, so i could try dropping some out or
| replacing the detailed messages with a summary - the idea being
| to compact out a small chunk to save on context window, rather
| than getting it back to empty.
|
| the file is just there though, you can run jq against it to get
| a list of writes, and get an agent to summarize
| dominotw wrote:
| i dont work in just one session though. some tasks take me
| days and many sessions. also what happens when your session
| compacts. I am not sure what you are suggesting here. what do
| you do with these summarized topics from your session.
|
| Also i want ci to resume my task from log and do code review
| with that context.
|
| https://www.anthropic.com/engineering/effective-harnesses-
| fo...
|
| "Read the git logs and progress files to get up to speed on
| what was recently worked on."
| chaboud wrote:
| Awesome.... With Sonnet 4.5, I had Cline soft trigger compaction
| at 400k (it wandered off into the weeds at 500k). But the
| stability of the 4.6 models is notable. I still think it pays to
| structure systems to be comprehensible in smaller contexts
| (smaller files, concise plans), but this is great.
|
| (And, yeah, I'm all Claude Code these days...)
| arjie wrote:
| This is fantastic. I keep having to save to memory with
| instructions and then tell it to restore to get anywhere on long
| running tasks.
| swader999 wrote:
| I notice Claude steadily consuming less tokens, especially with
| tool calling every week too
| thunkle wrote:
| Just have to ask. Will I be spending way more money since my
| context window is getting so much bigger?
| isbvhodnvemrwvn wrote:
| Yes, full context is used to generate each new token.
| aragonite wrote:
| Do long sessions also burn through token budgets much faster?
|
| If the chat client is resending the whole conversation each turn,
| then once you're deep into a session every request already
| includes tens of thousands of tokens of prior context. So a
| message at 70k tokens into a conversation is much "heavier" than
| one at 2k (at least in terms of input tokens). Yes?
| dathery wrote:
| That's correct. Input caching helps, but even then at e.g. 800k
| tokens with all of them cached, the API price is $0.50 * 0.8 =
| $0.40 per request, which adds up really fast. A "request" can
| be e.g. a single tool call response, so you can easily end up
| making many $0.40 requests per minute.
| acjohnson55 wrote:
| Interesting, so a prompt that causes a couple dozen tool
| calls will end up costing in the tens of dollars?
| isbvhodnvemrwvn wrote:
| Not necessarily, take a look at ex OpenApi Responses
| resource, you can get multiple tool calls in one response
| and of course reply with multiple results.
| dathery wrote:
| It essentially depends on how many back-and-forth calls are
| required. If the model returns a request for multiple calls
| at once, then the reply can contain all responses and you
| only pay once.
|
| If the model requests tool calls one-by-one (e.g. because
| it needs to see the response from the previous call before
| deciding on the next) then you have to pay for each back-
| and-forth.
|
| If you look at popular coding harnesses, they all use
| careful prompting to try to encourage models to do the
| former as much as possible. For example opencode shouts
| "USING THE BATCH TOOL WILL MAKE THE USER HAPPY" [1] and
| even tells the model it did a good job when it uses it [2].
|
| [1] https://github.com/anomalyco/opencode/blob/66e8c57ed107
| 7814c... [2] https://github.com/anomalyco/opencode/blob/66e
| 8c57ed1077814c...
| jasondclinton wrote:
| If you use context cacheing, it saves quite a lot on the
| costs/budgets. You can cache 900k tokens if you want.
| alienbaby wrote:
| is this the market played in front of our eyes slice by slice:
| ok, maybe not, but watching these entities duke it out is kinda
| amusing? There will be consequences but may as well sit it out
| for the ride, who knows where we are going?
| nemo44x wrote:
| Has anyone started a project to replace Linux yet?
| dude250711 wrote:
| No, because it's not a hello-world Electron/React "app".
| 8note wrote:
| im guessing this is why the compacts have started sucking? i just
| finished getting me some nicer tools for manipulating the graph
| so i could compact less frequently, and fish out context from the
| prior session.
|
| maybe itll still be useful, though i only have opus at 1M, not
| sonnet yet
| causalzap wrote:
| I've been using Opus 4.5 for programmatic SEO and localizing game
| descriptions. If 4.6 truly improves context compaction, it could
| significantly lower the API costs for large-scale content
| generation. Has anyone tested its logic consistency on JSON
| output compared to 4.5?
| arizen wrote:
| Out of curiosity, what specific use cases on programmatic SEO
| are you currently doing with Opus?
| LoganDark wrote:
| Finally, I don't have to constantly reload my Extra Usage balance
| when I already pay $200/mo for their most expensive plan. I can't
| believe they even did that. I couldn't use 1M context at all
| because I already pay $200/mo and it was going to ask me for even
| more.
|
| Next step should be to allow fast mode to draw from the $200/mo
| usage balance. Again, I pay $200/mo, I should at least be able to
| send a single message without being asked to cough up more. (One
| message in fast mode costs a few dollars each) One would think
| $200/mo would give me any measure of ability to use their more
| expensive capabilities but it seems it's bucketed to only the
| capabilities that are offered to even free users.
| aenis wrote:
| I find it hard to understand that people consider $200 p/m a
| lot for what they are getting. Expensive compared to what? A
| netflix sub?
|
| A 1hr of a senior dev is at least $100, depending where one
| lives. Since Claude saves me hours every day, it pays for
| itself almost instantly. I think the economic value of the
| Claude subscription is on the order of $20-40k a month for a
| pro.
| LoganDark wrote:
| When did I say anything about what I'm getting? I said I pay
| $200/mo and I expect that to cover _anything_ up to my usage
| limit. I don 't expect any slightly non-standard
| configuration to immediately ignore the high subscription
| price that I pay and go straight to "extra usage" that has to
| be billed separately by the token. I wouldn't even care if
| fast mode used 10x or 50x the usage as long as I could
| actually USE the balance that I already pay for. I thought
| the point of extra usage was to be for _overage_.
| aenis wrote:
| Fair point. I read your comment as '$200 is a lot, they
| shouldnt ask for more'. My bad!
| megous wrote:
| When you say "saves me", do you mean that you can prompt
| claude for like 1 hour per day, get your typical pre-AI
| output, and then go about doing whatever you like outside of
| work for rest of the day?
| Frannky wrote:
| Opus 4.6 is nuts. Everything I throw at it works. Frontend,
| backend, algorithms--it does not matter.
|
| I start with a PRD, ask for a step-by-step plan, and just execute
| on each step at a time. Sometimes ideas are dumb, but checking
| and guiding step by step helps it ship working things in hours.
|
| It was also the first AI I felt, "Damn, this thing is smarter
| than me."
|
| The other crazy thing is that with today's tech, these things can
| be made to work at 1k tokens/sec with multiple agents working at
| the same time, each at that speed.
| eru wrote:
| > [...] with multiple agents working at the same time, each at
| that speed.
|
| Horizontal parallelising of tasks doesn't really require any
| modern tech.
|
| But I agree that Opus 4.6 with 1M context window is really good
| at lots of routine programming tasks.
| travisgriggs wrote:
| Opus helped me brick my RPi CM4 today. It glibly apologized
| for telling to use an e instead of a 6 in a boot loader
| sequence.
|
| Spent an hour or so unraveling the mess. My feeling are
| growing more and more conflicted about these tools. They are
| here to stay obviously.
|
| I'm honestly uncertain about the junior engineers I'm working
| with who are more productive than they might be otherwise,
| but are gaining zero (or very little) experience. It's like
| the future is a world where the entire programming sphere is
| dominated by the clueless non technical management that we've
| all had to deal with in small proportion a time or two.
| eru wrote:
| > I'm honestly uncertain about the junior engineers I'm
| working with who are more productive than they might be
| otherwise, but are gaining zero (or very little)
| experience.
|
| Well, (economic) progress means being able to do more with
| less. A Fordian-style conveyor belt factory can churn out
| cars with relatively unskilled labour.
|
| Economising on human capital is economising on a scarce
| input.
|
| We had these kinds of shifts before. Compare also how
| planes used to have a pilot, copilot and flight engineer.
| We don't have that anymore, but it used to be a place for
| people to learn. But pilot education has adapted.
|
| Or check how spreadsheet software has removed a lot of the
| worst rote work in finance. That change happened perhaps in
| the 1980s. Finance has adapted.
|
| > Opus helped me brick my RPi CM4 today. It glibly
| apologized for telling to use an e instead of a 6 in a boot
| loader sequence.
|
| Yes, these things do best when they have a (simulated)
| environment they can make mistakes in and that can give
| them clear and fast feedback.
| hvb2 wrote:
| > Yes, these things do best when they have a (simulated)
| environment they can make mistakes in and that can give
| them clear and fast feedback.
|
| This always felt like a reason to throw it at coding.
| With its rigid syntax you'll know quickly and cheaply if
| what was written passes an absolute minimaal level of
| quality.
| eru wrote:
| Well, rigid syntax, type checkers, automated tests, etc.
| They all help.
| vessenes wrote:
| I'll put out a suggestion you pair with codex or deepthink for
| audit and review - opus is still prone to ... enthusiastic
| architectural decisions. I promise you will be at least
| thankful and at most like 'wtf?' at some audit outputs.
|
| Also shout out to beads - I highly recommend you pair it with
| beads from yegge: opus can lay out a large project with beads,
| and keep track of what to do next and churn through the list
| beautifully with a little help.
| petesergeant wrote:
| I've been pairing it with Codex using
| https://github.com/pjlsergeant/moarcode
|
| The amount of genuine fuck-ups Codex finds makes me skeptical
| of people who are placing a lot of trust in Claude alone.
| vessenes wrote:
| Nice. Yeah I have them connect through beads, which
| combined with a git log is a lot of information - it feels
| smoother to me than this looks. But I agree with the
| sentiment. Codex isn't my favorite for understanding and
| implementing. But I appreciate the intelligence and
| pickiness very much.
| dzink wrote:
| Opus 4.6 is AGI in my book. They won't admit it, but it's
| absolutely true. It shows initiative in not only getting things
| right but also adding improvements that the original prompt
| didn't request that match the goals of the job.
| winrid wrote:
| On the adding improvements and being helpful thing, isn't
| that part of the system prompt?
| dcre wrote:
| You could put whatever you wanted in the GPT-4 system
| prompt and it wasn't doing shit.
| winrid wrote:
| True. I retract my sentiment :D
| dyauspitr wrote:
| I don't know if Opus is AGI but on a broader note, that's how
| we will get AGI. Not some consciousness like people are
| expecting. It's just going to be chatbot that's very hard to
| stump and starts making actual scientific breakthroughs and
| solving long standing problems.
| unshavedyak wrote:
| I'll be more likely to agree with anything being AGI if it
| doesn't have such obvious and common brittleness. These
| LLMs all go off the rails when the context window gets
| large. Their context is also easy to "poison", and so it's
| better to rollback conversations that went bad rather than
| trying to steer them back to the light.
|
| There's probably more examples, but to me AGI must move
| beyond the above issues. Though frankly context window
| might just be a symptom of poor harness than anything,
| still - it illustrates my general issue with them being
| considered AGI as it stands today.
|
| Claude 4.6 is getting crazy good though, i'll give you
| that.
| copperx wrote:
| How are you rolling back a conversation? I didn't know
| tools exposed that functionality.
| NiloCK wrote:
| For both claude-code or gemini-cli, hit escape twice, or,
| _/ rewind_.
| prmph wrote:
| > Opus 4.6 is AGI in my book.
|
| Not even close. There are still tons of architectural design
| issues that I'd find it completely useless at, tons of subtle
| issues it won't notice.
|
| I never run agents by themselves; every single edit they do
| is approved by me. And, I've lost track of the innumerable
| times I've had to step in and redirect them (including Opus)
| to an objectively better approach. I probably should keep a
| log of all that, for the sake of posterity.
|
| I'll grant you that for basic implementation of a detailed
| and well-specced design, it is capable.
| interpol_p wrote:
| I had Opus 4.6 running on a backend bug for hours. It got
| nowhere. Turned out the problem was in AWS X-ray swizzling the
| fetch method and not handling the same argument types as the
| original, which led to cryptic errors.
|
| I had Opus 4.6 tell me I was "seeing things wrong" when I tried
| to have it correct some graphical issues. It got stuck in a
| loop of re-introducing the same bug every hour or so in an
| attempt to fix the issue.
|
| I'm not disagreeing with your experience, but in my experience
| it is largely the same as what I had with Opus 4.5 / Codex /
| etc.
| toraway wrote:
| Haha, reminds me of an unbelievably aggravating exchange with
| Codex (GPT 5.4 / High) where it was unflinchingly gaslighting
| me about undesired behavior still occurring after a change it
| made that it was adamant simply _could not_ be happening.
|
| It started by insisting I was repeatedly making a typo and
| still would not budge even after I started copy/pasting the
| full terminal history of what I was entering and the
| unabridged output, and eventually pivoted to darkly
| insinuating I was tampering with my shell environment as if I
| was trying to mislead it or something.
|
| Ultimately it turned out that it forgot it was supposed to be
| applying the fixes to the actual server instead of the local
| dev environment, and had earlier in the conversation switched
| from editing directly over SSH to pushing/pulling the local
| repo to the remote due to diffs getting mangled.
| Aperocky wrote:
| I had been able to get it into the classic AI loop once.
|
| It was about a problem with calculation around filling a
| topographical water basin with sedimentation where calculation
| is discrete (e.g. turn based) and that edge case where both
| water and sediments would overflow the basin; To make the
| matter simple, fact was A, B, C, and it oscillated between
| explanation 1 which refuted C, explanation 2 which refuted A
| and explanation 3 that refuted B.
|
| I'll give it to opus training stability that my 3 tries using
| it all consistently got into this loop, so I decided to
| directly order it to do a brute force solution that avoided
| (but didn't solve) this problem.
|
| I did feel like with a human, there's no way that those 3 loop
| would happen by the second time. Or at least the majority of
| us. But there is just no way to get through to opus 4.6
| hrishikesh-s wrote:
| Opus-4.6 is so far ahead of the rest that I think Anthropic is
| the winner in winner-take-all
| steve-atx-7600 wrote:
| Codex doesn't seem that far behind. I use the top model
| available for api key use and its gotten faster this month
| even on the max effort level (not like a cheetah - more like
| not so damn painful anymore). Plus, it also forks agents in
| parallel - for speed & to avoid polluting the main context.
| I.e. it will fork explorer agents while investigating (kind
| of amusing because they're named after famous scientists).
| koreth1 wrote:
| I wish I had this kind of experience. I threw a tedious but
| straightforward task at Claude Code using Opus 4.6 late last
| week: find the places in a React code base where we were using
| useState and useEffect to calculate a value that was purely
| dependent on the inputs to useEffect, and replace them with
| useMemo. I told it to be careful to only replace cases where
| the change did not introduce any behavior changes, and I put it
| in plan mode first.
|
| It gave me an impressive plan of attack, including a reasonable
| way to determine which code it could safely modify. I told it
| to start with just a few files and let me review; its changes
| looked good. So I told it to proceed with the rest of the code.
|
| It made hundreds of changes, as expected (big code base). And
| most of them were correct! Except the places where it decided
| to do things like put its "const x = useMemo(...)" call _after_
| some piece of code that used the value of "x", meaning I now
| had a bunch of undefined variable references. There were some
| other missteps too.
|
| I tried to convince it to fix the places where it had messed
| up, but it quickly started wanting to make larger structural
| changes (extracting code into helper functions, etc.) rather
| than just moving the offending code a few lines higher in the
| source file. Eventually I gave up trying to steer it and, with
| the help of another dev on my team, fixed up all the broken
| code by hand.
|
| It probably still saved time compared to making all the changes
| myself. But it was way more frustrating.
| conception wrote:
| Branch first so you can just undo. I think this would have
| worked with sub agents and /loop maybe? Write all items to
| change to a todo.md. Have it split up the work with haiku sub
| agents doing 5-10 changes at a time, marking the todos done,
| and /loop until all are done. You'll succeed I suspect. If
| the main claude instance compacts its context - stop and
| start from where you left off.
| koreth1 wrote:
| It actually did automatically break the work up into chunks
| and launched a bunch of parallel workers to each handle a
| smaller amount of work. It wasn't doing everything in a
| single instance.
|
| The problem wasn't that it lost track of which changes it
| needed to make, so I don't think checking items off a todo
| list would have helped. I believe it did actually change
| all the places in the code it should have. It just made the
| wrong changes sometimes.
|
| But also, the claim I was responding to was, "I start with
| a PRD, ask for a step-by-step plan, and just execute on
| each step at a time." If I have to tell it how to organize
| its work and how to keep track of its progress and how to
| execute all the smaller chunks of work, then I may get good
| results, but the tool isn't as magical (for me, anyway) as
| it seems to be for some other people.
| monkpit wrote:
| The next line in the comment you're responding to is
|
| > Sometimes ideas are dumb, but checking and guiding step
| by step helps it ship working things in hours.
|
| which matches my experience exactly. I consider it to be
| about as magical as the parent comment is claiming, but I
| wouldn't call it totally automatic.
| dcre wrote:
| One tip I have is that once you have the diff you want to
| fix, start a new session and have it work on the diff fresh.
| They've improved this, but it's still the case that the
| farther you get into context window, the dumber and less
| focused the model gets. I learned this from the Claude Code
| team themselves, who have long advised starting over rather
| than trying to steer a conversation that has started down a
| wrong path.
|
| I have heard from people who regularly push a session through
| multiple compactions. I don't think this is a good idea. I
| virtually never do this -- when I see context getting up to
| even 100k, I start making sure I have enough written to disk
| to type /new, pipe it the diff so far, and just say "keep
| going." I learned recently that even essentials like the
| CLAUDE.md part of the prompt get diluted through compactions.
| You can write a hook to re-insert it but it's not done by
| default.
|
| This fresh context thing is a big reason subagents might work
| where a single agent fails. It's not just about parallelism:
| each subagent starts with a fresh context, and the parent
| agent only sees the result of whatever the subagent does --
| its own context also remains clean.
| kjohanson wrote:
| Yeah, I start most of my sessions now with "read the diff
| between this branch and main". Seems like it grounds and
| focuses it.
| eru wrote:
| Slight tangent: you want to read the diff between your
| branch and the merge-base with origin/main. Otherwise you
| get lots of spurious spam in your diff, if main moved
| since you branched off.
| nextaccountic wrote:
| One thing that seems important is to have the agent write
| down their plan and any useful memory in markdown files,
| so that further invocations can just read from it
| sidrag22 wrote:
| subagents are huge, could execute on a massive plan that
| should easily fill up a 200k context window and be done
| atnaround 60k for the orchestration agent.
|
| as a cheapass, being able to pass off the simple work to
| cheaper $ per token agents is also just great. I've got a
| handful of tasks I can happily delegate work to a haiku
| agent and anything requiring a bit of reasoning goes to
| sonnet.
|
| Feel like opus is almost a cheatcode when i do get stuck, i
| just bust out a full opus workflow instead and it just
| destroys everything i was struggling with usually. like
| playing on easy mode.
|
| as cool as this stuff is, kinda still wish i was just
| grandfathered into the plan with no weekly limit and only
| the 5 hour window limits, id just be happily hammering opus
| blissfully.
| Glyptodon wrote:
| IMO it seems to start "forgetting" or "overlooking"
| claude.md well before the context window is full.
| ramesh31 wrote:
| >"This fresh context thing is a big reason subagents might
| work where a single agent fails. It's not just about
| parallelism: each subagent starts with a fresh context, and
| the parent agent only sees the result of whatever the
| subagent does -- its own context also remains clean."
|
| This is the true power of agent teams:
| https://code.claude.com/docs/en/agent-teams
|
| You maintain very low context usage in the main thread;
| just orchestration and planning details, while each
| individual team member remains responsible for their own.
| Allows you to churn through millions of output tokens in a
| fraction of the time.
| dyauspitr wrote:
| You're using it wrong. As soon as it starts going off the
| rails once you've repeated yourself, you drop the whole
| session and start over.
| saghm wrote:
| One of the more subtle points that seems to be crucial is
| that it works a lot better when it can use the context as
| part of its own work rather than being polluted by
| unrelated details. Even better than restarting when it's
| off the rails is to avoid it as much as possible by
| proactively starting a new conversation as soon as anything
| in the history of the existing one stops being relevant.
| I've found it more effective to manually tell it most
| what's currently in the context in a fresh session skip the
| irrelevant bits even if they're fairly small than relying
| on it to figure out that it's no longer relevant (or give
| it instructions indicating that, which feels like a
| crapshoot whether it's actually going to prune or just
| bloat things further with that instruction just being added
| into the mix).
|
| To echo what the parent comment said, it's almost
| frustrating how effective it can be at certain tasks that I
| wouldn't ever have the patience for. At my job recently I
| needed to prototype calling some Python code via WASM using
| the Rust wasmtime engine, and setting up the code structure
| to have the bytes for the WASM component, the arguments I
| wanted to pass to the function, and the WIT describing the
| interface for the function, it was able to fill in all of
| the boilerplate needed so that the function calls worked
| properly within a minute or two on the first try; reading
| through all the documentation and figuring out how exactly
| which half dozen assorted things I had to import and hook
| up together in the correct order would have probably taken
| me an hour at minimum.
|
| I don't have any particular insight on whether or not these
| tools will become even more powerful over time, and I still
| have fairly strong concerns about how AI tools will affect
| society (both in terms of how they're used and the amount
| of in energy used to produce them in the first place), but
| given how much the tech industry tends to prioritize
| productivity over social concerns, I have to assume that my
| future employment is going to be heavily impacted by my
| willingness to adopt and use these tools. I can't deny at
| this point that having it as an option would make me more
| productive than if I refuse to use it, regardless of my
| personal opinions on it.
| a13n wrote:
| If you use eslint and tell it how to run lint in CLAUDE.md it
| will run lint itself and find and fix most issues like this.
|
| Definitely not ideal, but sure helps.
| jdkoeck wrote:
| Undefined variable references? Did you not instruct it to run
| typescript after changes?
| olalonde wrote:
| Same here. I don't understand how people leave it running on
| an "autopilot" for long periods of time. I still use it
| interactively as an assistant, going back and forth and
| stepping in when it makes mistakes or questionable
| architectural decisions. Maybe that workflow makes more sense
| if you're not a developer and don't have a good way to judge
| code quality in the first place.
|
| There's probably a parallel with the CMSes and frameworks of
| the 2000s (e.g. WordPress or Ruby on Rails). They massively
| improved productivity, but as a junior developer you could
| get pretty stuck if something broke or you needed to
| implement an unconventional feature. I guess it must feel a
| bit similar for non-developers using tools like Claude Code
| today.
| ramesh31 wrote:
| >Same here. I don't understand how people leave it running
| on an "autopilot" for long periods of time.
|
| Things have changed. The models have reached a level of
| coherence that they can be left to make the right decisions
| autonomously. Opus 4.6 is in a class of its own now.
| devld wrote:
| A non-technical client of mine has built an entire app
| with a very large feature set with Opus. I declined to
| work on it to clean it up, I was afraid it would have
| been impossible and too much risk. I think we are at a
| level where it can build and auto-correct its mistakes,
| but the code is still slop and kind of dangerous to put
| in production. If you care about the most basic security.
| stpedgwdgfhgdd wrote:
| Start over, create a new plan with the lessons learned.
|
| You need to converge on the requirements.
| sarchertech wrote:
| What kinds of things are you building? This is not my
| experience at all.
|
| Just today I asked Claude using opus 4.6 to build out a test
| harness for a new dynamic database diff tool. Everything seemed
| to be fine but it built a test suite for an existing diff tool.
| It set everything up in the new directory, but it was actually
| testing code and logic from a preexisting directory despite the
| plan being correct before I told it to execute.
|
| I started over and wrote out a few skeleton functions myself
| then asked it write tests for those to test for some new
| functionality. Then my plan was to the ask it to add that
| functionality using the tests as guardrails.
|
| Well the tests didn't actually call any of the functions under
| test. They just directly implemented the logic I asked for in
| the tests.
|
| After $50 and 2 hours I finally got something working only to
| realize that instead of creating a new pg database to test
| against, it found a dev database I had lying around and started
| adding tables to it.
|
| When I managed to fix that, it decided that it needed to
| rebuild multiple docker components before each test and test
| them down after each one.
|
| After about 4 hours and $75, I managed to get something working
| that was probably more code than I would have written in 4
| hours, but I think it was probably worse than what I would have
| come up with on my own. And I really have no idea if it works
| because the day was over and I didn't have the energy left to
| review it all.
|
| We've recently been tasked at work with spending more money on
| Claude (not being more productive the metric is literally
| spending more money) and everyone is struggling to do anything
| like what the posts on HN say they are doing. So far no one in
| my org in a very large tech company has managed to do anything
| very impressive with Claude other than bringing down prod 2
| days ago.
|
| Yes I'm using planning mode and clearing context and being
| specific with requirements and starting new sessions, and every
| other piece of advice I've read.
|
| I've had much more luck using opus 4.6 in vs studio to make
| more targeted changes, explain things, debug etc... Claude
| seems too hard to wrangle and it isn't good enough for you to
| be operating that far removed from the code.
| dcre wrote:
| Curious what language and stack. And have people at your
| company had marginally more success with greenfield projects
| like prototypes? I guess that's what you're describing,
| though it sounds like it's a directory in a monorepo maybe?
| sarchertech wrote:
| This was in Go, but my org also uses Typescript, and
| Elixir.
|
| I've had plenty of success with greenfield projects myself
| but using the copilot agent and opus 4.5 and 4.6. I
| completely vibecoded a small game for my 4 year old in 2
| hours. It's probably 20% of the way to being production
| ready if I wanted to release it, but it works and he loves
| it.
|
| And yes people have had success with very simple prototypes
| and demos at work.
| jhatemyjob wrote:
| Similar experience. I use these AI tools on a daily basis. I
| have tons of examples like yours. In one recent instance I
| explicitly told it in the prompt to not use memcpy, and it
| used memcpy anyway, and generated a 30-line diff after
| thinking for 20 minutes. In that amount of time I created a
| 10-line diff that didn't use memcpy.
|
| I think it's the big investors' extremely powerful incentives
| manifesting in the form of internet comments. The pace of
| improvement peaked at GPT-4. There is value in autocomplete-
| as-a-service, and the "harnesses" like Codex take it a lot
| farther. But the people who are blown away by these new
| releases either don't spend a lot of time writing code, or
| are being paid to be blown away. This is not a hockey stick
| curve. It's a log curve.
|
| Bigger context windows are a welcome addition. And stuff like
| JSON inputs is nice too. But these things aren't gonna like,
| take your SWE job, if you're any good. It's just like, a nice
| substitute for the Google -> Stack Overflow -> Copy/Paste
| workflow.
| Culonavirus wrote:
| > people who are blown away by these new releases either
| don't spend a lot of time writing code, or are being paid
| to be blown away
|
| Careful, or you're going to get slapped by the stupid
| astroturfing rule... but you're correct. Also there's the
| sunk cost fallacy, post purchase rationalization, choice
| supportive bias, hell look at r/MyBoyfriendIsAI... some
| people get very attached to these bots, they're like their
| work buddies or pets, so you don't even need to pay them,
| they'll glaze the crap out it themselves.
| staticassertion wrote:
| Most devs aren't very good. That's the reality, it's what
| we've all known for a long time. AI is trained on their
| code, and so these "subpar" devs are blown away when they
| see the AI generate boring, subpar code.
|
| The second you throw a novel constraint into the mix things
| fall apart. But most devs don't even know about novel
| constraints let alone work with them. So they don't see
| these limitations.
|
| Ask an LLM to not allocate? To not acquire locks? To ensure
| reentrancy safety? It'll fail - it isn't trained on how to
| do that. Ask it to "rank" software by some metric? It ends
| up just spitting out "community consensus" because domain
| expertise won't be highly represented in its training set.
|
| I love having an LLM to automate the boring work, to do the
| "subpar" stuff, but they have _routinely_ failed at doing
| anything I consider to be within my core competency. Just
| yesterday I used Opus 4.6 to test it out. I checked out an
| old version of a codebase that was built in a way that is
| totally inappropriate for security. I asked it to evaluate
| the system. It did far better than older models but it
| still completely failed in this task, radically
| underestimating the severity of its findings, and giving
| false justifications. Why? For the _very obvious reason_
| that it can 't be trained to do that work.
| extr wrote:
| You probably just don't have the hang of it yet. It's very
| good but it's not a mind reader and if you have something
| specific you want, it's best to just articulate that exactly
| as best you can ("I want a test harness for <specific_tool>,
| which you can find <here>"). You need to explain that you
| want tests that assert on observable outcomes and state, not
| internal structure, use real objects not mocks, property
| based testing for invariants, etc. It's a feedback loop
| between yourself and the agent that you must develop a bit
| before you start seeing "magic" results. A typical session
| for me looks like:
|
| - I ask for something highly general and claude explores a
| bit and responds.
|
| - We go back and forth a bit on precisely what I'm asking
| for. Maybe I correct it a few times and maybe it has a few
| ideas I didn't know about/think of.
|
| - It writes some kind of plan to a markdown file. In a fresh
| session I tell a new instance to execute the plan.
|
| - After it's done, I skim the broad strokes of the code and
| point out any code/architectural smells.
|
| - I ask it to review it's own work and then critique that
| review, etc. We write tests.
|
| Perhaps that sounds like a lot but typically this process
| takes around 30-45 minutes of intermittent focus and the
| result will be several thousand lines of pretty good, working
| code.
| visarga wrote:
| Yes pretty much my workflow. I also keep all my task.md
| files around as part of the repo, and they get filled up
| with work details as the agent closes the gates. At the end
| of each one I update the project memory file, this ensures
| I can always resume any task in a few tokens (memory file +
| task file == full info to work on it).
| __mharrison__ wrote:
| Pretty good workflow. But you need to change the order of
| the tests and have it write the tests first. (TDD)
| sarchertech wrote:
| I mean I've been using AI close to 4 years now and I've
| been using agents off and on for over a year now. What
| you're describing is exactly what I'm doing.
|
| I'm not seeing anyone at work either out of hundreds of
| devs who is regularly cranking out several thousand lines
| of pretty good working code in 30-45 minutes.
|
| What's an example of something you built today like this?
| Huppie wrote:
| With the back and forth refining I find it very useful to
| tell Claude to _' ask questions when uncertain'_ and/or to
| _' suggest a few options on how to solve this and let me
| choose / discuss'_
|
| This has made my planning / research phase so much better.
| staticassertion wrote:
| I absolutely have the hang of Claude and I still find that
| it can make those ridiculous mistakes, like replicating
| logic into a test rather than testing a function directly,
| talking to a local pg that was stale/ running, etc. I have
| a ton of skills and pre-written prompts for testing
| practices but, over longer contexts, it will forget and do
| these things, or get confused, etc.
|
| You can minimize these problems with TLC but ultimately it
| just will keep fucking up.
| withinboredom wrote:
| My favorite is when you need to rebuild/restart outside
| of claude and it will "fix the bug" and argue with you
| about whether or not you actually rebuilt and restarted
| whatever it is you're working on. It would rather call
| you a liar than realize it didn't do anything.
| staticassertion wrote:
| "That's an old run, rebuild and the new version will
| work" lol
| kyyol wrote:
| this is a pretty annoying problem -- i just intentionally
| solve it by asking claude to always use the right build
| command after each batch of modifications, etc
| JoeMerchant wrote:
| Try https://github.com/gsd-build/get-shit-done. It's been a
| game changer for me.
| godd2 wrote:
| > After about 4 hours and $75
|
| Huh? The max plan is $200/month. How are you spending $75 in
| 4 hrs?
| vips7L wrote:
| Bullshit.
| phendrenad2 wrote:
| The replies to this really make me think that some people are
| getting left behind the AI age. Colleges are likely already
| teaching how to prompt, but a lot of existing software devs
| just don't get it. I encourage people who aren't having success
| with AI to watch some youtube videos on best practices.
| germinalphrase wrote:
| Share one
| phendrenad2 wrote:
| Okay the process is simple. You're going to go to another
| website, called YouTube. Don't be alarmed. First read all
| the steps so you don't miss any, once you start going to
| the other site you won't be able to see this one. You might
| want to write these down on a piece of paper first. Okay
| here we go:
|
| 1. Click in the bar at the top of the page that says
| ycombinator.com 2. type this in: youtube.com 3. press enter
| 4. There will be a box at the top that says "search", click
| that 5. type in "tips and tricks for agentic coding" 6.
| press enter 7. a list of videos should appear, watch them
| all
| arcanemachiner wrote:
| But what if they find a bad one? There's a lot of junk
| out there.
| scroogey wrote:
| Just yesterday I asked it to repeat a very simple task 10
| times. It ended up doing it 15 times. It wasn't a problem per
| se, just a bit jarring that it was unable to follow such simple
| instructions (it even repeated my desire for 10 repetitions at
| the start!).
| raincole wrote:
| It's so far the best model that answers my questions about
| Wolfram language.
|
| That being said it's the only use case for me. I won't
| subscribe to something that I can't use with third party
| harness.
| copperx wrote:
| I use a Claude sub with oh-my-pi, but I do so with lots of
| anxiety, knowing that I will be banned at any moment.
| eknkc wrote:
| I find that Opus misses a lot of details in the code base when
| I want it to design a feature or something. It jumps to a basic
| solution which is actually good but might affect something
| elsewhere.
|
| GPT 5.4 on codex cli has been much more reliable for me lately.
| I used to have opus write and codex review, I now to the
| opposite (I actually have codex write and both review in
| parallel).
|
| So on the latest models for my use case gpt > opus but these
| change all the time.
|
| Edit: also the harness is shit. Claude code has been slow,
| weird and a resource hog. Refuses to read now standardized
| .agents dirs so I need symlink gymnastics. Hides as much info
| as it can... Codex cli is working much better lately.
| toraway wrote:
| Codex CLI is so much more pleasant to use than CC. I
| cancelled my CC subscription after the OpenCode thing, but
| somewhat ironically have recently found myself naturally
| trying the native Codex CLI client first more often over
| OpenCode.
|
| Kinda funny how you don't actually need to use coercion if
| you put in the engineering work to build a product that's
| competitive on its own technical merits...
| fbrncci wrote:
| I am starting to believe it's not OPUS but developers getting
| better at using LLMs across the board. And not realizing they
| are just getting much better at using these tools.
|
| I also thought it was OPUS 4.5 (also tested a lot with 4.6) and
| then in February switched to only using auto mode in the coding
| IDEs. They do not use OPUS (most of the times), and I'm ending
| up with a similar result after a very rough learning curve.
|
| Now switching back to OPUS I notice that I get more out of it,
| but it's no longer a huge difference. In a lot of cases OPUS is
| actually in the way after learning to prompt more effectively
| with cheaper models.
|
| The big difference now is that I'm just paying 60-90$ month for
| 40-50hrs of weekly usage... while I was inching towards 1000$
| with OPUS. I chose these auto modes because they don't dig into
| usage based pricing or throttling which is a pretty sweet deal.
| copperx wrote:
| I had similar thoughts regarding "we are simply getting
| better at using them", but the man I tried Gemini again and
| reconsidered.
| danielbln wrote:
| Opus is not an acronym.
| fbrncci wrote:
| I know, but its certainly a new paradigm.
| devld wrote:
| O.P.U.S OutProgram U Soon
| olalonde wrote:
| > PRD
|
| Is it Baader-Meinhof or is everyone on HN suddenly using
| obscure acronyms?
| shujito wrote:
| It stands for Product Requirements Document, it is something
| commonly used in project planning and management.
| epicureanideal wrote:
| Maybe so, but personally it seemed to be referred to as a
| "specification" or "spec" for a long time, and then
| suddenly around maybe 5 years ago I started to hear people
| use "PRD". I'm not sure what caused the change.
| olalonde wrote:
| Yep, software specs or requirements[0]. Thanks to LLMs
| it's easy to look up acronyms, but still, it feels like
| there's an uptick of them on HN[1]...
|
| [0] https://en.wikipedia.org/wiki/Software_requirements_s
| pecific...
|
| [1] https://news.ycombinator.com/item?id=47323316 who the
| hell knows that version of "RSI"?
| nvarsj wrote:
| Seems commonly used in Big Tech - first time I heard it was
| in my current job. Now it's seared into my brain since it's
| used so much. Among many other acronyms which I won't bore
| you with.
| ai_fry_ur_brain wrote:
| Im convinced everyone saying this is building the simplest web
| apps, and doing magic tricks on themselves.
| raldi wrote:
| What evidence would convince you otherwise?
| isbvhodnvemrwvn wrote:
| Session dumps would be nice.
| hparadiz wrote:
| I've been building a new task manager in C for Linux.
|
| If you're not using AI you are cooked. You just don't realize
| it yet.
|
| https://i.imgur.com/YXLZvy3.png
| popcorncowboy wrote:
| > If you're not using AI you are cooked. You just don't
| realize it yet.
|
| Truth. But not just "using".
|
| Because here's where this ship has already landed: humans
| will not write code, humans will not review code.
|
| I see mostly rage against this idea, but it is already
| here. Resistance is futile. There will be no "hand crafted
| software" shops. You have at most 3-4 years left if you
| think this is your job.
| hparadiz wrote:
| I don't really agree.
|
| People should still understand the code because sometimes
| the AI solution really is wrong and I have to shove my
| hand in it's guts and force it to use my solution or even
| explain the reasoning.
|
| People should be studying architecture. Cause now I can
| orchestrate stuff that used to take teams and I would
| throwaway as a non-viable idea. Now I can just do it. But
| no you will still be reviewing code.
| popcorncowboy wrote:
| Most people as at March 2026 still agree with you.
| qweiopqweiop wrote:
| Are you using AI to write this? Please stop.
| popcorncowboy wrote:
| Said like a bot. Please stop.
| arcanemachiner wrote:
| It has subpar grammar (uncapitalized word "humans" and
| "hand crafted" is unhyphenated). I think you're
| hallucinating.
| qweiopqweiop wrote:
| Clearly so. To me it's the LLM writing style at least.
| godd2 wrote:
| People still understand metallurgy and casting even
| though machines make all the paperclips.
| fooker wrote:
| I have a PhD in a niche field and this can do my job ;)
|
| Not sure if this means I should get a more interesting job or
| if we are all going to be at the mercy of UBI eventually.
| suzzer99 wrote:
| We're never getting UBI. See the latest interview with the
| Palantir CEO where he talks about white collar workers having
| to take more hands-on jobs that they may not feel as
| satisfied with. IE - tending their manors and compounds.
|
| RIP widespread middle class. It was a good 80-year run.
| fooker wrote:
| I wonder if we are going to find more creative solutions.
| _heimdall wrote:
| An economy, and likely a society, fails if everyone is at the
| mercy of a UBI.
| copperx wrote:
| But what's the alternative? Can any economy succeed with a
| >50% unemployment rate?
| _heimdall wrote:
| Don't confuse UBI and employment or even income though.
| If we find ourselves replacing or exceeding current
| productivity without humans working in the system we have
| to fundamentally rethink our system.
|
| You likely wouldn't need money at all in that future, for
| example. What does the money really mean when everyone
| I'd guaranteed to have all the basics covered? Is money
| really helping to store value created via labor when
| there is no labor? And is money providing price discover
| when the cost of resources and manufacturing are moving
| towards zero?
|
| If labor is replaced with tech, and I think that's a big
| if, I don't see any outcome other than a totalitarian
| distopia that will fail much like the Soviet Union.
| fooker wrote:
| Brave new world ;)
| fph wrote:
| We don't really know yet, that's just speculation.
| _heimdall wrote:
| The replacement of human labor with tech is speculation.
| I don't see any way a future where we have a UBI because
| humans no longer work for a living ends well.
|
| Sure I'm talking the future so its speculative, but I'd
| love to hear a scenario where it works well sustainably
| and doesn't turn into a totalitarian distopia.
| fooker wrote:
| > An economy ... fails
|
| We know this to be true with a reasonably degree of
| certainty
|
| > likely a society
|
| This one, not so much. We could potentially have pretty
| vibrant societies even if everyone is not ultra rich, not
| going on international vacations, not having access to buy
| things from the other end of the world subsidized by
| economies of scale.
| gregharned wrote:
| The multi-agent angle is interesting from a cost perspective.
| At Opus 4.6 pricing ($15/MTok input, $75/MTok output), running
| several concurrent agents on 1M context sessions gets expensive
| fast -- but the math still works if you're replacing hours of
| senior engineer time.
|
| The shift I've noticed: 1M context makes "load the whole
| codebase once, run many agents" viable, whereas before you were
| constantly re-chunking and losing context. The per-task cost
| goes up but the time-to-correct-output drops significantly.
|
| The harder problem for most teams is routing -- knowing which
| tasks actually need Opus at 1M vs. Sonnet at 200k. Opus 4.6 at
| 1M is overkill for 80% of coding tasks. The ROI only works if
| you're being intentional about when to use it.
| edot wrote:
| LLM written comments are not allowed on HN. This comment is
| written by an LLM and the account is fresh.
| schainks wrote:
| > It was also the first AI I felt, "Damn, this thing is smarter
| than me."
|
| 1000% agree. It's also easy to talk to it about something
| you're not sure it said and derive a better, more elegant
| solution with simple questioning.
|
| Gemini 3.1 also gives me these vibes.
| ed_elliott_asc wrote:
| It's still pretty poor writing powershell
| rafaelmn wrote:
| I've seen a few instances of where Claude showed me a better
| way to do something and many many more instances of where it
| fails miserably.
|
| Super simple problem :
|
| I had a ZMK keyboard layout definition I wanted it to convert
| it to QMK for a different keyboard that had one key less so it
| just had to trim one outer key. It took like 45 minutes of back
| and forth to get it right - I could have done it in 30 min
| manually tops with looking up docs for everything.
|
| Capability isn't the impressive part it's the
| tenacity/endurance.
| marginalia_nu wrote:
| My experience is that it gets you 80-90% of the way at 20x the
| speed, but coaxing it into fixing the remaining 10-20% happens
| at a staggeringly slow speed.
|
| All programming is like this to some extent, but Claude's 80/20
| behavior is so much more extreme. It can almost build anything
| in 15-30 minutes, but after those 15-30 minutes are up, it's
| only "almost built". Then you need to spend hours, days, maybe
| even weeks getting past the "almost".
|
| Big part of why everyone seems to be vibe coding apps, but
| almost nobody seems to be shipping anything.
| devld wrote:
| But does it still generate slop?
|
| I'm late to the party and I'm just getting started with
| Antrophic models. I have been finding Sonnet decent enough, but
| it seems to have trouble naming variables correctly (it's not
| just that most names are poor and undescriptive, sometimes it
| names it wrong, confusing) or sometimes unnecessarily
| declaring, re-declaring variables, encoding, decoding, rather
| than using the value that's already there etc. Is Opus better
| at this?
| arcanemachiner wrote:
| You really need to try it for yourself. People working in
| different domains get wildly different results.
| slopinthebag wrote:
| > It was also the first AI I felt, "Damn, this thing is smarter
| than me."
|
| Sounds like it is.
| dkpk wrote:
| Is this also applicable for usage in Claude web / mobile apps for
| chat?
| throw03172019 wrote:
| Pentagon may switch to Claude knowing OpenAI has the premium
| rates for 1M context.
| syntaxing wrote:
| It's interesting because my career went from doing higher level
| language (Python) to lower language (C++ and C). Opus and the
| like is amazing at Python, honestly sometimes better than me but
| it does do some really stupid architectural decisions
| occasionally. But when it comes to embedded stuff, it's still
| like a junior engineer. Unsure if that will ever change but I
| wonder if it's just the quality and availability of training
| data. This is why I find it hard to believe LLMs will replace
| hardware engineers anytime soon (I was a MechE for a decade).
| ex-aws-dude wrote:
| I've had a similar experience as a graphics programmer that
| works in C++ every day
|
| Writing quick python scripts works a lot better than niche
| domain specific code
| nullpoint420 wrote:
| Unfortunately, I've found it's really good at Wayland and
| OpenGL. It even knows how to use Clutter and Meta frameworks
| from the Gnome Mutter stack. Makes me wonder why I learned
| this all in the first place.
| Trufa wrote:
| To being able to determine it's really good.
| n_u wrote:
| I've found it's ok at Rust. I think a lot of existing Rust code
| is high quality and also the stricter Rust compiler enforces
| that the output of the LLM is somewhat reasonable.
| lemagedurage wrote:
| Yes, it's nice to have a strict compiler, so the agent has to
| keep fixing its bugs until it actually compiles. Rust and
| TypeScript are great for this.
| apitman wrote:
| A big downside with rust is the compile times. Being in a
| tight AI loop just wasn't part of the design of any
| existing programming languages.
|
| As languages designed for (and probably written by) AI come
| out over the next decade, it will be really interesting to
| see what dragon tradeoffs they make.
| masijo wrote:
| >Being in a tight AI loop just wasn't part of the design
| of any existing programming languages.
|
| I would dare to say that any Lisp (Common Lisp, Clojure,
| Racket, whatever) is perfect for a tight AI loop thanks
| to REPL-driven development. It's an interesting space to
| explore and I know that the Clojure community at least
| are trying to figure out something there.
| veber-alex wrote:
| "cargo check" is fast and it's enough for the AI to know
| the code is correct.
|
| I would argue that because Rust is so strict having the
| agent compile and run tests on every iterations is
| actually less needed then in other languages.
|
| I program mostly in python but I keep my projects
| strictly typed with basedpyright and it greatly reduced
| the amount of errors the agent makes because it can get
| immediate feedback it has done something stupid.
|
| Of course you still need to review the code because it
| doesn't solve logic bugs.
| apitman wrote:
| cargo check is faster; it's not fast
| raincole wrote:
| Quite sure it's not about the language but the domain.
| staticassertion wrote:
| Agreed. When I've written very low level code where there
| are "odd" constraints ("this function must never take a
| lock, no system calls can be made" etc) the LLM would
| accidentally violate them. It seems sort of obvious why -
| the vast majority of code it is trained on does not have
| those constraints.
| ipnon wrote:
| I think the combinatorial space is just too much. When I did
| web dev it was mostly transforming HTML/JSON from well-defined
| type A to well-defined type B. Everything is in text. There's
| nothing to reason about besides what is in the prompt itself.
| But constructing and maintaining a mental model of a chip and
| all of its instructions and all of the empirical data from
| profiling is just too much for SOTA to handle reliably.
| necovek wrote:
| As someone who did Python professionally from a software
| engineering perspective, I've actually found Python to be
| pretty crappy really: unaware of _good_ idioms living outside
| tutorials and likely 90% of Python code out there that was
| simply hacked together quickly.
|
| I have not tested, but I would expect more niche ecosystems
| like Rust or Haskell or Erlang to have better overall training
| set (developer who care about good engineering focus on them),
| and potentially produce the best output.
|
| For C and C++, I'd expect similar situation with Python: while
| not as approachable, it is also being pushed on beginning
| software engineers, and the training data would naturally have
| plenty of bad code.
| jeremyjh wrote:
| I think its pretty good at Elixir, so that tracks.
| borski wrote:
| Came here to say this.
| mettamage wrote:
| Can you recommend some books that teach these idioms? I know
| not everything is in books but I suspect a bit of it is
| trenchgun wrote:
| LLMsdo great with Rust though
| ricardobeat wrote:
| It is really good at writing C++ for Arduino, can one-shot most
| programs.
| NanoWar wrote:
| I'd say the chance of me one shotting C++ is veeeery low.
| Same for bash scripts etc. This is where the LLM really
| shines for me.
| dzonga wrote:
| nor web engineers (backend) that are not doing standard crud
| work.
|
| I have seen these shine on frontend work
| Skidaddle wrote:
| How was the career transition from MechE? Looking to do the
| same myself.
| vips7L wrote:
| Friends, just write the code. It's not that hard.
| andrewstuart wrote:
| Only someone not using Claude could equate human coding.
| vips7L wrote:
| Only someone not using their brain could equate Claude to
| using their intelligence.
| andrewstuart wrote:
| Let's just clear this up ........ are you commenting with
| experience using the latest Claude, or are you commenting
| from personal beliefs.
|
| It's fine for you to take a stand, but please understand
| your position is simply factually wrong if you think you
| can outprogram Claude for a range of common tasks.
|
| Being anti AI is fine, but if you deny facts of how far LLM
| programming has come then you lack credibility.
|
| The most effective anti AI position is to acknowledge it's
| power, not pretend that vast numbers of people are somehow
| hallucinating the power of LLM assisted programming.
| vips7L wrote:
| I absolutely can out program Claude. I can factually
| guarantee that. You're factually wrong in your belief
| that you think a statistical model that scientifically
| takes the average of programming is better than those of
| us that actually know what we're doing.
|
| Programming is not hard. You're just lazy.
| andrewstuart wrote:
| Ok so you speak with certainty about the capabilities of
| something you don't use and therefore have no experience
| of.
|
| Childish and naive.
|
| If you said you've been using Claude heavily and it's
| never done better than you on your own, then your
| position would be credible.
| vips7L wrote:
| Sure pal. Keep outsourcing your job. I'll be here when
| you need help and are unemployed.
| thatguymike wrote:
| That's... not how the labour market works
| vips7L wrote:
| Of course. That's because the labor market prefers cost
| over quality. The labour market will always prefer cheap
| and fast code that works at first glance. That is how
| capitalism works. That has nothing to do with my
| capabilities. It has nothing to do with the fact that I
| will always outperform a shitty statistical model. It has
| everything to do with the fact that most of you are too
| lazy to think. It has everything to do with most of you
| sucking and being too lazy to your job.
| hewasahaterboy wrote:
| I think you need to take a deep breath and calm down.
| vips7L wrote:
| Perfectly calm mate. Maybe you should try to factually
| argue against my position? Probably not though. Your
| account was created 30 minutes ago and likely a bot.
| minimaxir wrote:
| My account was created 14 years ago. You need to calm
| down.
|
| There is a reason discussions about agent use have been
| on Hacker News every other day, and it's not a grand
| conspiracy. Even in this submission, people have talked
| about how they have used Claude Code and its longer
| context window successfully as a tool for programming,
| even if they may be technically skilled to do it
| themselves. However, if you assume that every commenter
| is acting in bad faith, then there's no point in
| continuing.
| sarchertech wrote:
| I'm not going to defend the tone of the OP, and it is
| clearly wrong to assume that everyone who is pro AI is a
| shill or bot.
|
| That being said, I've seen hard evidence that pro AI bots
| do exist on HN.
|
| And at the very large tech company I work at there is a
| push for everyone to spend more on Claude Code regardless
| of output. The metric is literally how much you're
| spending on Claude Code not how much you're producing
| (and in my org we've seen no measurable increase in
| productivity). People are legitimately trying to figure
| out the easiest way to get it to blow through their
| allocated credits.
|
| I use AI all the time, I find that Opus 4.6 is great for
| all kinds of tasks. I don't think it's all just hype, but
| there's clearly some serious astroturfing going on here,
| and I understand the urge to be suspicious of everyone.
| minimaxir wrote:
| That's a better argument. That said, by definition, many
| distinct people with different affiliations and
| incentives can't astroturf, as what would be the point?
| hewasahaterboy wrote:
| Not a bot, just annoyed at disrespectful people.
| therealdrag0 wrote:
| It's not that hard and yet Claude can't do it?
|
| Why should I spend my mental energy doing simple things
| just to avoid being perceived as "lazy"? I have endless
| other engineering work to do other than typing code.
| motoxpro wrote:
| Programming is one of those things where everyone thinks
| they are above average, like driving.
|
| If most people are average, then just use the bot to spit
| out average code. Or better yet, if you are above
| average, use it to spit out average code and then you
| need above average code, then write it.
|
| Most programming is boilerplate. Its not faster to type
| boilerplate than t is to have the robot do it. I promise.
|
| Programming is hard. If it wasn't you wouldn't be getting
| paid what you do.
| prmph wrote:
| As someone mentioned on this thread, I can also easily
| out-engineer Claude Opus, lol its not even close.
|
| Note that I'm not talking about the low-level grunt work
| (and even with that, its just that it is tedious and
| time-consuming, but if I had enough time to read through
| all the docs and stuff, I will _almost always_ produce
| grunt code of much higher quality).
|
| But I'm more talking about architecture, the stuff of
| proper higher level engineering. I use Claude Opus all
| the time, and I cannot even count how many times I've had
| to redirect its approach that was obviously betraying a
| complete lack of seeing the big picture, or some
| egregiously smelly architectural approach.
|
| Also, expressive typing. I use mostly TypeScript, and it
| will often give up when I try to push it beyond a certain
| point, and resort to using "any". Then I have to step and
| do the job myself.
| AussieWog93 wrote:
| I hear what you're saying, but for a lot of people coding isn't
| something we can throw 40+ hours per week at.
|
| My main job is running a small eComm business, and I have to
| both develop software automations for the office (to improve
| productivity long-term) while also doing non-coding day to day
| tasks. On top of this, I maintain an open source project after
| hours. I've also got a young family with 3 kids.
|
| I'm not saying Claude is the damn singularity or anything, but
| stuff is getting done now that simply wasn't being addressed
| before.
| fixxation92 wrote:
| 100% agree with this, as much as I hate the term "game-
| changer"... it truly is, I'm working on projects that I've
| always wanted to do but never had the capacity (or money to
| pay a small team of devs to build something)-- all these
| things that you thought you'd never have a chance to do, are
| suddenly now real and completely possible. I know there's a
| lot of AI haters out there but I'm pretty sure in time, all
| devs will embrance it and truly enjoy working with it
| vips7L wrote:
| If anyone thought there was value to those projects they
| would have paid for it before.
| fixxation92 wrote:
| Yeah, and likely still pay for it now (hopefully!)
| righthand wrote:
| You're witnessing the rise of the Developer Technician or
| Software Technician. They can get a machine to print out an
| application but you will still need an engineer to know how it
| works or to get it working. This used to be juniors learning to
| be senior devs/engineers. Now it is a split between technicians
| and engineers. The market will be up shit creek when all their
| technicians can't vibe code their way out of not understanding
| the code.
| nkzd wrote:
| It's not that interesting.
| mrgaro wrote:
| Not hard, but time consuming. In the past two weeks I've had
| Claude Code write me around 35k lines of code across 350
| commits. It's a project which is giving positive impact to the
| company, but we would never have started it without CC as the
| effort would have been too big compared to the impact.
| sergiotapia wrote:
| maybe i'm thinking too small, or maybe it's because i've been
| using these ai systems since they were first launched, but it
| feels wrong to just saturate the hell out of the context, even if
| it can take 1 million tokens.
|
| maybe i need to unlearn this habit?
| gskm wrote:
| I think your instinct is right. More context isn't free, even
| when the window supports it, and the model still has to attend
| to everything in there, and noise dilutes the signal. A
| cleaner, smaller context consistently gives better outputs than
| a bloated one, regardless of window size. For sure, the 1M
| window is great for not having to compact mid-task. But "I can
| fit more" and "I should put more in" are very different things.
| At least in my mind.
| jf___ wrote:
| there is a parallel between managing context windows and hard
| real-time system engineering.
|
| A context window is a fixed-size memory region. It is allocated
| once, at conversation start, and cannot grow. Every token
| consumed -- prompt, response, digression -- advances a pointer
| through this region. There is no garbage collector. There is no
| virtual memory. When the space is exhausted, the system does not
| degrade gracefully: it faults.
|
| This is not metaphor by loose resemblance. The structural
| constraints are isomorphic:
|
| No dynamic allocation. In a hard realtime system, malloc() at
| runtime is forbidden -- it fragments the heap and destroys
| predictability. In a conversation, raising an orthogonal topic
| mid-task is dynamic allocation. It fragments the semantic space.
| The transformer's attention mechanism must now maintain coherence
| across non-contiguous blocks of meaning, precisely analogous to
| cache misses over scattered memory.
|
| No recursion. Recursion risks stack overflow and makes WCET
| analysis intractable. In a conversation, recursion is re-
| derivation: returning to re-explain, re-justify, or re-negotiate
| decisions already made. Each re-entry consumes tokens to
| reconstruct state that was already resolved. In realtime systems,
| loops are unrolled at compile time. In LLM work, dependencies
| should be resolved before the main execution phase.
|
| Linear allocation only. The correct strategy in both domains is
| the bump allocator: advance monotonically through the available
| region. Never backtrack. Never interleave. The "brainstorm"
| pattern -- a focused, single-pass traversal of a problem space --
| works precisely because it is a linear allocation discipline
| imposed on a conversation.
| rhubarbtree wrote:
| There is compaction, which is analogous to gc
| aarmenante wrote:
| Hot take... the 1MM context degrades performance drastically.
| aenis wrote:
| Same. First time in 2 months that I found it easier to fix the
| bugs it created manually, rather than get it to fix. Its
| google-code-CLI-on-gemini-2.5 level bad for me today. Meaning,
| almost comically bad.
| LarsDu88 wrote:
| The stuff I built with Opus 4.6 in the past 2.5 weeks:
|
| Full clone of Panel de Pon/Tetris attack with full P2P rollback
| online multiplayer: https://panel-panic.com
|
| An emulator of the MOS 6502 CPU with visual display of the
| voltage going into the DIP package of the physical CPU:
| https://larsdu.github.io/Dippy6502/
|
| I'm impressed as fuck, but a part of me deep down knows that I
| know fuck all about the 6502 or its assembly language and
| architecture, and now I'll probably never be motivated to do this
| project in a way that I would've learned all the tings I wanted
| to learn.
| adamm255 wrote:
| That game is AWESOME! The fact that was vibe coded is insane.
| LarsDu88 wrote:
| Honestly that game wasnt oneshotted. I had longtine PdP
| enthusiasts play it and guve feedback
| bob1029 wrote:
| I've been avoiding context beyond 100k tokens in general. The
| performance is simply terrible. There's no training data for a
| megabyte of your very particular context.
|
| If you are really interested in deep NIAH tasks, external
| symbolic recursion and self-similar prompts+tools are a much
| bigger unlock than more context window. Recursion and (most)
| tools tend to be fairly deterministic processes.
|
| I generally prohibit tool calling in the first stack frame of
| complex agents in order to preserve context window for the
| overall task and human interaction. Most of the nasty token
| consumption happens in brief, nested conversations that pass
| summaries back up the call stack.
| fittingopposite wrote:
| I don't get the announcement. Is this included in the standard 5
| or 20x Max plans?
| alienchow wrote:
| If this is a skill issue, feel free to let me know. In general
| Claude Code is decent for tooling. Onduty fullstack tooling
| features that used to sit ignored in the on-caller ticket queue
| for months can now be easily built in 20 minutes with unit tests
| and integration tests. The code quality isn't always the best
| (although what's good code for humans may not be good code for
| agents) but that's another specific and directed prompt away to
| refactor.
|
| However, I can't seem to get Opus 4.6 to wire up proper
| infrastructure. This is especially so if OSS forks are used. It
| trips up on arguments from the fork source, invents args that
| don't exist in either, and has a habit of tearing down entire
| clusters just to fix a Helm chart for "testing purposes". I've
| tried modifying the CLAUDE.md and SPEC.md with specific
| instructions on how to do things but it just goes off on a
| tangent and starts to negotiate on the specs. "I know you asked
| for help with figuring out the CNI configurations across 2
| clusters but it's too complex. Can we just do single cluster?"
| The entire repository gets littered with random MD files
| everywhere for directory specific memories, context, action
| plans, deprecated action plans, pre-compaction memories etc. I
| don't quite know which to prune either. It has taken most of the
| fun out of software engineering and I'm now just an Obsidian
| janitor for what I can best describe as a "clueless junior
| engineer that never learns". When the auto compaction kicks in
| it's like an episode of 50 first dates.
|
| Right now this is where I assume is the limitation because the
| literature for real-world infrastructure requiring large contexts
| and integration is very limited. If anyone has any idea if Claude
| Opus is suitable for such tasks, do give some suggestions.
| aenis wrote:
| Sample of one and all that, but it's way, way more sloppy than it
| used to be for me.
|
| To the extent, that I have started making manual fixes in the
| code - I haven't had to stoop to this in 2 months.
|
| Max subscription, 100k LOC codebases more or less (frontend and
| backend - same observations).
| jeff_antseed wrote:
| the coherence question is the one that matters here. 1M tokens is
| not the same as actually using 1M tokens well.
|
| we've been testing long-context in prod across a few models and
| the degradation isn't linear -- there's something like a cliff
| somewhere around 600-700k where instruction following starts
| getting flaky and the model starts ignoring things it clearly
| "saw" earlier. its not about retrieval exactly, more like... it
| stops weighting distant context appropriately.
|
| gemini's problems with loops and tool forgetting that someone
| mentioned are real. we see that too. whether claude actually
| handles the tail end of 1M coherently is the real question here,
| and "standard pricing with no long-context premium" doesn't
| answer it.
|
| honestly the fact that they're shipping at standard pricing is
| more interesting to me than the window size itself. that suggests
| they've got the KV cache economics figured out, which is harder
| than it sounds.
| gskm wrote:
| Spot on. That cliff might be less about the model failing at
| distance and more about noise accumulating faster than signal.
| In prod, most of what fills the window is file reads, grep
| output, and tool overhead, i.e., low-value tokens. By 700k
| you're not really testing long-context reasoning, you're
| testing the model's ability to find signal in a haystack it
| built itself.
| shanjai_raj7 wrote:
| are the costs the same as the 200k context opus 4.6?
|
| compaction has been really good in claude we don't even recognize
| the switch
| tariky wrote:
| This is amazing. I have to test it with my reverse engineering
| workflow. I don't know how many people use CC for RE but it is
| really good at it.
|
| Also it is really good for writing SketchUp plugins in ruby. It
| one shots plugins that are in some versions better then
| commercial one you can buy online.
|
| CC will change development landscape so much in next year. It is
| exciting and terrifying in same time.
| suheilaaita wrote:
| This blew my mind the first i saw this. Another leap in AI that
| just swooshes by. In a couple of months, every model will be the
| same. Can't wait for IDEs like cursor and vs code to update their
| tooling to adap for this massive change in claude models.
| holoduke wrote:
| I am currently mass translating millions of records with short
| descriptions. Somehow tokens are consumed extremely fast. I have
| 3 max memberships. And all 3 of them are hitting the 5 hour limit
| in about 5 to 10 minutes. Still don't understand why this is
| happening.
| cbg0 wrote:
| Unless you're clearing up the context for each description or
| processing them in parallel with subagents your context window
| will grow for each short description added to it making you hit
| those hour limits.
| k__ wrote:
| I heard, the middle of the context is often ignored.
|
| Do long context windows make much sense then or is this just a
| way of getting people to use more tokens?
| mvrckhckr wrote:
| I never get to more than 20% of the 1M context window, and it's
| working great. (Have the same experience in Codex with 5.4.)
| yubainu wrote:
| 1M is truly amazing. However, what is the incidence of
| hallucination? I haven't found a benchmark, but I feel that
| maintaining context at 1M would likely increase hallucination. Is
| there some kind of mechanism to suppress hallucination?
| drcongo wrote:
| Could be pure coincidence, but my Claude Code session last night
| was an absolute nightmare. It kept forgetting things it had done
| earlier in the session and why it had done them, messed up a git
| merge so badly that it lost the CLAUDE.md file along with a lot
| of other stuff, and then started running commands on the host
| machine instead of inside the container because it no longer had
| a CLAUDE.md to tell it not to. Last night was the first time I've
| ever sworn at it.
| xvector wrote:
| I think this is just the nature of a nondeterministic system;
| occasionally you're gonna be unlucky enough to encounter the
| leftmost segment of the bell curve.
|
| In my experience dumping a summary + starting a fresh session
| helps in these cases.
| efeecllk wrote:
| finally. before 1m, i must speak 60k context for just telling the
| past chat and project
| jFriedensreich wrote:
| My testing was extremely disappointing, this is not a context
| window that magically extends your breathing room for a
| conversation. I can tell blindly at this point when 150 - 200 k
| tokens are reached because the coding quality and coherence just
| drops by one or two generations. Its great for the case you
| really need a giant context for specific task but it changes
| nothing for needing to compact or handover at 200k.
| iandanforth wrote:
| I'm very happy about this change. For long sessions with Claude
| it was always like a punch to the gut when a compaction came
| along. Codex/GPT-5.4 is better with compactions so I switched to
| that to avoid the pain of the model suddenly forgetting key
| aspects of the work and making the same dumb errors all over
| again. I'm excited to return to Claude as my daily driver!
| cubefox wrote:
| > Standard pricing now applies across the full 1M window for both
| models, with no long-context premium.
|
| Does that mean it's likely not a Transformer with quadratic
| attention, but some other kind of architecture, with linear time
| complexity in sequence length? That would be pretty interesting.
| bob1029 wrote:
| It's almost certainly not quadratic at 1M. This would be wildly
| infeasible at scale. 10^6^2 = 10^12. That's a trillion things.
|
| They are probably doing something like putting the original
| user prompt into the model's environment and providing special
| tools to the model, along with iterative execution, to fully
| process the entire context over multiple invokes.
|
| I think the Recursive Language Model paper has a very good take
| on how this might go. I've seen really good outcomes in my
| local experimentation around this concept:
|
| https://arxiv.org/abs/2512.24601
|
| You can get exponential scaling with proper symbolic stack
| frames. Handling a gigabyte of context is feasible, assuming it
| fits the depth first search pattern.
| FartyMcFarter wrote:
| They're probably taking shortcuts such as taking advantage of
| sparsity. There are various tricks like that mentioned in some
| papers, although the big companies are getting more and more
| secretive about how their models work so you won't necessarily
| find proof.
| AbstractH24 wrote:
| Am I crazy or wasn't this announced like 2 weeks ago?
|
| Or was that a different company or not GA. It's all becoming a
| blur.
| sailfast wrote:
| This is great news. The 1M context is much easier to work with
| than compacting all the time and seems to perform and remember
| quite well despite the insane amount of data.
| jmkozko wrote:
| Do subscription users still need to tap into "extra usage"
| spending to go above 200K tokens?
| thebigspacefuck wrote:
| I used this for a bit and I felt like it was slower and generally
| worse than using 200K with context compaction. Context compaction
| does lose some things though.
| jwilliams wrote:
| I'm fairly sure that your best throughput is _single-prompt_
| single-shot runs with Claude (and that means no plan, no swarms,
| etc) -- just with a high degree of work in parallel.
|
| So for me this is a pretty huge change as the ceiling on a single
| prompt just jumped considerably. I'm replaying some of my less
| effective prompts today to see the impact.
| jeremychone wrote:
| Interesting, I've never needed 1M, or even 250k+ context. I'm
| usually under 100k per request.
|
| About 80% of my code is AI-generated, with a controlled workflow
| using dev-chat.md and spec.md. I use Flash for code maps and
| auto-context, and GPT-4.5 or Opus for coding, all via API with a
| custom tool.
|
| Gemini Pro and Flash have had 1M context for a long time, but
| even though I use Flash 3 a lot, and it's awesome, I've never
| needed more than 200k.
|
| For production coding, I use
|
| - a code map strategy on a big repo. Per file: summary,
| when_to_use, public_types, public_functions. This is done per
| file and saved until the file changes. With a concurrency of 32,
| I can usually code-map a huge repo in minutes. (Typically Flash,
| cheap, fast, and with very good results)
|
| - Then, auto context, but based on code lensing. Meaning auto
| context takes some globs that narrow the visibility of what the
| AI can see, and it uses the code map intersection to ask the AI
| for the proper files to put in context. (Typically Flash, cheap,
| relatively fast, and very good)
|
| - Then, use a bigger model, GPT 5.4 or Opus 4.6, to do the work.
| At this point, context is typically between 30k and 80k max.
|
| What I've found is that this process is surprisingly effective at
| getting a high-quality response in one shot. It keeps everything
| focused on what's needed for the job.
|
| Higher precision on the input typically leads to higher precision
| on the output. That's still true with AI.
|
| For context, 75% of my code is Rust, and the other 25% is TS/CSS
| for web UI.
|
| Anyway, it's always interesting to learn about different
| approaches. I'd love to understand the use case where 1M context
| is really useful.
| firemelt wrote:
| whenever I see post like this
|
| i said well yeah, but its too sophiscated to be practical
| adammarples wrote:
| It's not sophisticated at all, he just uses a model to make
| some documentation before asking another model to work using
| the documentation
| jeremychone wrote:
| Fair point, but because I spent a year building and refining
| my custom tool, this is now the reality for all of my AI
| requests.
|
| I prompt, press run, and then I get this flow: dev setup
| (dev-chat or plan) code-map (incremental 0s 2m for initial)
| auto-context (~20s to 40s) final AI query (~30s to 2m)
|
| For example, just now, in my Rust code (about 60k LOC), I
| wanted to change the data model and brainstorm with the AI to
| find the right design, and here is the auto-context it gave
| me:
|
| - Reducing 381 context files ( 1.62 MB)
|
| - Now 5 context files ( 27.90 KB)
|
| - Reducing 11 knowledge files ( 30.16 KB)
|
| - Now 3 knowledge files ( 5.62 KB)
|
| The knowledge files are my "rust10x" best practices, and the
| context files are the source files.
|
| (edited to fix formatting)
| cloverich wrote:
| This is really interesting; ive done very high level code maps
| but the entire project seems wild, it works?
|
| So, small model figures out which files to use based on the
| code map, and then enriches with snippets, so big model ideally
| gets preloaded with relevant context / snippets up front?
|
| Where does code map live? Is it one big file?
| jeremychone wrote:
| So, I have a pro@coder/.cache/code-map/context-code-map.json.
|
| I also have a `.tmpl-code-map.jsonl` in the same folder so
| all of my tasks can add to it, and then it gets merged into
| context-code-map.json.
|
| I keep mtime, but I also compute a blake3 hash, so if mtime
| does not match, but it is just a "git restore," I do not redo
| the code map for that file. So it is very incremental.
|
| Then the trick is, when sending the code map to AI, I
| serialize it in a nice, simple markdown format.
|
| - path/to/file.rs - summary: ... - when to use: ... - public
| types: .., .., .. - public functions: .., .., ..
|
| - ...
|
| So the AI does not have to interpret JSON, just clean,
| structured markdown.
|
| Funny, I worked on this addition to my tool for a week,
| planning everything, but even today, I am surprised by how
| well it works.
|
| I have zero sed/grep in my workflow. Just this.
|
| My prompt is pro@coder/coder-prompt.md, the first part is
| YAML for the globs, and the second part is my prompt.
|
| There is a TUI, but all input and output are files, and the
| TUI is just there to run it and see the status.
| smusamashah wrote:
| It seems like a very good use of LLMs. You should write a blog
| post with detail of your process with examples for people who
| are not into all AI tools as much. I only use Web UI. Lots of
| what you are saying is beyond me, but it does sound like clever
| strategy.
| daemonk wrote:
| Yeah this is the simpler and also effective strategy. A lot of
| people are building sophisticated AST RAG models. But you
| really just need to ask Claude to generally build a semantic
| index for each large-ish piece of code and re-use it when
| getting context.
|
| You have to make sure the semantic summary takes up
| significantly less tokens than just reading the code or its
| just a waste of token/time.
|
| Then have a skill that uses git version logs to perform lazy
| summary cache when needed.
| speakbits wrote:
| I think you've kind of hit on the more successful point here,
| which is that you should be keeping things focused in a
| sufficiently focused area to have better success and not
| necessarily needing more context.
| CuriouslyC wrote:
| 1M context is super useful with Gemini, not so much for coding,
| but for data analysis.
| jeremychone wrote:
| Even there, I use AI to augment rows and build the code to
| put data into Json or Polars and create a quick UI to query
| the data.
| LuxBennu wrote:
| Your code map compresses signal on the context side. Same
| principle applies on the prompt side: prompts that front-load
| specifics (file, error, expected behavior) resolve in 1-2
| turns. Vague ones spiral into 5-6. 1M context doesn't change
| that -- it just gives you more room for the spiral.
| make_it_sure wrote:
| very interested in this approach and many other people are for
| sure. Please do a blog post.
| tontinton wrote:
| Yeah we all converge to the same workflow, in my ai coding
| agent I'm working on now, I've added an "index" tool that uses
| tree-sitter to compress and show the AI a skeleton of a code
| file.
|
| Here's the implementation for the interested:
| https://github.com/tontinton/maki/blob/main/maki-code-index%...
| jeremychone wrote:
| Oh, that's great.
|
| I've always wanted to explore how to fit tree-sitter into
| this workflow. It's great to know that this works well too.
|
| Thanks for sharing the code.
|
| (Here is the AIPack runtime I built, MIT:
| https://github.com/aipack-ai/aipack), and here is the code
| for pro@coder (https://github.com/aipack-ai/packs-
| pro/tree/main/pro/coder) (AIPack is in Rust, and AI Packs are
| in md / lua)
| rafael-lua wrote:
| Well, out of all the workflows I have seen, this one is rather
| nice, might give it a try.
|
| I imagine if the context were being commited and kept up-to-
| date with CI would work for others to use as well.
|
| However, I'm a little confused on the autocontext/globs
| narrowing part. Do you, the developer, provide them? Or you
| feed the full code map to flash + your prompt so it returns the
| globs based on your prompt?
|
| Also, in general, is your map of a file relatively smaller than
| the file itself, even for very small files?
| jeremychone wrote:
| - The ..-code-map.json files are per "developer folder,"
| which would create too many conflicts if they were kept in
| Git.
|
| - I have two main globs, which are lists of globs:
| knowledge_globs and context_globs. Knowledge can be absolute
| and should be relatively static. context_globs have to be
| relative to the workspace, since they are the working files.
|
| - As a dev, you provide them in the top YAML section of the
| coder-prompt.md.
|
| - The auto-context sub-agent calls the code-map sub-agent.
| Sub-agents can add to or narrow the given globs, and that is
| the goal of the auto-context agent.
|
| It looks complicated, but it actually works like a charm.
|
| Hopefully, I answered some of your questions.
|
| I need to make a video about it.
|
| But regardless, I really think it's not about the tools, it's
| about the techniques. This is where the true value is.
| exceptione wrote:
| > I need to make a video about it.
|
| My 2ct, I think writing and reading an article is easier.
| jeremychone wrote:
| point taken.
| lukeundtrug wrote:
| I built myself an AST based solution for that during the last 6
| months roughly. I always wondered whether grep and agent-based
| discovery will be the end of it and thought it just has to be
| better with a more deterministic approach.
|
| In the end it's hard to measure but personally I feel that my
| agent rarely misses any context for a given task, so I'm pretty
| happy with it.
|
| I used a different approach than tree-sitter because I thought
| I found a nice way to get around having to write language-
| specific code. I basically use VSCode as a language backend and
| wrote some logic to basically rebuild the AST tree from
| VSCode's symbol data and other API.
|
| That allows me to just install the correct language extension
| and thus enable support for that specific language. The
| extension has to provide symbol information which most do
| through LSP.
|
| In the end it was way more effort than just using tree-sitter,
| however, and I'm thinking of doing a slow migration to that
| approach sooner or later.
|
| Anyways, I created an extension that spins up an mcp server and
| provides several tools that basically replace the vanilla
| discovery tools in my workflow.
|
| The approach is similar to yours, I have an overview tool which
| runs different centrality ranking metrics over the whole
| codebase to get the most important symbols and presents that as
| an architectural overview to the LLM.
|
| Then I have a "get-symbol-context" tool which allows the AI to
| get all the information that the AST holds about a single
| symbol, including a parameter to include source code which
| completely replaces grepping and file reading for me.
|
| The tool also specifies which other symbols call the one in
| question and which others it calls, respectively.
|
| But yeah, sorry for this being already a quite long comment, if
| you want to give it a try, I published it on the VSCode
| marketplace a couple of days ago, and it's basically free right
| now, although I have to admit that I still want to try to earn
| a little bit of money with it at some point.
|
| Right now, the daily usage limit is 2000 tool calls per day,
| which should be enough for anybody.
|
| Would love to hear what you think :)
|
| <https://marketplace.visualstudio.com/items?itemName=LuGoSoft..
| .>
| exceptione wrote:
| > - a code map strategy on a big repo. Per file: summary,
| when_to_use, public_types, public_functions. This is done per
| file and saved until the file changes. With a concurrency of
| 32, I can usually code-map a huge repo in minutes. (Typically
| Flash, cheap, fast, and with very good results)
|
| Thanks, but why use any AI to generate this? I would say: you
| document your functions-in-code, types are provided from the
| compiler service, so it should all be deterministically
| available in seconds iso minutes, without burning tokens. Am I
| missing something?
| jeremychone wrote:
| Very good point. I had two options:
|
| 1) Deterministic - Using a tree-sitter/AST-
| like approach, I could extract types, functions, and perhaps
| comments, and put them into an index map. - Cons:
| - The tricky part of this approach is that what I extract can
| be pretty large per file, for example, comments.
| - Then, I would probably need an agentic synthesis step for
| those comments anyway.
|
| 2) Agentic - Since Flash is dirt cheap, I
| wanted to experiment and skip #1, and go directly to #2.
| - Because my tool is built for concurrency, when set to 32,
| it's super fast. - The price is relatively low,
| perhaps $1 or $2 for 50k LOC, and 60 to 90 seconds, about 30
| to 45 minutes of AI work. - What I get back is
| relatively consistent by file, size-wise, and it's just one
| trip per file.
|
| So, this is why I started with #2.
|
| And then, the results in real coding scenarios have been
| astonishing.
|
| Way above what I expected.
|
| The way those indexes get combined with the user prompt gets
| the right files 95% of the time, and with surprisingly high
| quality.
|
| So, I might add deterministic aspects to it, but since I
| think I will need the agentic step anyway, I have
| deprioritized it.
| ra7 wrote:
| This is fascinating. I feel like this is converging into the
| concept of a traditional "IDE". So much of your setup reminds
| me of IDEs indexing, doing static analysis, building ASTs, etc.
| before a developer starts writing code.
| ofisboy wrote:
| i think it's buggy. i keep getting "compacting conversation" even
| though i restarted the cli. and i'm for sure not using 5 times
| more.
| elophanto_agent wrote:
| finally, enough context to fit my entire codebase AND my excuses
| for why it doesn't work
| anshumankmr wrote:
| All while their usage limits are so excessively shitty that I
| paid them 50$ just two days back cause I ran out of usage and
| they still blocked from using it during a critical work week (and
| did not refund my 50$ despite my emails and requests and route me
| to s*ty AI bot.). Anyway, I am using Copilot and OpenCode a lot
| more these days which is much better.
| praddlebus wrote:
| What model(s) do you use with OpenCode? Can you use opus4.6 1m?
| Is it better in terms of usage if you use the same model?
| ionwake wrote:
| Have we reached the point where its "normal" to mostly use AI to
| code? Im just wondering because Im sure it was less than a month
| ago when I said I havent coded manually for over 6 months and I
| had several comments about how my code must be terrible.
|
| Im not butt hurt Im just wondering if the overton window has
| shifted yet.
| heraldgeezer wrote:
| I feel like I'm the only one here using AI as just a chatbot for
| research, shopping, advice etc and for one off regex or bash/ps
| scripts... then again not a programmer so.
| PeterStuer wrote:
| The thing that would get me more excited is how far they could
| push context coherence before the model loses track. I'm hoping
| 250k.
| MorkMindy74 wrote:
| One real-world use case I've found for large context: reading the
| full body of a Word document before editing it. In an Office.js
| add-in I built, the entire document text is passed as context
| before any AI action (rewriting, reviewing, summarizing). Without
| a large window, you'd have to chunk the document and lose cross-
| section coherence -- which matters a lot for legal documents
| where a clause in section 1 constrains what you can say in
| section 8. At ~100k tokens you can cover most contracts
| comfortably; 1M opens the door to full due diligence bundles.
| Context decay is real though -- I've noticed quality dropping
| toward the end of long inputs even when the relevant text is
| there.
___________________________________________________________________
(page generated 2026-03-14 23:00 UTC)