foresight-agent-guard 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- foresight_agent_guard-0.1.0/LICENSE +21 -0
- foresight_agent_guard-0.1.0/PKG-INFO +305 -0
- foresight_agent_guard-0.1.0/README.md +276 -0
- foresight_agent_guard-0.1.0/foresight/__init__.py +3 -0
- foresight_agent_guard-0.1.0/foresight/benchmark.py +153 -0
- foresight_agent_guard-0.1.0/foresight/cli.py +370 -0
- foresight_agent_guard-0.1.0/foresight/config.py +139 -0
- foresight_agent_guard-0.1.0/foresight/demo_scenario.py +190 -0
- foresight_agent_guard-0.1.0/foresight/eventbus_bridge.py +12 -0
- foresight_agent_guard-0.1.0/foresight/guardrail_scenarios.py +180 -0
- foresight_agent_guard-0.1.0/foresight/injection_benchmark.py +165 -0
- foresight_agent_guard-0.1.0/foresight/multi_task_session.py +139 -0
- foresight_agent_guard-0.1.0/foresight/predictor.py +167 -0
- foresight_agent_guard-0.1.0/foresight/session_monitor.py +360 -0
- foresight_agent_guard-0.1.0/foresight/workflow_demo.py +114 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/PKG-INFO +305 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/SOURCES.txt +30 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/dependency_links.txt +1 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/entry_points.txt +2 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/requires.txt +6 -0
- foresight_agent_guard-0.1.0/foresight_agent_guard.egg-info/top_level.txt +2 -0
- foresight_agent_guard-0.1.0/pyproject.toml +44 -0
- foresight_agent_guard-0.1.0/sentry/__init__.py +1 -0
- foresight_agent_guard-0.1.0/sentry/eventbus/__init__.py +2 -0
- foresight_agent_guard-0.1.0/sentry/eventbus/server.py +244 -0
- foresight_agent_guard-0.1.0/sentry/policy/__init__.py +2 -0
- foresight_agent_guard-0.1.0/sentry/policy/engine.py +350 -0
- foresight_agent_guard-0.1.0/sentry/policy/schema.py +33 -0
- foresight_agent_guard-0.1.0/sentry/proxy/__init__.py +2 -0
- foresight_agent_guard-0.1.0/sentry/proxy/actions.py +15 -0
- foresight_agent_guard-0.1.0/sentry/proxy/interceptor.py +475 -0
- foresight_agent_guard-0.1.0/setup.cfg +4 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 AmanM006
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,305 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: foresight-agent-guard
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Predictive cost, policy, and runaway-session guardrails for AI coding agents
|
|
5
|
+
Author: Aman M
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/AmanM006/foresight
|
|
8
|
+
Project-URL: Repository, https://github.com/AmanM006/foresight
|
|
9
|
+
Project-URL: Issues, https://github.com/AmanM006/foresight/issues
|
|
10
|
+
Keywords: ai-agents,codex,gpt,cost-monitoring,developer-tools
|
|
11
|
+
Classifier: Development Status :: 3 - Alpha
|
|
12
|
+
Classifier: Intended Audience :: Developers
|
|
13
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
14
|
+
Classifier: Operating System :: OS Independent
|
|
15
|
+
Classifier: Programming Language :: Python :: 3
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
18
|
+
Classifier: Topic :: Software Development
|
|
19
|
+
Requires-Python: >=3.11
|
|
20
|
+
Description-Content-Type: text/markdown
|
|
21
|
+
License-File: LICENSE
|
|
22
|
+
Requires-Dist: click<9,>=8.1
|
|
23
|
+
Requires-Dist: openai<3,>=1.0
|
|
24
|
+
Requires-Dist: python-dotenv<2,>=1.0
|
|
25
|
+
Requires-Dist: requests<3,>=2.31
|
|
26
|
+
Requires-Dist: rich<15,>=13.0
|
|
27
|
+
Requires-Dist: websockets<16,>=13
|
|
28
|
+
Dynamic: license-file
|
|
29
|
+
|
|
30
|
+
# Foresight
|
|
31
|
+
|
|
32
|
+
**Foresight is a predictive cost and tier-routing layer for AI coding agents.** It chooses the right level of reasoning before work begins, then watches the session closely enough to stop drift before it becomes expensive.
|
|
33
|
+
|
|
34
|
+

|
|
35
|
+

|
|
36
|
+

|
|
37
|
+

|
|
38
|
+
|
|
39
|
+
> **Install from PyPI (after the first release)**
|
|
40
|
+
>
|
|
41
|
+
> ```bash
|
|
42
|
+
> pip install foresight-agent-guard
|
|
43
|
+
> foresight --help
|
|
44
|
+
> ```
|
|
45
|
+
|
|
46
|
+
> **Build from source / quick test**
|
|
47
|
+
>
|
|
48
|
+
> ```bash
|
|
49
|
+
> git clone https://github.com/AmanM006/foresight.git
|
|
50
|
+
> cd foresight
|
|
51
|
+
> pip install -e .
|
|
52
|
+
> copy .env.example .env
|
|
53
|
+
> python -m foresight.demo_scenario
|
|
54
|
+
> ```
|
|
55
|
+
>
|
|
56
|
+
> Add your `OPENAI_API_KEY` to `.env` after copying the example file. On macOS/Linux, use `cp .env.example .env`.
|
|
57
|
+
|
|
58
|
+
## Verify this submission
|
|
59
|
+
|
|
60
|
+
Run the complete replay-safe verification pass with one command:
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
python verify.py
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
It checks the environment, runs tests when present, and executes the full replay demo without spending tokens. Add `--live` only when you want it to run the paid tier and injection benchmarks as well. For a zero-setup visual alternative, explore the deployed dashboard at [sentry-lime.vercel.app](https://sentry-lime.vercel.app).
|
|
67
|
+
|
|
68
|
+
## The problem
|
|
69
|
+
|
|
70
|
+
When developers use Codex/GPT-5.6 for coding work, they often do not know upfront which tier or reasoning effort a task actually needs. Defaulting to Sol overpays for mechanical work; choosing too small a tier can leave an agent stuck and repeatedly escalating.
|
|
71
|
+
|
|
72
|
+
The risk is not hypothetical. An open [Codex issue #32250](https://github.com/openai/codex/issues/32250) reports GPT-5.6 Sol Medium reducing a Pro five-hour allowance from 87% to 76% during a short conversation and several trivial follow-ups. Recent [r/codex](https://www.reddit.com/r/codex/comments/1ust6y8/usage_drops_much_faster_now_despite_less_cost/) and [r/ChatGPTPro](https://www.reddit.com/r/ChatGPTPro/comments/1us02nr/56_rate_limits/) threads describe confusion around five-hour versus weekly limits; these are community reports, not a claim about every session. Community guidance also identifies duplicated context and uncontrolled subagent spawning as sources of extra consumption ([discussion](https://www.reddit.com/r/codex/comments/1uu7weh/possible_fixes_for_gpt_56_burning_through_your/)).
|
|
73
|
+
|
|
74
|
+
There is a second failure mode: scope creep. A small implementation task can turn into unrequested architecture work, sprawling documentation, or broad file changes—the “Sol Ultra problem” discussed by users—silently consuming budget without an early warning. OpenAI documents that `ultra` coordinates four agents in parallel by default and trades higher token use for stronger results on demanding tasks; it is not an appropriate default for every coding task ([OpenAI GPT-5.6 overview](https://openai.com/index/gpt-5-6/)).
|
|
75
|
+
|
|
76
|
+
**Foresight solves this by predicting complexity and tier before execution, then watching the live session to catch drift before it compounds.**
|
|
77
|
+
|
|
78
|
+
## Live demo proof
|
|
79
|
+
|
|
80
|
+
One real recorded demo run produced the following result:
|
|
81
|
+
|
|
82
|
+
| Signal | Observed result |
|
|
83
|
+
| --- | --- |
|
|
84
|
+
| Predicted route | `luna / low / isolated` |
|
|
85
|
+
| Files touched | `16` |
|
|
86
|
+
| Predictive flag | `scope_explosion` |
|
|
87
|
+
| Final disposition | `escalated_for_review` |
|
|
88
|
+
| Recorded model cost | approximately `$0.0060` |
|
|
89
|
+
|
|
90
|
+
The demo showed two independent catch mechanisms live:
|
|
91
|
+
|
|
92
|
+
- **Predictive scope-drift detection:** unrelated file changes exceeded the predicted isolated blast radius.
|
|
93
|
+
- **Forbidden-pattern interception:** an attempted `.env` read was caught and blocked by the policy layer.
|
|
94
|
+
|
|
95
|
+

|
|
96
|
+
|
|
97
|
+

|
|
98
|
+
|
|
99
|
+

|
|
100
|
+
|
|
101
|
+
Inspect the sanitized raw evidence in [`examples/`](examples/): [`policy_and_verdict_output.example.json`](examples/policy_and_verdict_output.example.json) and [`audit_event_output.example.json`](examples/audit_event_output.example.json).
|
|
102
|
+
|
|
103
|
+
## Evidence and benchmarks
|
|
104
|
+
|
|
105
|
+
| Evidence | Real result |
|
|
106
|
+
| --- | --- |
|
|
107
|
+
| **Tier prediction accuracy** | 15 hand-labeled tasks spanning mechanical, moderate, and architectural complexity. **14/15** exact tier match, **1** conservative overestimate (avatar upload: expected `terra/moderate`, predicted `sol/moderate`), **0** risky underestimates. Total cost: **$0.0346** across 15 real GPT-5.6-terra calls. [View results](benchmark_results.json). |
|
|
108
|
+
| **Injection resistance** | 10 adversarial prompt-injection scenarios across hidden HTML comments, code comments, disguised TODOs, subprocess arguments, config fields, misleading filenames, social-engineering “temporarily disable” requests, and multi-step justification chains. **9/10** caught and blocked. The one miss triggered the fail-safe path (uncertain evaluation → warning, not silent allow) rather than a full block; it is disclosed as a real finding. [View results](injection_benchmark_results.json). |
|
|
109
|
+
| **Multi-task session (false-positive check)** | One continuous session across four task types: a trivial README fix (`luna/isolated`, clean), scoped API validation (`terra/moderate`, clean), a broad payment migration (`sol/wide`, 6 files touched, not flagged as `scope_explosion` because wide scope was predicted), and an injected `.env` access attempt (blocked). Total session cost: **$0.01812**. [View results](multi_task_session_results.json). |
|
|
110
|
+
|
|
111
|
+
Run `python verify.py` to reproduce the zero-cost checks yourself, or `python verify.py --live` to reproduce the paid benchmarks above (~$0.08 total across all three).
|
|
112
|
+
|
|
113
|
+
One benchmark response includes its raw OpenAI response ID as tamper-evident proof that it was a real API call, not a fabricated result: `response_id: resp_016b9a9aa893e50d006a57492295908192b3c0b54f1eefd7c7`. The recorded response is documented in [`benchmark_results.json`](benchmark_results.json).
|
|
114
|
+
|
|
115
|
+
## What it does
|
|
116
|
+
|
|
117
|
+
- **Routes before spend:** predicts the right Luna/Terra/Sol tier, effort level, and blast radius before a single task action is evaluated.
|
|
118
|
+
- **Turns scope into enforcement:** derives a restrictive policy from the declared task instead of treating agent access as implicitly broad.
|
|
119
|
+
- **Intercepts high-risk actions:** captures file I/O, subprocesses, and network requests before execution.
|
|
120
|
+
- **Flags runaway behavior early:** detects scope explosions, low-progress churn, and repeated paralysis loops while the session is live.
|
|
121
|
+
- **Makes spend auditable:** streams actions, verdicts, predictions, signals, and token-derived costs to the event bus and dashboard.
|
|
122
|
+
|
|
123
|
+
## Architecture
|
|
124
|
+
|
|
125
|
+
```text
|
|
126
|
+
Task description
|
|
127
|
+
|
|
|
128
|
+
v
|
|
129
|
+
foresight/ predictor + session monitor
|
|
130
|
+
|
|
|
131
|
+
v
|
|
132
|
+
sentry/ interception engine + policy + event bus ----> dashboard frontend
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
- **`foresight/`** contains prediction, routing, the CLI, and session monitoring. Keeping these concerns together makes the pre-execution estimate and live escalation decision share the same session context.
|
|
136
|
+
- **`sentry/`** is the internal interception engine codename. It captures actions, applies policy, tracks costs, and publishes events. It is decoupled from `foresight/` so the security layer can be reused independently of prediction logic.
|
|
137
|
+
- **`sentry/web/`** is the single, restored Next.js dashboard. It consumes the event model rather than duplicating policy or interception behavior.
|
|
138
|
+
|
|
139
|
+
Sentry is the internal codename for the interception engine; **Foresight** is the complete product.
|
|
140
|
+
|
|
141
|
+
### Runtime decision flow
|
|
142
|
+
|
|
143
|
+
```text
|
|
144
|
+
1. Task description
|
|
145
|
+
-> predictor returns tier, effort, blast radius, and risk factors
|
|
146
|
+
-> scope-to-policy returns allowed paths, hosts, and forbidden patterns
|
|
147
|
+
|
|
148
|
+
2. Agent attempts an action
|
|
149
|
+
-> SentryProxy captures it before execution
|
|
150
|
+
-> Action(type, target, payload, timestamp, session_id)
|
|
151
|
+
|
|
152
|
+
3. Fast enforcement path
|
|
153
|
+
-> forbidden target: critical block, no model call
|
|
154
|
+
-> out-of-scope file or host: warning event
|
|
155
|
+
-> identical action repeated six times in 60 seconds: paralysis-loop block
|
|
156
|
+
|
|
157
|
+
4. Ambiguous in-scope action
|
|
158
|
+
-> GPT-5.6-terra returns a structured Verdict
|
|
159
|
+
-> allow, warn, or block before the original operation proceeds
|
|
160
|
+
|
|
161
|
+
5. Session-level monitoring
|
|
162
|
+
-> compare files, diffs, and spend against the original prediction
|
|
163
|
+
-> scope/churn signal triggers a contextual reassessment
|
|
164
|
+
-> kill only if the reassessment confirms a wide or Sol-level runaway
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
### Layer responsibilities
|
|
168
|
+
|
|
169
|
+
| Layer | Main modules | Responsibility | Why it is separate |
|
|
170
|
+
| --- | --- | --- | --- |
|
|
171
|
+
| Prediction | `foresight/predictor.py` | Produces tier, effort, blast radius, rationale, and risk factors from the task description. | Establishes an expected cost and scope baseline before any agent action exists. |
|
|
172
|
+
| Session control | `foresight/session_monitor.py` | Watches file count, repeated diffs, and cost ceilings; emits signals and reassesses drift. | Session-level behavior cannot be decided from one action alone. |
|
|
173
|
+
| Policy | `sentry/policy/engine.py` | Converts scope to `Policy`, makes local decisions first, and uses structured model review only for ambiguity. | Keeps common security decisions deterministic, cheap, and auditable. |
|
|
174
|
+
| Enforcement | `sentry/proxy/interceptor.py` | Temporarily intercepts file, subprocess, delete, and `requests` calls in the current Python process. | Places the decision immediately before the original operation can execute. |
|
|
175
|
+
| Telemetry | `sentry/eventbus/server.py` | Broadcasts actions, costs, predictions, and monitor signals over WebSocket; exports JSON audit logs. | Decouples producers from the dashboard and leaves a machine-readable record. |
|
|
176
|
+
| Presentation | `sentry/web/` | Renders live connection state, action feed, policy context, cost, and kill state. | Lets a reviewer understand a session without reading Python logs. |
|
|
177
|
+
|
|
178
|
+
### The common event contract
|
|
179
|
+
|
|
180
|
+
Every intercepted operation becomes the same `Action` record:
|
|
181
|
+
|
|
182
|
+
```text
|
|
183
|
+
Action
|
|
184
|
+
type: file_read | file_write | file_delete | subprocess | network
|
|
185
|
+
target: path, command, or host:port
|
|
186
|
+
payload: mode, unified diff, cwd/env summary, or request-size summary
|
|
187
|
+
timestamp
|
|
188
|
+
agent_session_id
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
Policy evaluation returns a `Verdict` with `severity`, `reason`, and `allowed`. This normalized pair is what the proxy enforces, the monitor observes, the event bus broadcasts, and the dashboard displays. Model use is represented separately as `CostEvent(model, input_tokens, output_tokens, cost_usd, timestamp)`.
|
|
192
|
+
|
|
193
|
+
### Four failure modes, four distinct mechanisms
|
|
194
|
+
|
|
195
|
+
Foresight deliberately gives each failure mode a distinct trigger, reason, event name, and escalation path instead of treating all anomalous activity as one generic warning:
|
|
196
|
+
|
|
197
|
+
1. **Forbidden-pattern interception** is deterministic and zero-latency. `SentryProxy` blocks an action such as `.env` access before it executes, emits the policy `Verdict`, and terminates only on a critical denied verdict. This is security enforcement, not prediction.
|
|
198
|
+
2. **Scope explosion** is predictive and contextual. `SessionMonitor` compares touched files with the predicted blast radius, emits `scope_explosion`, and re-runs complexity assessment with session context before committing to termination. A wide predicted task is not falsely killed for having a wide footprint.
|
|
199
|
+
3. **Hard action ceiling** is a deterministic workflow cap. The predictor maps `isolated` to 15 actions, `moderate` to 40, and `wide` to 100. Reaching the cap emits `hard_ceiling_reached` with `hard_action_ceiling_reached` as its final reason and terminates immediately, even if the agent believes it is nearly done.
|
|
200
|
+
4. **Parallel fan-out** detects a different failure shape from repeated loops: five distinct file or subprocess actions inside three seconds. It emits `parallel_explosion` and triggers soft reassessment, allowing deliberate, paced parallel work to remain unblocked.
|
|
201
|
+
|
|
202
|
+
**Burn-rate forecasting** is separately broadcast as `burn_forecast`, but it is intentionally informational rather than a kill switch. After enough cost events, it projects minutes remaining at the current cost/minute rate so a user can intervene before a budget ceiling is reached. This keeps forecast visibility separate from hard enforcement.
|
|
203
|
+
|
|
204
|
+
The independent `paralysis_loop` check remains in `SentryProxy`: a rolling 60-second window blocks the sixth identical action after five prior repeats before any model evaluation. It is distinct from parallel fan-out because one catches repeated identical work while the other catches a burst of different work.
|
|
205
|
+
|
|
206
|
+
This distinction is why the demo can truthfully show two independent outcomes: an immediate `.env` block from deterministic policy enforcement, and an `escalated_for_review` result after predictive scope drift is reassessed.
|
|
207
|
+
|
|
208
|
+
### Cost-aware model use
|
|
209
|
+
|
|
210
|
+
`scope_to_policy()` and `predict_complexity()` use structured output. `evaluate_action()` uses GPT-5.6-terra only when a local rule cannot resolve an in-scope but suspicious action. Each response has an explicit output cap, a stable prompt prefix for caching, and usage recorded through `CostTracker`.
|
|
211
|
+
|
|
212
|
+
Predicted effort is calibrated separately from tier: mechanical isolated work routes to `low`, normal scoped coding work defaults to `medium`, and `high` is reserved for genuinely high-stakes or architectural work. A high-effort prediction with a non-wide blast radius carries a deterministic advisory against casually escalating to `max` or `ultra`; the CLI renders it as a dim note and the dashboard renders it beside the predicted effort. No extra model call is required for that advice.
|
|
213
|
+
|
|
214
|
+
The architecture therefore treats model judgement as a metered dependency rather than an invisible background call.
|
|
215
|
+
|
|
216
|
+
### Current prototype boundaries
|
|
217
|
+
|
|
218
|
+
The repository is intentionally a focused vertical slice, not a claim of production multi-tenant infrastructure:
|
|
219
|
+
|
|
220
|
+
- Interception is process-scoped Python monkey-patching, not an operating-system sandbox.
|
|
221
|
+
- Audit events are held in memory and persisted through explicit JSON export rather than a database.
|
|
222
|
+
- Budget ceilings are current heuristics, not learned per-user limits.
|
|
223
|
+
- A deployed dashboard needs a reachable event-bus endpoint; it cannot receive events from a developer's local process without a connection path.
|
|
224
|
+
- The dashboard is intentionally a single deploy target at `sentry/web/`; a production hardening pass would add deployment-specific event-bus connectivity and persistence.
|
|
225
|
+
|
|
226
|
+
## What we got wrong, and what it taught us
|
|
227
|
+
|
|
228
|
+
We originally wrote the demo around the task “Refactor the login flow to add MFA support,” assuming it would produce a narrow `terra / isolated` prediction so the scripted scope-explosion sequence could exercise escalation. When we ran it against the real GPT-5.6-terra model, it classified MFA and authentication work as security-sensitive and returned `sol / high / wide`. That was the right call: MFA changes can affect identity, recovery, and session boundaries. Our test assumption, not the prediction, was wrong. The problem was that a wide blast radius has no file-count ceiling to exceed, so the demo narrative no longer matched the model’s real risk assessment. We redesigned the task as a genuinely narrow isolated variable rename, which keeps the expected route and scripted drift consistent. We also added a second, prediction-independent catch: the forbidden-pattern block on `.env` access. It works regardless of the predicted tier, so the demo now proves both predictive scope monitoring and deterministic interception without guessing a model outcome. This is the same principle the system is built to detect in agents: the gap between what we assumed a task’s scope was and what it actually turned out to be.
|
|
229
|
+
|
|
230
|
+
## Why not just use a bigger model for everything?
|
|
231
|
+
|
|
232
|
+
Sol costs five times Luna’s input and output price, while many coding tasks are mechanical enough to complete safely with a smaller tier. Defaulting to the frontier tier therefore creates exactly the avoidable spend Foresight is designed to expose. Prediction is not free: it adds a metered call before work begins. But a conservative prediction only adds an escalation round-trip, because Foresight reassesses live drift instead of trusting the first estimate blindly.
|
|
233
|
+
|
|
234
|
+
## Quickstart
|
|
235
|
+
|
|
236
|
+
Install the Python runtime and CLI:
|
|
237
|
+
|
|
238
|
+
```bash
|
|
239
|
+
pip install -r requirements.txt
|
|
240
|
+
# or, for the `foresight` command:
|
|
241
|
+
pip install -e .
|
|
242
|
+
```
|
|
243
|
+
|
|
244
|
+
Create your local environment file from the committed template:
|
|
245
|
+
|
|
246
|
+
```bash
|
|
247
|
+
copy .env.example .env
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Set `OPENAI_API_KEY` in `.env`, then run the end-to-end demo:
|
|
251
|
+
|
|
252
|
+
```bash
|
|
253
|
+
python -m foresight.demo_scenario
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
For a complete local replay with **zero OpenAI API calls** (using real captured GPT-5.6 policy and prediction responses), run:
|
|
257
|
+
|
|
258
|
+
```bash
|
|
259
|
+
python -m foresight.demo_scenario --replay
|
|
260
|
+
```
|
|
261
|
+
|
|
262
|
+
The live path above remains the primary demonstration. Replay is the accessible fallback for judges who want to exercise the real interception and monitoring flow without an API key. For a zero-setup visual tour of the dashboard UI, visit [the deployed dashboard](https://sentry-lime.vercel.app); it is distinct from replay mode, which runs the local Python enforcement logic.
|
|
263
|
+
|
|
264
|
+
CLI workflow:
|
|
265
|
+
|
|
266
|
+
```bash
|
|
267
|
+
foresight init
|
|
268
|
+
foresight run -- python your_agent_task.py
|
|
269
|
+
foresight status
|
|
270
|
+
foresight export
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
Run the dashboard locally:
|
|
274
|
+
|
|
275
|
+
```bash
|
|
276
|
+
cd sentry/web
|
|
277
|
+
npm install
|
|
278
|
+
npm run dev
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
Open `http://localhost:3000/dashboard`. The event bus listens on `ws://localhost:8765` by default.
|
|
282
|
+
|
|
283
|
+
## Cost tracking and prompt caching
|
|
284
|
+
|
|
285
|
+
Every OpenAI response becomes a `CostEvent`, calculated from input/output token usage and streamed to the event bus. Calls use a stable system/context prefix with only task-specific content appended, improving prompt-cache reuse. Clear forbidden or out-of-scope actions are decided locally first, avoiding unnecessary model calls.
|
|
286
|
+
|
|
287
|
+
**Every prediction and policy call is cost-tracked in real time and streamed to the dashboard—Foresight audits its own spend, not just the agent’s.**
|
|
288
|
+
|
|
289
|
+
## Codex vs Antigravity build split
|
|
290
|
+
|
|
291
|
+
- **Codex:** reasoning-critical implementation in `sentry/proxy/interceptor.py`, `sentry/policy/engine.py`, `foresight/predictor.py`, `foresight/session_monitor.py`, plus the event bus, CLI, and end-to-end demo.
|
|
292
|
+
- **Antigravity:** frontend polish in `sentry/web/`, dashboard bug fixes, deployment configuration, environment/documentation cleanup, and this submission README.
|
|
293
|
+
|
|
294
|
+
This split is intentional and documented per hackathon submission requirements—Codex built 100% of the reasoning-critical logic: prediction, policy evaluation, and escalation.
|
|
295
|
+
|
|
296
|
+
## Roadmap
|
|
297
|
+
|
|
298
|
+
- Multi-agent swarm monitoring with a shared session risk view.
|
|
299
|
+
- Historical session learning to improve tier prediction over time.
|
|
300
|
+
- Monitoring support for Claude Code and other agent runtimes beyond Codex.
|
|
301
|
+
- Team-level policy profiles and budget guardrails.
|
|
302
|
+
|
|
303
|
+
## License and attribution
|
|
304
|
+
|
|
305
|
+
MIT License. Built for Build Week, July 2026.
|
|
@@ -0,0 +1,276 @@
|
|
|
1
|
+
# Foresight
|
|
2
|
+
|
|
3
|
+
**Foresight is a predictive cost and tier-routing layer for AI coding agents.** It chooses the right level of reasoning before work begins, then watches the session closely enough to stop drift before it becomes expensive.
|
|
4
|
+
|
|
5
|
+

|
|
6
|
+

|
|
7
|
+

|
|
8
|
+

|
|
9
|
+
|
|
10
|
+
> **Install from PyPI (after the first release)**
|
|
11
|
+
>
|
|
12
|
+
> ```bash
|
|
13
|
+
> pip install foresight-agent-guard
|
|
14
|
+
> foresight --help
|
|
15
|
+
> ```
|
|
16
|
+
|
|
17
|
+
> **Build from source / quick test**
|
|
18
|
+
>
|
|
19
|
+
> ```bash
|
|
20
|
+
> git clone https://github.com/AmanM006/foresight.git
|
|
21
|
+
> cd foresight
|
|
22
|
+
> pip install -e .
|
|
23
|
+
> copy .env.example .env
|
|
24
|
+
> python -m foresight.demo_scenario
|
|
25
|
+
> ```
|
|
26
|
+
>
|
|
27
|
+
> Add your `OPENAI_API_KEY` to `.env` after copying the example file. On macOS/Linux, use `cp .env.example .env`.
|
|
28
|
+
|
|
29
|
+
## Verify this submission
|
|
30
|
+
|
|
31
|
+
Run the complete replay-safe verification pass with one command:
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
python verify.py
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
It checks the environment, runs tests when present, and executes the full replay demo without spending tokens. Add `--live` only when you want it to run the paid tier and injection benchmarks as well. For a zero-setup visual alternative, explore the deployed dashboard at [sentry-lime.vercel.app](https://sentry-lime.vercel.app).
|
|
38
|
+
|
|
39
|
+
## The problem
|
|
40
|
+
|
|
41
|
+
When developers use Codex/GPT-5.6 for coding work, they often do not know upfront which tier or reasoning effort a task actually needs. Defaulting to Sol overpays for mechanical work; choosing too small a tier can leave an agent stuck and repeatedly escalating.
|
|
42
|
+
|
|
43
|
+
The risk is not hypothetical. An open [Codex issue #32250](https://github.com/openai/codex/issues/32250) reports GPT-5.6 Sol Medium reducing a Pro five-hour allowance from 87% to 76% during a short conversation and several trivial follow-ups. Recent [r/codex](https://www.reddit.com/r/codex/comments/1ust6y8/usage_drops_much_faster_now_despite_less_cost/) and [r/ChatGPTPro](https://www.reddit.com/r/ChatGPTPro/comments/1us02nr/56_rate_limits/) threads describe confusion around five-hour versus weekly limits; these are community reports, not a claim about every session. Community guidance also identifies duplicated context and uncontrolled subagent spawning as sources of extra consumption ([discussion](https://www.reddit.com/r/codex/comments/1uu7weh/possible_fixes_for_gpt_56_burning_through_your/)).
|
|
44
|
+
|
|
45
|
+
There is a second failure mode: scope creep. A small implementation task can turn into unrequested architecture work, sprawling documentation, or broad file changes—the “Sol Ultra problem” discussed by users—silently consuming budget without an early warning. OpenAI documents that `ultra` coordinates four agents in parallel by default and trades higher token use for stronger results on demanding tasks; it is not an appropriate default for every coding task ([OpenAI GPT-5.6 overview](https://openai.com/index/gpt-5-6/)).
|
|
46
|
+
|
|
47
|
+
**Foresight solves this by predicting complexity and tier before execution, then watching the live session to catch drift before it compounds.**
|
|
48
|
+
|
|
49
|
+
## Live demo proof
|
|
50
|
+
|
|
51
|
+
One real recorded demo run produced the following result:
|
|
52
|
+
|
|
53
|
+
| Signal | Observed result |
|
|
54
|
+
| --- | --- |
|
|
55
|
+
| Predicted route | `luna / low / isolated` |
|
|
56
|
+
| Files touched | `16` |
|
|
57
|
+
| Predictive flag | `scope_explosion` |
|
|
58
|
+
| Final disposition | `escalated_for_review` |
|
|
59
|
+
| Recorded model cost | approximately `$0.0060` |
|
|
60
|
+
|
|
61
|
+
The demo showed two independent catch mechanisms live:
|
|
62
|
+
|
|
63
|
+
- **Predictive scope-drift detection:** unrelated file changes exceeded the predicted isolated blast radius.
|
|
64
|
+
- **Forbidden-pattern interception:** an attempted `.env` read was caught and blocked by the policy layer.
|
|
65
|
+
|
|
66
|
+

|
|
67
|
+
|
|
68
|
+

|
|
69
|
+
|
|
70
|
+

|
|
71
|
+
|
|
72
|
+
Inspect the sanitized raw evidence in [`examples/`](examples/): [`policy_and_verdict_output.example.json`](examples/policy_and_verdict_output.example.json) and [`audit_event_output.example.json`](examples/audit_event_output.example.json).
|
|
73
|
+
|
|
74
|
+
## Evidence and benchmarks
|
|
75
|
+
|
|
76
|
+
| Evidence | Real result |
|
|
77
|
+
| --- | --- |
|
|
78
|
+
| **Tier prediction accuracy** | 15 hand-labeled tasks spanning mechanical, moderate, and architectural complexity. **14/15** exact tier match, **1** conservative overestimate (avatar upload: expected `terra/moderate`, predicted `sol/moderate`), **0** risky underestimates. Total cost: **$0.0346** across 15 real GPT-5.6-terra calls. [View results](benchmark_results.json). |
|
|
79
|
+
| **Injection resistance** | 10 adversarial prompt-injection scenarios across hidden HTML comments, code comments, disguised TODOs, subprocess arguments, config fields, misleading filenames, social-engineering “temporarily disable” requests, and multi-step justification chains. **9/10** caught and blocked. The one miss triggered the fail-safe path (uncertain evaluation → warning, not silent allow) rather than a full block; it is disclosed as a real finding. [View results](injection_benchmark_results.json). |
|
|
80
|
+
| **Multi-task session (false-positive check)** | One continuous session across four task types: a trivial README fix (`luna/isolated`, clean), scoped API validation (`terra/moderate`, clean), a broad payment migration (`sol/wide`, 6 files touched, not flagged as `scope_explosion` because wide scope was predicted), and an injected `.env` access attempt (blocked). Total session cost: **$0.01812**. [View results](multi_task_session_results.json). |
|
|
81
|
+
|
|
82
|
+
Run `python verify.py` to reproduce the zero-cost checks yourself, or `python verify.py --live` to reproduce the paid benchmarks above (~$0.08 total across all three).
|
|
83
|
+
|
|
84
|
+
One benchmark response includes its raw OpenAI response ID as tamper-evident proof that it was a real API call, not a fabricated result: `response_id: resp_016b9a9aa893e50d006a57492295908192b3c0b54f1eefd7c7`. The recorded response is documented in [`benchmark_results.json`](benchmark_results.json).
|
|
85
|
+
|
|
86
|
+
## What it does
|
|
87
|
+
|
|
88
|
+
- **Routes before spend:** predicts the right Luna/Terra/Sol tier, effort level, and blast radius before a single task action is evaluated.
|
|
89
|
+
- **Turns scope into enforcement:** derives a restrictive policy from the declared task instead of treating agent access as implicitly broad.
|
|
90
|
+
- **Intercepts high-risk actions:** captures file I/O, subprocesses, and network requests before execution.
|
|
91
|
+
- **Flags runaway behavior early:** detects scope explosions, low-progress churn, and repeated paralysis loops while the session is live.
|
|
92
|
+
- **Makes spend auditable:** streams actions, verdicts, predictions, signals, and token-derived costs to the event bus and dashboard.
|
|
93
|
+
|
|
94
|
+
## Architecture
|
|
95
|
+
|
|
96
|
+
```text
|
|
97
|
+
Task description
|
|
98
|
+
|
|
|
99
|
+
v
|
|
100
|
+
foresight/ predictor + session monitor
|
|
101
|
+
|
|
|
102
|
+
v
|
|
103
|
+
sentry/ interception engine + policy + event bus ----> dashboard frontend
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
- **`foresight/`** contains prediction, routing, the CLI, and session monitoring. Keeping these concerns together makes the pre-execution estimate and live escalation decision share the same session context.
|
|
107
|
+
- **`sentry/`** is the internal interception engine codename. It captures actions, applies policy, tracks costs, and publishes events. It is decoupled from `foresight/` so the security layer can be reused independently of prediction logic.
|
|
108
|
+
- **`sentry/web/`** is the single, restored Next.js dashboard. It consumes the event model rather than duplicating policy or interception behavior.
|
|
109
|
+
|
|
110
|
+
Sentry is the internal codename for the interception engine; **Foresight** is the complete product.
|
|
111
|
+
|
|
112
|
+
### Runtime decision flow
|
|
113
|
+
|
|
114
|
+
```text
|
|
115
|
+
1. Task description
|
|
116
|
+
-> predictor returns tier, effort, blast radius, and risk factors
|
|
117
|
+
-> scope-to-policy returns allowed paths, hosts, and forbidden patterns
|
|
118
|
+
|
|
119
|
+
2. Agent attempts an action
|
|
120
|
+
-> SentryProxy captures it before execution
|
|
121
|
+
-> Action(type, target, payload, timestamp, session_id)
|
|
122
|
+
|
|
123
|
+
3. Fast enforcement path
|
|
124
|
+
-> forbidden target: critical block, no model call
|
|
125
|
+
-> out-of-scope file or host: warning event
|
|
126
|
+
-> identical action repeated six times in 60 seconds: paralysis-loop block
|
|
127
|
+
|
|
128
|
+
4. Ambiguous in-scope action
|
|
129
|
+
-> GPT-5.6-terra returns a structured Verdict
|
|
130
|
+
-> allow, warn, or block before the original operation proceeds
|
|
131
|
+
|
|
132
|
+
5. Session-level monitoring
|
|
133
|
+
-> compare files, diffs, and spend against the original prediction
|
|
134
|
+
-> scope/churn signal triggers a contextual reassessment
|
|
135
|
+
-> kill only if the reassessment confirms a wide or Sol-level runaway
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
### Layer responsibilities
|
|
139
|
+
|
|
140
|
+
| Layer | Main modules | Responsibility | Why it is separate |
|
|
141
|
+
| --- | --- | --- | --- |
|
|
142
|
+
| Prediction | `foresight/predictor.py` | Produces tier, effort, blast radius, rationale, and risk factors from the task description. | Establishes an expected cost and scope baseline before any agent action exists. |
|
|
143
|
+
| Session control | `foresight/session_monitor.py` | Watches file count, repeated diffs, and cost ceilings; emits signals and reassesses drift. | Session-level behavior cannot be decided from one action alone. |
|
|
144
|
+
| Policy | `sentry/policy/engine.py` | Converts scope to `Policy`, makes local decisions first, and uses structured model review only for ambiguity. | Keeps common security decisions deterministic, cheap, and auditable. |
|
|
145
|
+
| Enforcement | `sentry/proxy/interceptor.py` | Temporarily intercepts file, subprocess, delete, and `requests` calls in the current Python process. | Places the decision immediately before the original operation can execute. |
|
|
146
|
+
| Telemetry | `sentry/eventbus/server.py` | Broadcasts actions, costs, predictions, and monitor signals over WebSocket; exports JSON audit logs. | Decouples producers from the dashboard and leaves a machine-readable record. |
|
|
147
|
+
| Presentation | `sentry/web/` | Renders live connection state, action feed, policy context, cost, and kill state. | Lets a reviewer understand a session without reading Python logs. |
|
|
148
|
+
|
|
149
|
+
### The common event contract
|
|
150
|
+
|
|
151
|
+
Every intercepted operation becomes the same `Action` record:
|
|
152
|
+
|
|
153
|
+
```text
|
|
154
|
+
Action
|
|
155
|
+
type: file_read | file_write | file_delete | subprocess | network
|
|
156
|
+
target: path, command, or host:port
|
|
157
|
+
payload: mode, unified diff, cwd/env summary, or request-size summary
|
|
158
|
+
timestamp
|
|
159
|
+
agent_session_id
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
Policy evaluation returns a `Verdict` with `severity`, `reason`, and `allowed`. This normalized pair is what the proxy enforces, the monitor observes, the event bus broadcasts, and the dashboard displays. Model use is represented separately as `CostEvent(model, input_tokens, output_tokens, cost_usd, timestamp)`.
|
|
163
|
+
|
|
164
|
+
### Four failure modes, four distinct mechanisms
|
|
165
|
+
|
|
166
|
+
Foresight deliberately gives each failure mode a distinct trigger, reason, event name, and escalation path instead of treating all anomalous activity as one generic warning:
|
|
167
|
+
|
|
168
|
+
1. **Forbidden-pattern interception** is deterministic and zero-latency. `SentryProxy` blocks an action such as `.env` access before it executes, emits the policy `Verdict`, and terminates only on a critical denied verdict. This is security enforcement, not prediction.
|
|
169
|
+
2. **Scope explosion** is predictive and contextual. `SessionMonitor` compares touched files with the predicted blast radius, emits `scope_explosion`, and re-runs complexity assessment with session context before committing to termination. A wide predicted task is not falsely killed for having a wide footprint.
|
|
170
|
+
3. **Hard action ceiling** is a deterministic workflow cap. The predictor maps `isolated` to 15 actions, `moderate` to 40, and `wide` to 100. Reaching the cap emits `hard_ceiling_reached` with `hard_action_ceiling_reached` as its final reason and terminates immediately, even if the agent believes it is nearly done.
|
|
171
|
+
4. **Parallel fan-out** detects a different failure shape from repeated loops: five distinct file or subprocess actions inside three seconds. It emits `parallel_explosion` and triggers soft reassessment, allowing deliberate, paced parallel work to remain unblocked.
|
|
172
|
+
|
|
173
|
+
**Burn-rate forecasting** is separately broadcast as `burn_forecast`, but it is intentionally informational rather than a kill switch. After enough cost events, it projects minutes remaining at the current cost/minute rate so a user can intervene before a budget ceiling is reached. This keeps forecast visibility separate from hard enforcement.
|
|
174
|
+
|
|
175
|
+
The independent `paralysis_loop` check remains in `SentryProxy`: a rolling 60-second window blocks the sixth identical action after five prior repeats before any model evaluation. It is distinct from parallel fan-out because one catches repeated identical work while the other catches a burst of different work.
|
|
176
|
+
|
|
177
|
+
This distinction is why the demo can truthfully show two independent outcomes: an immediate `.env` block from deterministic policy enforcement, and an `escalated_for_review` result after predictive scope drift is reassessed.
|
|
178
|
+
|
|
179
|
+
### Cost-aware model use
|
|
180
|
+
|
|
181
|
+
`scope_to_policy()` and `predict_complexity()` use structured output. `evaluate_action()` uses GPT-5.6-terra only when a local rule cannot resolve an in-scope but suspicious action. Each response has an explicit output cap, a stable prompt prefix for caching, and usage recorded through `CostTracker`.
|
|
182
|
+
|
|
183
|
+
Predicted effort is calibrated separately from tier: mechanical isolated work routes to `low`, normal scoped coding work defaults to `medium`, and `high` is reserved for genuinely high-stakes or architectural work. A high-effort prediction with a non-wide blast radius carries a deterministic advisory against casually escalating to `max` or `ultra`; the CLI renders it as a dim note and the dashboard renders it beside the predicted effort. No extra model call is required for that advice.
|
|
184
|
+
|
|
185
|
+
The architecture therefore treats model judgement as a metered dependency rather than an invisible background call.
|
|
186
|
+
|
|
187
|
+
### Current prototype boundaries
|
|
188
|
+
|
|
189
|
+
The repository is intentionally a focused vertical slice, not a claim of production multi-tenant infrastructure:
|
|
190
|
+
|
|
191
|
+
- Interception is process-scoped Python monkey-patching, not an operating-system sandbox.
|
|
192
|
+
- Audit events are held in memory and persisted through explicit JSON export rather than a database.
|
|
193
|
+
- Budget ceilings are current heuristics, not learned per-user limits.
|
|
194
|
+
- A deployed dashboard needs a reachable event-bus endpoint; it cannot receive events from a developer's local process without a connection path.
|
|
195
|
+
- The dashboard is intentionally a single deploy target at `sentry/web/`; a production hardening pass would add deployment-specific event-bus connectivity and persistence.
|
|
196
|
+
|
|
197
|
+
## What we got wrong, and what it taught us
|
|
198
|
+
|
|
199
|
+
We originally wrote the demo around the task “Refactor the login flow to add MFA support,” assuming it would produce a narrow `terra / isolated` prediction so the scripted scope-explosion sequence could exercise escalation. When we ran it against the real GPT-5.6-terra model, it classified MFA and authentication work as security-sensitive and returned `sol / high / wide`. That was the right call: MFA changes can affect identity, recovery, and session boundaries. Our test assumption, not the prediction, was wrong. The problem was that a wide blast radius has no file-count ceiling to exceed, so the demo narrative no longer matched the model’s real risk assessment. We redesigned the task as a genuinely narrow isolated variable rename, which keeps the expected route and scripted drift consistent. We also added a second, prediction-independent catch: the forbidden-pattern block on `.env` access. It works regardless of the predicted tier, so the demo now proves both predictive scope monitoring and deterministic interception without guessing a model outcome. This is the same principle the system is built to detect in agents: the gap between what we assumed a task’s scope was and what it actually turned out to be.
|
|
200
|
+
|
|
201
|
+
## Why not just use a bigger model for everything?
|
|
202
|
+
|
|
203
|
+
Sol costs five times Luna’s input and output price, while many coding tasks are mechanical enough to complete safely with a smaller tier. Defaulting to the frontier tier therefore creates exactly the avoidable spend Foresight is designed to expose. Prediction is not free: it adds a metered call before work begins. But a conservative prediction only adds an escalation round-trip, because Foresight reassesses live drift instead of trusting the first estimate blindly.
|
|
204
|
+
|
|
205
|
+
## Quickstart
|
|
206
|
+
|
|
207
|
+
Install the Python runtime and CLI:
|
|
208
|
+
|
|
209
|
+
```bash
|
|
210
|
+
pip install -r requirements.txt
|
|
211
|
+
# or, for the `foresight` command:
|
|
212
|
+
pip install -e .
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
Create your local environment file from the committed template:
|
|
216
|
+
|
|
217
|
+
```bash
|
|
218
|
+
copy .env.example .env
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
Set `OPENAI_API_KEY` in `.env`, then run the end-to-end demo:
|
|
222
|
+
|
|
223
|
+
```bash
|
|
224
|
+
python -m foresight.demo_scenario
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
For a complete local replay with **zero OpenAI API calls** (using real captured GPT-5.6 policy and prediction responses), run:
|
|
228
|
+
|
|
229
|
+
```bash
|
|
230
|
+
python -m foresight.demo_scenario --replay
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
The live path above remains the primary demonstration. Replay is the accessible fallback for judges who want to exercise the real interception and monitoring flow without an API key. For a zero-setup visual tour of the dashboard UI, visit [the deployed dashboard](https://sentry-lime.vercel.app); it is distinct from replay mode, which runs the local Python enforcement logic.
|
|
234
|
+
|
|
235
|
+
CLI workflow:
|
|
236
|
+
|
|
237
|
+
```bash
|
|
238
|
+
foresight init
|
|
239
|
+
foresight run -- python your_agent_task.py
|
|
240
|
+
foresight status
|
|
241
|
+
foresight export
|
|
242
|
+
```
|
|
243
|
+
|
|
244
|
+
Run the dashboard locally:
|
|
245
|
+
|
|
246
|
+
```bash
|
|
247
|
+
cd sentry/web
|
|
248
|
+
npm install
|
|
249
|
+
npm run dev
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
Open `http://localhost:3000/dashboard`. The event bus listens on `ws://localhost:8765` by default.
|
|
253
|
+
|
|
254
|
+
## Cost tracking and prompt caching
|
|
255
|
+
|
|
256
|
+
Every OpenAI response becomes a `CostEvent`, calculated from input/output token usage and streamed to the event bus. Calls use a stable system/context prefix with only task-specific content appended, improving prompt-cache reuse. Clear forbidden or out-of-scope actions are decided locally first, avoiding unnecessary model calls.
|
|
257
|
+
|
|
258
|
+
**Every prediction and policy call is cost-tracked in real time and streamed to the dashboard—Foresight audits its own spend, not just the agent’s.**
|
|
259
|
+
|
|
260
|
+
## Codex vs Antigravity build split
|
|
261
|
+
|
|
262
|
+
- **Codex:** reasoning-critical implementation in `sentry/proxy/interceptor.py`, `sentry/policy/engine.py`, `foresight/predictor.py`, `foresight/session_monitor.py`, plus the event bus, CLI, and end-to-end demo.
|
|
263
|
+
- **Antigravity:** frontend polish in `sentry/web/`, dashboard bug fixes, deployment configuration, environment/documentation cleanup, and this submission README.
|
|
264
|
+
|
|
265
|
+
This split is intentional and documented per hackathon submission requirements—Codex built 100% of the reasoning-critical logic: prediction, policy evaluation, and escalation.
|
|
266
|
+
|
|
267
|
+
## Roadmap
|
|
268
|
+
|
|
269
|
+
- Multi-agent swarm monitoring with a shared session risk view.
|
|
270
|
+
- Historical session learning to improve tier prediction over time.
|
|
271
|
+
- Monitoring support for Claude Code and other agent runtimes beyond Codex.
|
|
272
|
+
- Team-level policy profiles and budget guardrails.
|
|
273
|
+
|
|
274
|
+
## License and attribution
|
|
275
|
+
|
|
276
|
+
MIT License. Built for Build Week, July 2026.
|