Your question is worded kind of confusingly, but all caching is handled on the inference layer, and by all major providers. In short, caching should work as long as you are sending requests to the same model and provider.
Apologies. I guess my main question is just is there a benefit to routing directly to a provider through its own harness vs just sending chat requests to those providers using OpenRouter or similar as a proxy?
As per your response it sounds like at least caching would happen for any provider regardless of the request's origin.
I’m currently on codex can it also this? I find it hard to make accurate benchmarks in token use for these kind of changes because I don’t keep repeating the same tasks.
Basically I run in luna high or extra high continuously with a terra subworker dedicated to planning and difficult research questions. Then I end with a final review in Terra or Sol depending how big the feature is.
yes, and you can do it entirely in developer instructions (AGENTS.md/SKILLS.md). No hooks or other executables needed. Check out `codex-subagent-router` for an example. Its overly complicated, and has a few things wrong, but it mostly works. In short:
- Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
- Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
- in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
- Explain they can use "default" or specify their own custom model settings if needed.
- Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.
Details to know:
- IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
- You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest.
Anyways, write you skill & subagent profiles and it basically "just works".
That's an example of why it would be useful for someone to actually do it. A random commenter on HN is one thing. A direct comparison on a brand new app that isn't part of any training is another
That's an example of why it would be useful for someone to actually do it. A random commenter on HN is one thing. A direct comparison on a brand new app that isn't part of any training is another
People need to stop repeating this because it’s not true. Yes, other models can find the same vulnerabilities Mythos found… if pointed at the exact code that has each vulnerability. It does not mean they are nearly as capable when starting from scratch, or when chaining multiple (often very obscure) vulnerabilities).
Anthropic themselves have explained that the harness for Mythos has a very important role in finding the vulnerabilities, because the model does not start from scratch, but the harness runs the model many times on each file of the code base, with different prompts, where the prompts evolve depending on the results of the previous runs.
First with more generic prompts, to determine whether it is worthwhile to do a detailed analysis of that file, then with more specific prompts to identify the bugs, and eventually with a prompt that requests a confirmation that a given bug/vulnerability exists.
For a proper comparison between some other model and Mythos, you also need such a complex harness. If you just tell to an LLM "find the bugs", and it does not find a vulnerability known to have been found by Mythos, that is a totally invalid comparison.
The final results provided by Mythos, like a PoC exploit or a patch, are also generated with a prompt that points to the exact code that has the vulnerability (which is supposed to exist based on the results of the previous runs).
My take from the SCW interview is that the Mythos harness isn't all that important and the author thought it would be even less important with future models. But maybe I misremember.
Anthropic has a vested interest in downplaying the harness relevance. In my experience harness really matters. More capable models are great, but current models are enough if you put some engineering effort into the harness.
I think you have it backwards. Systems engineering is the big picture discipline of designing & managing complex systems while config management is a specific process within that.
The amount of paths in the wrong direction are infinitely more than then number in the right direction. You'll quickly realize this doesn't actually scale.
I'm a bit confused by this; are you referring to vanishing/exploding gradients during training or iteration at inference? If the former, this is only true if you take too many steps. If the latter, we already know this works and scales well.
The latter, and I would disagree that “this works and scales well” in the general sense. It clearly has very finite bounds by the fact we haven’t achieved agi by running an llm in a loop..
The approach of “try a few more things before stopping” is a great strategy akin to taking a few more stabs at RNG. It’s not the same as saying keep trying until you get there - you won’t.
> It clearly has very finite bounds by the fact we haven’t achieved agi by running an llm in a loop..
That's one hell of a criterion. Test-time inference undergoes a similar scaling law to pretraining, and has resulted in dramatically improved performance on many complex tasks. Law of diminishing returns kicks in of course, but this doesn't mean it's ineffective.
> akin to taking a few more stabs at RNG
Assuming I understand you correctly, I disagree. Scaling laws cannot appear with glassy optimisation procedures (essentially iid trials until you succeed, the mental model you seem to be implying here). They only appear if the underlying optimisation is globally connected and roughly convex. It's no different than gradient descent in this regard.
But test-time inference leads to better data to train better models that can generate better test-time inference data.
There's an obvious trend going on here, of course we're still just growing these systems and going with whatever works.
It's worked well so far, even if it's more convoluted than elegant...
What puts my mind at ease is that the current state of these AI systems isn't going to go backwards because of the data they generate which contributes to the pool of possible knowledge for more advanced systems.
I never made a claim that it's ineffective, just that it's of limited effectiveness. The diminishing returns kick in quickly, and it's not applicable in more domains than it is applicable.
It's a hyperparameter much like learning rate. If the learning rate is too high, the training process would not work either. Addressing this is just a matter of a grid search.
Sorry to break it to you but 10% profit on 6.5M rev is very low and will absolutely not fetch a high multiple, especially considering this is a mature 10 year old business. This is not a high growth business and you may have grown overly rose colored glasses by thinking it could be priced as one.
So much more. What assets/patents do they own? How much money is in the bank? What does their liability sheet look like? How “hot” is their industry right now?
Some time ago I found a good formula to plugin numbers and get a valuation multiple. The questions above were the ones that really moved the multiplier. A major lot of “startups” are in the 1-2x range. The hot ones will peak at 7-12x.
I suppose the industry is not hot right now. EdTech was never really very hot. It was 'luke warm' at best, a decade ago. They own a lot of software, also, they publish their own math textbook (both digital and print). They have licenses with thousands of schools across multiple countries. I don't recall they have any debt.
I feel like they could easily bump up profits by $2 million just by letting go of people... But they could probably double the license cost per student. Although schools don't have much money, they are kind of slow and bureaucratic; set in their ways. It's a small cost for them anyway, once a system is part of the curriculum, they'll probably pay extra to avoid reorganizing the lessons.
As you describe this is largely a cash flow business and the bulk of the value should be extracted via dividends to the benefit of major shareholders.
A tech enabled business needs gross margins north of 70% to be attractive from a leverage standpoint, unless revenue is scaling very rapidly. Without these there’s no attractive exit opportunities.
There are border towns where some workers do daily crossings. Without refund infrastructure in place it looks like this would add $250/day fee for all of these individuals
reply