17 pointsby paoloanzn7 hours ago5 comments
  • fractorial5 hours ago
    I’m not quite sure why the harness itself needs to be small. Isn’t the system prompt and management of system prompt the bit you want lightweight?
    • userbinator5 hours ago
      "Why does it need to be large?" should be the question instead.
      • selcuka4 hours ago
        A harness needs to be good. Being large is annoying, sure, but it's generally not an issue. Unless this one has feature parity with the "large" ones (hint: it doesn't), I don't see any reason to use it only because it's small.
        • cyanydeez4 hours ago
          ultimately, the harness is just going to be another model specifically engineered to be deterministic, like ballbearings in a wheel minimizing friction.
    • embedding-shape2 hours ago
      Probably you want all of them to be as simple and small as possible, especially if you want to use it to work on itself. Smaller codebases are (generally) easier to work with.
      • adithyassekhar2 minutes ago
        Sometimes smaller software has the harder codebase.
    • K0IN4 hours ago
      I think it's nice to have options, but I also don't see the appeal in "sub x mb" (except as codegolf or just for the hacky part, for day to day this does not matter) especially if features are missing or other compromises have been made just for the sake of remaining small.
  • orliesaurus4 hours ago
    i love the idea, but you also need to maintain it long term: in today's world what is the best practice to do that... do you spin up an agent anytime codex-cli updates and mirror the updates in c++ and push a new release? or idk... set up an automated process that does this on a worker on CF in a sandbox when npm updates @openai/codex?
  • xms17189an hour ago
    [flagged]
  • duckweed_show3 hours ago
    [dead]
  • zane_shu5 hours ago
    [dead]